Startup MVP Development Services

Most failed MVPs are not failures of speed. They are products that shipped fast, found a market, and then could not be changed because the data model assumed one customer, one currency and one way of working.

The parts worth building carefully are small and identifiable: how records relate, how tenants are separated, how identity works, and how anything financial is recorded. Nearly everything else can be crude at first and fixed once you know what users actually do.

A minimum viable product is the smallest system that can produce a real answer to a question you cannot answer any other way. If you already know the answer, you are not building an MVP, you are building version one of a product — a legitimate thing to do, but priced and scoped differently.

When you should not build an MVP

An MVP is the wrong instrument in three cases, and it is worth checking before spending anything.

The first is when the question can be answered without software. If the uncertainty is whether anyone will pay, a landing page, ten conversations and a spreadsheet operated by hand will settle it faster and for a fraction of the cost. Running the process manually for twenty customers teaches you what the software should do; building the software first teaches you what you assumed.

The second is when the product is only viable at full scope. Regulated products, clearing and settlement, anything where a partial system is unusable or unlawful — these do not have a meaningful minimum. Scoping them like a consumer app produces a demo that cannot be operated.

The third is when the MVP is really a funding artefact. A build aimed at a slide rather than at users optimises for what looks impressive in a ten-minute demo, which is almost the opposite of what survives a hundred real users. That is a design and prototyping job, and it should be bought as one.

What actually goes into the first version

One loop, end to end, working properly. Not a slice of every screen on the roadmap — the complete path from the thing a user arrives wanting to the thing they leave with, including the part where the business gets paid if payment is part of the proposition.

The failure mode here is subtle and we have watched it happen. A project can have the schema, the designs and the plan for a whole half of the product, and still have nothing usable, because the work was cut by layer instead of by loop. On one system, seventy-five endpoints existed and every one of them served the parent’s side of the product. The child’s half had tables, columns, a design and a plan, and not a single route to talk to. Everything looked most of the way done in every artefact except the running application.

Cut by journey, not by layer. A vertical slice that one real person can complete is worth more than four horizontal ones that nobody can.

One thing that looks like polish and is not: seeded demo data, built as numbered scripts that run from an empty database, with a companion script that asserts the seed actually landed. It is what lets you demonstrate the product without touching a customer’s records, gives every test a known starting state, and forces the onboarding path to be exercised early rather than discovered on the day a second customer arrives.

The four decisions that are expensive to reverse

Records and how they relate. A column named id is a naming convention, not a type. On one consolidation, converting forty key columns to a single identifier format meant three had to be reverted, because what they actually held was a handle, a display name and a mixed bag. Deciding what a record is, and what identifies it, is cheap on day one and archaeological later.

Tenancy. Isolation enforced by a WHERE clause depends on nobody ever forgetting one. Enforced by composite foreign keys, a cross-tenant row cannot be written at all. Same effort in week one; a different category of problem in year two. And isolation is only half of it — if loading a new customer’s configuration needs a developer, your customer ceiling is your developer capacity, however multi-tenant the schema is.

Identity and permissions. Two hard-coded roles look adequate until the fourth kind of user arrives. Replacing them later is not a refactor, it is a re-audit of every screen and every endpoint. Building permissions first and composing roles from them costs a few days early on, and on one system that exercise caught a design bug which would have shown field staff the director’s dashboard.

Money. Never store a balance; store the entries that produce it. A mutable total looks simpler for about a week, and then a retried request pays twice and nobody can reconstruct where the number came from. Related, and easy to get wrong in any language with loose typing: fixed-precision money columns come back from database drivers as strings, and adding them with the wrong operator produces a receivables figure of zero while forty-five unpaid invoices sit in the table.

Which shortcuts are genuinely safe

Plenty, and taking them deliberately is what makes the timeline work. A back-office step done by hand in a spreadsheet. An interface that is plain rather than designed. One server rather than an orchestrated cluster. No reporting beyond a couple of queries someone runs when asked. Onboarding performed by us rather than self-service. Email sent from a single template.

Each of those is a few days to fix later and none of them constrains anything else. The rule is that a shortcut is safe when it can be replaced without changing the shape of the data — and unsafe when reversing it means rewriting rows that already exist.

Structure is on that list too, within limits. A genuine prototype can be a single file of a few hundred lines with the queries written inline, and there is nothing wrong with that while it is answering a question. What makes it dangerous is not its size but the moment it stops being a prototype without anyone saying so — when a second developer arrives, when it holds data someone would miss, or when a customer is given the address. Name that transition and pay for the restructuring then, deliberately, rather than discovering later that the throwaway version is the production one.

How “deferred” is written down

Everything cut is recorded, with the reason and an estimate of what adding it later costs. That document is the deliverable people underestimate, because six months on nobody remembers which gaps were decisions and which were oversights, and the difference determines whether you trust the system.

It is kept accurate rather than written once. A stale register is worse than none: on one project a backlog entry claiming an offline sync layer had never been built caused two rounds of work to be commissioned against a module that already existed and worked. Anything the register says is missing gets checked against the running system before it is scheduled.

What instrumentation from day one means

Enough to answer the question the MVP exists to ask. Which steps of the loop people complete, where they stop, how long the thing they came for actually takes, and how often the paths you were worried about are used at all. Error reporting that reaches a person, not a log file nobody opens.

This is a small amount of work and it is the part most often skipped, which is how a first version launches and produces opinions instead of evidence.

What happens after launch, and what you own

Either the same team keeps building against what usage shows, or an in-house team takes it on with the repository, migrations, tests, infrastructure definitions and a runbook. Ownership is not a handover event — the code and the accounts are yours from the first commit, and the test of the documentation is whether someone who has never met us can stand the system up and deploy a change.

We say where our own products are honestly for the same reason we ask founders to: of the seven in the Sarva portfolio, some are live with operators, one is in user acceptance testing, one is still in build and one is pre-launch and not generally available. Stating the stage plainly is cheaper than being found out by a demo.