MVP definition & rapid prototyping

Who comes to us for this

Two kinds of people, usually. Founders - some technical, many not - who have a business to run and need a product that exists, works, and can be put in front of users and investors without apology. And established businesses testing a new line: a service they want to productise, a tool their industry lacks, an idea that keeps coming up in customer conversations. Both arrive with the same question - is this worth building properly? - and a working MVP is the cheapest honest answer available.

• Founders who need a product users and investors can actually touch
• Established businesses productising a service or testing a new line
• Product teams that need evidence before a board will fund the build

Small, but real

An MVP is not a rough draft - it is an experiment with a sharp question: will people use this? We cut scope hard until what is left tests that question and nothing else, then build it well enough to survive contact with real users. Polish comes later, if the answer is yes.

The scoping week, where most of the value hides

The first thing we build is nothing at all. The opening days are spent pinning down the hypothesis - who the user is, what they do today, what would make them switch - and then cutting everything that does not test it. Off-the-shelf login instead of custom accounts, one platform instead of three, a manual step behind the scenes where users will never notice the difference. Every cut is written down with its reasoning, so the deferred features are a backlog rather than a loss. What survives the week is small enough to build fast and real enough to trust the answer.

• One core hypothesis, agreed in writing
• A cut list with reasoning, so scope can be restored deliberately later
• The smallest build that produces an answer you can trust

Weeks, not quarters

Senior engineers build the prototype in tight build-measure-learn loops, and findings are shared as they land rather than saved for a big reveal. Most clients have something in front of users within a few weeks. By the end, the decision tends to make itself - the evidence is either there or it is not.

• Built by senior engineers - quickly, but not carelessly
• Real users on it within weeks
• Findings shared as they arrive

Measured, not just launched

An MVP without measurement is just a small product. Ours ship instrumented: analytics on the flows that matter, funnels around the core action, and enough session context to see where people hesitate. Before launch we agree what signal would count as validation - activation, repeat use, willingness to pay - so the read at the end is against a bar set while everyone was still objective, not one moved after the fact.

What you walk away with

A working product on infrastructure you own, with the codebase, the accounts and the IP in your name from day one. Alongside it, the evidence: what real users did, where they stalled, what they came back for - and a written recommendation to build, pivot or stop, with the reasoning attached. If the answer is build, the same engineers carry on and the MVP becomes release one. If it is stop, you have spent weeks and a fixed fee learning what a full build would have taught you in a year.

Technology that keeps your options open

An MVP’s stack has one job: not to foreclose anything. We build on mainstream, well-supported technology - the kind your eventual hires will already know - and on infrastructure in your own accounts from the first commit. No exotic framework someone fell in love with, no platform that holds the product hostage, no shortcuts that mean release one starts with a rewrite. If the product takes off, the MVP is the foundation; if you take it to another team, they will recognise everything they open.

What an MVP costs

MVPs here are fixed-scope projects starting from £8,000, priced in the scoping week and agreed in writing before the build begins. The whole point of an MVP is a known cost for a real answer, so an open-ended invoice would defeat it. If the scope shifts mid-build because the evidence says it should, that is a conversation and a decision - never a surprise on the bill.

What happens next

Strong signal? The MVP becomes the foundation of the full build - same codebase, same team, no restart. Weak signal? You have learned that at prototype prices, and a pivot or a stop is a respectable outcome. Either way you are deciding on evidence rather than enthusiasm.

Why we build plain first

We once joined a project where sixty-four beautiful screens had been signed off before a line of code existed - for a scheduling tool whose real-world jobs turned out to have seventeen states, not the three the mock-ups allowed. Two weeks of plain screens on real data found the other fourteen. That is the order an MVP runs in here: make it work on real data first, and make it beautiful once the answer has earned it.