Most MVPs don't fail because the developer was bad. They fail because the thing that got built was too big, and the money ran out before anyone found out whether users wanted it. That's the single most common way I see founder budgets disappear, and it's almost entirely preventable in the first two weeks — before a line of code exists.

I build these for a living. I've shipped an AI real-estate app (Atikia), an e-commerce funnel platform (Lightfunnels), a construction-tracking app with real-time sync (AMG), and a high-traffic research video platform (JoVE). This guide is the conversation I have with founders before we start, written down: what an MVP actually is, how to decide what goes in it, what it should be built with, how long it takes, and the specific places where the money leaks out.

You don't need to learn to code to make good decisions here. You need to know which decisions are yours.

An MVP is a question, not a small product

The most useful reframe I can give you: your MVP is an experiment with a specific question attached. It isn't "version one of my app." It isn't "my app but cheaper."

If you can't finish this sentence, you're not ready to build:

"If ______ happens within ______ weeks of launch, the idea works."

Founders who can finish that sentence scope well, because every feature request gets tested against it. Founders who can't finish it end up building everything, because with no criterion for what matters, everything looks like it matters equally.

This is also the fastest way to tell whether a developer is any good — a strong one will ask you this in the first meeting and won't be satisfied with a vague answer. More on that in how to vet a developer when you can't code.

If the terminology is still fuzzy — MVP, prototype, proof of concept, "v1" — start with what an MVP actually is, then come back.

The five decisions that are actually yours

Everything else is implementation detail you can delegate. These five are not.

1. What goes in version one

This is the decision that determines your budget, because scope is cost. Not the framework, not the hosting, not the database — scope.

The discipline is brutal and simple: one core workflow, done properly, and nothing else. Not "the main flow plus a few small things." The small things are never small. An admin dashboard, a notifications system, a settings page, and a second user role can quietly double a build.

I go through the whole method in what goes in version one, including the specific features that founders always assume are trivial and never are.

2. Whether you need custom code at all

A real answer that costs me work: a lot of MVPs should not be custom-built. If your product is a form, a database, and some emails, no-code will get you to market faster and cheaper, and you can rebuild later if it works.

Custom code earns its cost when you have real logic, real scale, real integrations, or something genuinely novel at the core. No-code vs custom development is the honest version of that comparison, including when starting on no-code and rebuilding later is smart and when it's a trap.

3. Who builds it

Agency, freelancer, technical co-founder, offshore team — these are genuinely different products with different failure modes, not different prices for the same thing. Agency, freelancer or technical co-founder walks the trade-offs, and the hiring guide covers the whole process from shortlist to signed contract.

4. Who owns what you paid for

If you take one thing from this entire guide: paying for code does not automatically mean you own it. In the US and many other jurisdictions, an independent contractor generally retains copyright in what they create unless a written agreement says otherwise, and software often doesn't qualify as "work made for hire" on its own.

This is the cheapest problem to fix and the most expensive to discover late — it surfaces during a funding round or an acquisition, at the worst possible moment. Who owns the source code covers what has to be written down and, just as importantly, whose name the accounts should be in from day one.

5. What "done" looks like

Agree the finish line before you start. Not a feeling — a list. A staging URL, a repo you own, a deploy that runs without the developer present, and documentation someone else can follow. The handover checklist is the version I'd hand a client.

What actually happens, week by week

Timelines slip for boringly predictable reasons. A realistic small-MVP shape looks roughly like this:

The phase founders try to skip is discovery, and it's the one that pays for itself. Every day spent cutting scope before the build saves several during it.

Two things reliably blow the timeline: feature changes mid-build, and the founder being unavailable to answer questions. A developer blocked on a decision for four days has lost four days you paid for. How long an MVP takes breaks down where the time actually goes and what to do when it slips.

Where the money leaks

Not the hourly rate. The leaks are structural:

• Building the second-best idea properly. Validating first is cheaper than building first. If nobody will pre-commit, that's information.
• Scope creep with no change process. Every "while you're in there…" has a price. If nobody names it, you pay it in schedule instead of invoice.
• Rebuilding because ownership was unclear. Losing repo access or a cloud account you can't recover means paying twice for the same product.
• Polish before proof. Design refinement on a product nobody has used yet is the purest form of premature spending.
• Hiring on price alone. A cheap build that has to be redone costs more than the expensive one you didn't buy.

Notice that four of the five are decisions, not invoices.

What to ask about the technology (and what to ignore)

You do not need to have an opinion about the framework. You do need answers to four questions, in plain language:

1. Can someone else pick this up? Mainstream tools with big talent pools mean your next developer isn't a rescue mission.
2. What happens if this works? Not "will it scale to millions" — will it survive the traffic you'd celebrate?
3. Where does the user data live, and who can reach it? Auth and data handling are the two places where MVP shortcuts turn into real liability.
4. What does it cost to run each month? Hosting, database, email, third-party APIs. Small, but it's a recurring bill you should know before launch, not after.

If you want to see how a developer actually reasons through stack choices, my tech stack decision guide is written for developers — but skimming it tells you whether the person you're hiring is thinking this way or picking what's trendy.

The order to do things in

1. Write down the question your MVP answers, and the number that means "yes."
2. Cut the feature list until only the core workflow remains. Then cut once more.
3. Decide custom vs no-code honestly.
4. Shortlist builders. Give each the identical one-page spec so the proposals are comparable.
5. Read the proposals for what's excluded, not what's included. Red flags and the questions to ask both live here.
6. Get ownership and handover in writing before the first payment.
7. Build in visible weekly increments. If you can't see it, it isn't progress.
8. Launch to real users earlier than feels comfortable.

The honest summary

An MVP is the cheapest way to find out you're wrong. That's not pessimism — it's the entire point. Every decision above is really about the same thing: spending the smallest amount of money to get real information, and keeping the option to keep going.

The founders who do well at this aren't the technical ones. They're the ones who can say no to their own feature ideas and who get ownership sorted before the money moves.

If you're at the stage where you want a second opinion on scope before you commit a budget — including an honest "you don't need custom code for this" — that's a conversation worth having. Get in touch.