Most MVPs don't fail in production. They fail in the planning document, months earlier, when someone wrote "minimum viable product" at the top of a page and then listed every feature the finished product would need. If you're a Cambridge startup — a spinout, a grant-funded venture, or two people with a Companies House registration and a hypothesis — the highest-leverage decision you'll make this year is what not to build.
We build software for early-stage companies, and the pattern is consistent enough to be worth writing down: the startups that learn fastest build the least, fake the most, and are brutally honest about which assumption their MVP actually exists to test.
An MVP is an experiment, not version one
The useful definition of an MVP: the cheapest thing you can put in front of real users that gives you a definitive answer to your riskiest assumption.
That framing changes everything, because experiments have a hypothesis and v1 products have feature lists. Ask "what would the product need?" and the answer is everything — accounts, billing, settings, notifications, an admin panel. Ask "what does the experiment need?" and the answer is usually one core interaction and a way to observe what users do with it.
So before any technology discussion, write your riskiest assumption down as a single sentence. Something like: "Lab managers will trust an automated system to schedule shared equipment instead of the whiteboard." Then put every proposed feature through one filter: if we cut this, does the experiment still produce a clear answer? If yes, cut it. Most features survive scoping meetings not because they're necessary but because nobody asked.
This is ruthless, and it should be. Every week spent building something the experiment doesn't need is a week of runway converted into code you'll probably delete.
What to fake
Faking parts of a product feels wrong to engineers. It isn't wrong; it's correct sequencing. Users can't see your architecture — they can only see the surface — and at MVP stage the surface is the only part that has to hold. Three categories almost never need to be real:
Admin panels: use a spreadsheet
Nobody outside your company will ever see the admin panel, so stop designing one. A CRUD interface with role management and audit logging is weeks of work serving two members of staff. Instead, have the application read from a shared spreadsheet or Airtable base, or accept that "updating a record" means someone runs a script. From the outside, the product is identical. Build real admin tooling when staff time becomes the bottleneck — at MVP scale, it won't be.
"Automation": do it by hand first
The concierge MVP is the most underused trick in early-stage product work. If your product promises matching, report generation, scheduling, or any other clever processing, do it manually behind the scenes. The user uploads their data; your "engine" is a person with a spreadsheet and a four-hour turnaround.
This buys you two things. First, it validates demand before you've spent anything on the clever part. Second — and this is the bit people miss — doing the job by hand teaches you what the automation actually needs to do. Every edge case you hit manually is a requirement you'd otherwise have discovered in production. Yes, it doesn't scale. It doesn't need to. It needs to survive twenty users, not twenty thousand.
Configurable flows: hard-code them
Settings pages, pricing tiers, white-labelling, "flexible" workflows — hard-code all of it. One plan, one flow, one configuration. If a second customer needs something different, change a constant and redeploy; that's minutes, against the weeks a configuration UI costs. You'll also guess the wrong axes of configurability anyway — you don't know which knobs matter until customers tell you.
The same logic covers payments (a Stripe payment link instead of integrated billing), auth (magic links instead of full account management), and transactional email (sent by a person, at first).
What must be real
One thing cannot be faked: the thing your riskiest assumption is about.
- If the risk is demand — will anyone pay? — the front of the product must be real enough to take money, even if the back is a person with a spreadsheet.
- If the risk is technical — can our model, sensor, or algorithm do this at all? — the core technology must be real, and everything around it (UI, onboarding, billing) can be scaffolding.
- If the risk is behavioural — will users actually change their workflow? — the workflow itself must be real and genuinely pleasant to use, and everything else stays minimal.
The common failure mode is building everything to 70%: a polished interface wrapped around a faked core, when the core was the question. That demo lies to you, and you make your next funding decision on the lie.
A good MVP is lopsided on purpose. One part is disproportionately solid — the experiment — and everything else is openly held together with tape. This is, candidly, where the way we work earns its keep: we're an AuDHD-founded studio, and when we lock onto the one component that has to be real, it gets total immersion, while pattern recognition from previous builds makes it faster to spot which parts are safely fakeable.
The Cambridge problem: milestone-shaped MVPs
Cambridge startups operate inside a specific distortion field. University spinouts and grant-funded ventures don't only answer to users — they answer to milestones: the investor demo day, the Innovate UK quarterly deliverable, the departmental review. Milestones reward looking finished. Experiments reward finding the truth quickly. Those pull in opposite directions, and the milestone usually wins.
The result is a familiar shape: a demo build that impresses a panel but tests nothing — one hard-coded happy path that no user outside the room could survive. Or grant deliverables written eighteen months ago dictating what gets built this quarter, regardless of everything learnt since.
You can handle this without torching your funding:
- Separate the demo from the experiment, explicitly. A demo is allowed to be a film set — scripted path, hard-coded data — provided everyone internally knows it's a set. The danger isn't the set; it's the moment the team starts believing it's a building.
- Write deliverables around learning where you can. Monitoring officers and assessors generally accept milestones framed as validated questions — "completed pilot with N users and a go/no-go decision" — rather than shipped feature lists. That phrasing gives you room to follow the evidence. The honest caveat: sometimes the deliverable list is already fixed. In that case, build each deliverable as cheaply as honesty allows and ring-fence part of the budget for the real experiment.
- Spinouts: test the commercial risk, not the science. If the technology was de-risked in the lab, re-demonstrating it is comfort work. The untested assumption is almost always commercial — will anyone outside academia pay for it, integrate it, change their process for it? Aim the MVP there.
Navigating those funding-cycle pressures alongside the build is a large part of what our software development in Cambridge work involves, because the build and the milestones have to be planned together or one quietly eats the other.
Tech choices that keep options open
Over-engineering is the respectable-looking way to kill an MVP. Microservices for zero users, Kubernetes for one container, an event-sourced architecture because the conference talk was persuasive. The opposite failure — "just throw something together" — produces a build too brittle to learn from. The middle path:
- Boring, mainstream stack. Postgres, a mainstream web framework, one server or a simple managed platform. Boring means problems are searchable, hiring is easier later, and nothing about it prevents scaling. Most products you use daily started as a monolith on exactly this.
- A monolith with clean seams. Keep modules separated inside one deployable. You get most of the future flexibility of services with none of the operational cost.
- Buy, don't run. Managed auth, managed email, managed payments, managed hosting. Your differentiation is the experiment, not your infrastructure.
- Web first, unless hardware or native genuinely demands otherwise. Responsive web application development reaches every device from one codebase; native apps and app-store review cycles can wait until the experiment says yes.
- Decide what's scaffolding and what's foundation — upfront. Either answer is fine. Pretending the code is both is how a "temporary" prototype ends up carrying five years of production traffic. Realistically, successful MVP code gets refactored rather than rewritten, so keep one boundary clean — the core domain logic — and let the edges be scrappy.
Budget reality
An MVP scoped as an experiment, with aggressive faking, is a build measured in weeks, not months — and the cost should reflect that. If a proposal for your "MVP" runs six months before first user contact, it isn't an MVP; it's a v1 wearing the name to get through budget approval.
Two rules of thumb we'd stand behind. First: if the build costs more than running the manual concierge version for six months would, the scoping went wrong. Second: reserve 20–30% of the budget for changes after launch. The first version will be wrong in specific, informative ways — that's the point of it — and the startups that budget for iteration learn from those signals instead of just absorbing them.
Where to start
If you're scoping an MVP — spinout, grant-funded, or bootstrapped — we're happy to talk through what to build and what to fake, with no pitch deck required. Email hello@overclockminds.co.uk or get in touch.