What an MVP actually has to do
An MVP is not a cheap version of the product. It is the smallest thing that can settle the one assumption the whole business rests on, and everything that does not serve that question is scope you pay for twice.
The first job is therefore to name that assumption out loud. Will people pay for this? Will they change an existing habit? Can the workflow survive contact with real data? Once it is written down, most feature lists shrink by half on their own.
How the scope gets cut
Anything that can be done manually behind the scenes at low volume stays manual. Onboarding, approvals, refunds and support can all be a human in a dashboard for the first hundred users, and building them properly before that is guesswork.
Admin panels, analytics suites, role hierarchies, multi-language support and settings screens are the usual suspects. They feel essential and almost never are before launch.
What ships in the first version
A working product path from signup to the moment the user gets value, on a real domain with real authentication and a real database. Payments if the assumption being tested involves money, because willingness to pay is not measurable without a checkout.
Analytics on the handful of events that answer the assumption, so the launch produces evidence instead of opinions. Plus a way to contact users, since early conversations explain the numbers.
Stack and delivery
React and TypeScript on the frontend, Python or Node.js and Postgres behind it, hosted on Vercel or Supabase. These are boring, well-documented choices, which matters because the MVP has to be cheap to change and easy for the next developer to pick up.
Work runs in weekly increments on a live preview URL. You use it every week and steer, which is the only reliable way to catch a wrong assumption while it is still cheap.
What happens after launch
The first weeks of real usage usually contradict part of the plan, and that is the point. The build is structured so the pieces most likely to change are the easiest to replace.
From there the work is either hardening what worked, or cutting what did not and testing the next assumption. Both are cheaper than having built the full product first.
Frequently asked questions
How long does an MVP take?
Most focused MVPs ship in four to eight weeks. The variable is scope, not speed, so the scoping conversation matters more than the estimate.
How much does an MVP cost?
It depends on the number of user journeys and whether payments and integrations are in scope. You receive a written scope and a fixed quote before any work starts.
Do I need a technical cofounder first?
Not to validate an idea. Many founders build and launch the first version this way, then hire once there is traction and a reason for someone to join.
Who owns the code?
You do, in your own repository, from the first commit. There is no lock-in and no licence attached to the source.
Can the MVP scale if it works?
The stack used is the same one that runs production systems, so the usual path is hardening and extending rather than rewriting. Where an MVP shortcut exists it is written down so the cost of removing it later is known.
Can you keep working on it after launch?
Yes, either as ongoing weekly development or as a handover to your own team with documentation and a walkthrough.
Get your MVP scoped
Tell me what you need and you get a written scope, a fixed quote and a delivery timeline before any work starts — no obligation.
Ananth N · Madurai, Tamil Nadu · serving Madurai, Coimbatore, Chennai and clients across India · remote-first.
Discuss your MVP WhatsApp Email