MVP Development
in the UK
A new product or internal programme needs evidence before the business approves a larger investment. We build the smallest usable release around one buyer or workflow, then measure what it proves and what remains uncertain.
One decision
THE RELEASE MUST HELP YOU MAKE
Fixed price
PER PHASE, AGREED UP FRONT
Yours
CODE, DATA AND IP
Build the smallest thing that proves the idea
Inside an established business, a focused first release should answer a specific investment question. That may be whether customers will use a new service, whether an internal workflow produces the expected saving or whether an integration works with live operating constraints.
It still needs the security, data handling and support required for real users. The reduced scope comes from solving one complete job, rather than leaving several features half built.
The release ends with evidence and a recommendation for the next funding decision.
THE WRONG MVP
- Every feature on the roadmap, half-done
- A demo for a pitch deck, not for users
- Six months and a six-figure cheque
- A throwaway prototype you can't sell from
- Built abroad, launched, then unmaintainable
THE RIGHT MVP
- One job, done end to end
- Real users, real money, real feedback
- A delivery plan based on scope and dependencies
- Production code you'll keep building on
- Built in the UK, maintainable by you
What the first version needs
The first version must complete one useful job from start to finish. These are the parts we usually need to make that possible.
One real job
A single workflow a user will pay for, sign up for, or come back to. Not a general-purpose toolkit. One job, done well.
Accounts and access
Sign-up, log-in, password reset, the right role checks on the server. Boring, mandatory, the bit AI coding tools get wrong on day one.
A way to pay
Stripe checkout, GoCardless mandate, an invoice, whatever fits. If money can't change hands, you're not validating, you're showing slides.
Analytics you'll read
Three or four numbers that tell you whether the idea works. Activation, retention, money, the one funnel step that matters. Not a dashboard nobody opens.
A backbone that holds
Hosting, backups, error reporting, the basics that mean the MVP doesn't fall over the first time five people show up at once. Production code, not a prototype.
How we take it into live use
The people who define the product decision remain involved through engineering and review. Your internal sponsor and technology team can see the assumptions, code and evidence throughout.
Each phase has a defined product decision and working software. AI coding tools can reduce engineering time, while a human engineer remains accountable for architecture, testing and the handover.
BOOK A SCOPING CALLScoping
We sit with you and cut the idea down to the smallest version that still proves the point. You leave with a written scope, a named price, a date for first live version, and a list of the bits we're deliberately not building yet.
Build in the open
Your product owner receives a working preview and regular demonstrations. Feedback is recorded while the relevant part is still in progress, with changes assessed against the agreed decision and budget.
Run it with real users
The release uses the agreed domain, accounts, payments where required, monitoring, backups and privacy controls. Access and support are set for the test group before it opens.
Hand over, or keep going
We can hand the codebase and operating notes to your internal team or continue under a separate support and development scope. Ownership and access are agreed before the build starts.
A maintainable technical foundation
We use widely supported technology that an internal or incoming engineering team can understand, operate and recruit for.
Laravel on PostgreSQL
Documented, conventional, and easy for the next engineer to inherit. PostgreSQL because the MVP shouldn't need a database rewrite when it grows.
Livewire or React
Server-rendered with Livewire for internal tools, React when the UI really needs it. Tailwind throughout. No designer round-trip for every change.
Stripe + GoCardless
Stripe for cards, GoCardless for UK direct debit. Signed webhooks, reconciled, refundable. Real money, not a fake checkout.
UK or EU-region cloud
AWS or Hetzner, hosted in the UK or EU. Daily backups, error reporting via Sentry, uptime monitoring. The basics, wired up from day one.
A UK-based development team
Same time zone, English law, and a team you can reach during the UK working day. When the payment provider asks a question or a user emails you about their data, the answer doesn't go through a ticket queue in another continent.
Data and procurement requirements
We record the data flow, hosting, processors, lawful basis and retention needed for the first release. Your privacy, security and procurement teams can review the same information before access is widened.
Internal ownership and handover
The business sponsor, product owner, technical contact and support owner are named in the scope. Repositories, hosting, accounts and documentation remain accessible to the people responsible for the next decision.
Evidence for the next approval
The release starts with a baseline and test plan. At the end, leadership and finance receive the usage, operating result, remaining risks and costed options for stopping, extending or rebuilding.
Who the engagement suits
These are common reasons for approving a focused first release. Each one needs a different buyer, evidence threshold and route to a larger investment.
A product customers are already asking for
The company understands the buyer and commercial need, but wants evidence before committing a full internal team or larger budget.
A workflow that needs proof before rollout
Operations has a defined problem and an owner. Finance and IT need a usable result, measured value and known dependencies before approving wider adoption.
Industry knowledge with a route to market
The subject experts, target customers and commercial owner are in place. The first release tests the product boundary and how the new operation would run.
We build and operate our own products too
Raq.com, 102.ai and Project Quote AI give us direct experience of product scope, accounts, billing, permissions, support and the work that starts after a first release is usable.
When this is worth discussing
We work best when there is a real operating problem, enough volume to measure and people from the affected teams who can make decisions.
Usually a good fit
- An established UK business, usually with annual revenue above £10m
- A repeated process with a known cost, delay, error rate or capacity problem
- A senior sponsor and a day-to-day owner who understand the work
- Access to the relevant staff, systems, sample records and security requirements
We may point you elsewhere
- A standard product already covers the process well
- The requirement is a one-off small build with no wider operating case
- There is no owner or access to the people and data needed to test the result
- The plan relies on AI making high-impact decisions with nobody responsible for review
Questions before connecting the systems
How much does an MVP cost?
We price the agreed phase after confirming the user, workflow, integrations, data and commercial risk. The proposal is issued before engineering starts and separates third-party running costs.
Why not build it on Lovable or Bolt myself?
They can be suitable for a landing page or internal prototype. Before external users or payments are involved, the team should review authentication, server-side authorisation, data persistence, webhooks, logging, backups and provider limits. Our Fix My Vibe-Coded App page covers that production review.
What if I don't know exactly what I want yet?
Good. The scoping phase is where we figure that out together. You bring the problem, the customer, and any half-formed idea of the answer. We bring the questions and the experience of building this kind of product before. You leave with a scope you understand and could explain in a pub.
Do I own the code?
The agreement states ownership of the source code, database, domain and product IP. The repository can live in your GitHub organisation, with hosting and handover terms settled before the build.
Will this survive past the MVP?
Yes, when the first release is built on supported technology with a data model and operating setup that suit the expected next stage. The proposal identifies which parts are intended to continue and which are deliberately temporary tests.
Do I need to be in the UK?
No. We work UK hours and contract under English law, while the product scope can cover customers and operations in other territories. Data protection, sector rules, hosting and support hours are agreed against the markets involved.
What if the idea doesn't work?
The release should test whether the idea earns more investment. We agree the success and stop criteria before launch, then report the evidence even when it argues against a larger build.
Talk to us about the first version
Tell us the decision the first release needs to support, the users involved and the budget at risk. We will identify the smallest useful scope and the evidence it should produce.