Software Development · Service 05
MVP & Digital Product Development
A first release scoped tightly enough to launch and learn, built well enough that success does not force a rewrite.
What this service is
The purpose of a first version is to replace opinion with evidence — without spending the whole budget getting there.
MVP development is the disciplined business of deciding what not to build. A minimum viable product is not a rough version of everything; it is a complete, properly built version of the one thing that proves the idea works.
We help with the scoping as much as the building. The most common reason a first release disappoints is that it tried to cover too much ground, arrived late, and still could not answer the question it was meant to answer. The second most common is that it succeeded and then had to be thrown away.
What we can deliver
Deliverables for this service
Not every engagement includes every item. Your quotation lists exactly what is in scope and what is not.
- 01Product definition workshop
The problem, the intended user, the value proposition and the assumptions that must be tested, captured in writing.
- 02Scope and exclusion list
What version one includes and, just as importantly, what it excludes and why. The exclusion list is the deliverable people underestimate.
- 03Core user journey
The path that proves the product’s value, designed and built properly rather than mocked or half-implemented.
- 04Technical foundation
Architecture, data model and hosting chosen for a small user base but capable of growing without being replaced.
- 05Accounts, roles and administration
Registration, authentication, permissions and enough internal tooling to run and support the service.
- 06Payments where relevant
Subscription or one-off payment through an established provider, with the states that follow a failed payment handled.
- 07Measurement and feedback
Privacy-conscious usage measurement against the assumptions being tested, plus structured routes for users to tell you what is wrong.
- 08Release pipeline
Automated build, test and deployment so improvements reach users in days rather than months.
Business problems we solve
The situations that bring people to this service
If more than two of these describe your organisation, the conversation is usually worth having.
Visual model
How the work is structured
Drawn for this page in SVG. Nothing here is stock imagery.
Our approach
How we work on this specifically
The parts of the method that matter most on this kind of engagement.
- 01Name the assumption
We identify what must be true for the product to work, then design the release to test that specifically. It is what separates an MVP from a small version of everything.
- 02Cut hard, build properly
Narrow scope, full quality. A cut-down feature set built well beats a broad feature set built badly, because only one of them can be extended.
- 03Choose boring foundations
Established technology, straightforward architecture and mainstream hosting. Novelty in the stack adds risk without adding evidence.
- 04Instrument from day one
If the release cannot show what people did, it cannot answer the question it was built to answer.
- 05Plan the next decision, not the next two years
We finish with a costed view of realistic next steps so the following commitment is made on evidence.
Common use cases
Where this work typically applies
Practical examples rather than industry categories — the pattern matters more than the sector.
- 01Founder validating a new product
A first release that tests demand and willingness to pay with real users rather than survey responses.
- 02Established business launching a service line
A contained pilot for a new digital offer, kept separate from core systems until it earns its place.
- 03Digitising a manual service
Taking a service delivered by phone, email and spreadsheets and proving it works as a product.
- 04Proof of concept for a technical question
A narrow build that answers a specific feasibility or performance question before committing to a full project.
- 05Pre-investment position
Working software, evidence of usage and a costed roadmap to support a funding conversation.
- 06Internal product pilot
Testing a tool with one team before deciding whether to roll it out across the organisation.
Project stages
The sequence from enquiry to delivery
Each stage has a defined output and a review point. You always know where the work stands.
Define
Problem, user, value and assumptions established; success criteria agreed.
Scope
Core journey chosen, exclusions documented, technical approach and cost confirmed.
Build
Short cycles with working software available for review throughout.
Launch
Controlled release to a first group of real users, with monitoring in place.
Learn
Usage and feedback reviewed against the original assumptions.
Decide
Continue, adjust or stop — with costed options for each.
Technical capabilities
What we bring to this work
Capability relevant to this service. We do not list technology we would not actually recommend.
Product
- Assumption and risk mapping
- Scope definition and exclusion lists
- Core journey design
- Pricing and packaging structures
- Feedback capture
- Roadmap and prioritisation
Build
- Web application development
- Accounts, roles and permissions
- Subscription and one-off payments
- Email and notification flows
- Administration tooling
- Responsive interface design
Learn
- Privacy-conscious usage measurement
- Conversion and drop-off analysis
- A-B capability where justified
- Error and performance monitoring
- Release pipeline for fast iteration
- Post-launch review
Who this service is for
Typical clients for this work
We work with B2B companies, organisations and private clients. The requirement matters more than the size of the buyer.
Founders and startups
- First-time founders needing a technical partner
- Teams preparing for a funding conversation
- Ventures testing willingness to pay
Established businesses
- Companies launching a new digital service line
- Organisations digitising a manual service
- Teams piloting an internal tool before wider rollout
Private clients
- Individuals developing a personal venture
- Professionals productising their own expertise
Related services
Often commissioned alongside this
Service FAQ
Questions we are asked about this service
A prototype demonstrates an idea and is usually discarded. An MVP is real software that real users use for real purposes, built to a standard that allows it to continue. Both are legitimate; they answer different questions and cost different amounts, so it is worth being clear which you need.
By working backwards from the assumption you most need to test. If the question is whether people will pay, payment must be in scope and reporting can wait. If the question is whether the workflow saves time, the workflow must be complete and branding can wait.
Then it has done its job at a fraction of the cost of finding out later. We will tell you plainly what the evidence shows. A clear negative result reached in three months is a far better outcome than an ambiguous one reached in eighteen.
Not if it is built properly. We deliberately avoid shortcuts that cannot be undone: a coherent data model, separated business logic, automated tests on the core and mainstream hosting. Parts will be replaced as the product grows, which is normal, but the foundation should not need discarding.
No. We work on a straightforward commercial basis with a written quotation, which keeps the relationship clear and our advice independent of the outcome.
Have a project in mind?
Tell us what you are trying to achieve and we will come back with a clear view of the scope, the approach and the cost.