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.
Choose one question
Build the needed workflow
Test it with users
You get evidence for the next investment decision.
One decision
THE RELEASE MUST HELP YOU MAKE
Fixed price
PER PHASE, AGREED UP FRONT
Yours
CODE, DATA AND IP
Build a first release that tests 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.
SCOPE RISKS
- Every feature on the roadmap, half-done
- A demo for a pitch deck, not for users
- A large commitment before user testing
- A throwaway prototype you can't sell from
- Launched without ownership or a handover plan
FIRST RELEASE
- 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
- Documented for your team to maintain
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
Choose one workflow that lets the intended users test the core idea. Define what they need to complete it and what evidence their use should produce.
Accounts and access
Sign-up, log-in, password reset and server-side role checks. AI coding tools can help build these, but the implementation still needs review and tests before launch.
A way to test value
A commercial product may need checkout, a mandate or invoicing. An internal pilot may instead measure time, errors or service quality. The test should match the investment decision.
Analytics you'll read
Track the usage and outcome measures needed for the decision, such as completion, repeat use or paid conversion. Agree the thresholds before the test starts.
An operating setup
Hosting, backups, error reporting and support appropriate to the test group. Load and recovery checks need to match the expected use.
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
We use a documented framework and relational database, with the data model reviewed against the next stage of the product.
Livewire or React
We choose Livewire or React against the required interactions and maintenance needs, with Tailwind for styling.
Stripe + GoCardless
We integrate the payment method the product needs, including webhook verification, reconciliation and supported refund flows.
UK or EU-region cloud
Hosting location, backups, error reporting and uptime monitoring are agreed before launch, with a named support owner.
Work with Vu in Solihull
Phil Webb and Alex Hawke founded Vu Agency in Solihull. The project scope sets out your contacts, review process and support arrangements.
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 bespoke source code, database, domain and product IP. Third-party services and open-source components remain under their own licences. 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. Most of our clients are in the UK, with others in the US and Australia. We agree working hours, support, data handling and contract terms against the territories 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.