Insights · 10 min read
Define the MVP before you talk to developers and your quotes become comparable, your build gets shorter, and you stop paying for features nobody asked for.
By GGP Editorial
Founders usually hire developers too early and define the MVP too late. They have a vision, they get three quotes that differ by a factor of three, and they realize the problem is not the developers; it is that nobody knows what the first version actually is.
I run a software development company, and the projects that go well have one thing in common before they ever reach us: the founder already decided what the MVP is and is not. This article is that decision, broken down so you can make it before you spend a dollar on a build.
The order matters more than most founders think. When you talk to developers before you have defined the MVP, you are asking them to both scope and guess. They make different assumptions about what "first version" means, and you get quotes you cannot compare. When you define the MVP first, you hand every vendor the same scope, and the quotes become a like-for-like comparison.
There is a second reason. Defining the MVP forces you to decide what you are actually building, and that decision is yours, not the vendor's. A developer can tell you how to build a thing. Only you can decide which thing is worth building first. Get the order right and you save money and months.
The MVP starts with a job someone needs done, not with a feature list. Write down the one problem you are solving and the one metric that tells you whether you solved it. Not five metrics. One.
For example, instead of "a platform for small landlords to manage properties," write "a landlord can collect rent and track who has paid, without a spreadsheet." The metric might be how many landlords complete their first rent collection without contacting support. That sentence is your compass. Every feature you consider either moves that metric or it does not.
This is the same discipline we describe in what to build first and what it costs: a clear problem and a clear success signal are the difference between shipping something useful and shipping a demo nobody asked for.
Once you have the problem and the metric, write down every feature you can think of. Everything. Then sort it into three columns: must have, should have, and later.
The must-have column is the only one that ships in the MVP, and it should be small. If a feature is not required for the one metric you chose, it goes in the later column. This sounds obvious and is surprisingly hard, because every feature feels essential to the person who dreamed up the product. The test is simple: can the user complete the core job without it? If yes, it waits.
A useful rule of thumb: if your must-have list is longer than about seven to ten items, you are probably still listing features instead of jobs. Group them. "Sign up," "log in," and "reset password" are one job, not three features.
Personas are where founders lose a week. You do not need a persona deck for an MVP. You need one real user and one scenario: who they are, what they are trying to do, and what success looks like for them.
Write it as a single sentence. "A restaurant owner who runs two locations wants to see daily sales per location on their phone by 9am." That is enough to guide the build and to say no to everything that does not serve that scenario. When a feature request comes up, the question is whether it helps this user in this scenario. If it does not, it waits.
The MVP does not need a full requirements document. It needs a one-page scope that covers the problem, the one metric, the must-have features, the one user and scenario, and what "done" means. That page is what you send to every vendor.
You can expand it later. The one-pager is enough to start a real conversation and enough to keep the build honest. If you want the full version of what a buildable requirements document contains, we have a guide to writing a software requirements document that covers the longer form for when the MVP graduates into a full product.
Before you hire anyone, write down the acceptance criteria for the MVP: the specific things that must be true for you to call it shipped, and the specific number you will watch after launch to decide whether to keep going.
"Done" might be that a user can sign up, complete the core job end to end, and the data is stored where you can see it. "Success" might be that twenty users complete the core job in the first month, or that half of them come back in week two. These numbers are guesses, and that is fine. The point is to have a number, because without one you cannot tell whether the MVP worked, and you keep building features instead of learning.
This matters for the vendor relationship too. When you hand a team clear acceptance criteria, you get a real estimate and a real handover. When you do not, you get a build that "is almost done" for weeks. The same logic applies to the contract: a fixed price vs time and materials decision is much easier to make when the scope is this concrete.
When you do sit down with a vendor, you should have a small stack of artifacts ready. You do not need all of them perfect; you need them clear.
| Artifact | What it contains | Why it matters |
|---|---|---|
| One-page scope | problem, metric, features, user, done | Gives every vendor the same brief |
| Must-have list | the features that ship in v1 | Prevents scope creep from day one |
| One user and scenario | who and what, in a sentence | Grounds every feature decision |
| Success metric | the number you watch after launch | Tells you if the MVP worked |
| Acceptance criteria | the concrete definition of done | Makes estimates and handover real |
None of these requires a consultant or a tool. They require a few focused hours of thinking, and they are the highest-value hours you will spend on the whole project. The alternative, which we see all the time, is a founder who hands over a vision and a feature wishlist, then wonders why the quotes vary so much and the build drags.
Overbuilding is the default, not the exception. The three places it shows up most are the features list, the design, and the admin.
The features list overbuilds because every idea feels essential before a real user touches the product. The design overbuilds because founders polish screens that will change after the first five users. The admin overbuilds because a custom dashboard with ten reports feels like progress but ships nothing a customer can use.
Each of these adds weeks and money without adding learning. The discipline that fixes all three is the same: does this help the one user complete the one job in a way that moves the metric? If not, it is a later. We have written a whole piece on shipping less and learning faster, and the core idea is that a smaller MVP teaches you more than a larger one.
The moment you hand three vendors the same one-page scope, something changes: their quotes start to converge, and the differences that remain are about team, seniority, and approach, which is what you actually want to compare.
Before that, you are comparing assumptions. One vendor quotes for a two-month MVP with one feature; another quotes for a six-month build with ten. Neither is wrong about the build; they are wrong about your scope, because you had not defined it. The definition is what turns a vendor selection from a gamble into a decision.
When you get to the point of choosing a team, the same clarity helps there too. Our guide to choosing a software development company covers the questions to ask, and they land much harder when you already know exactly what you are building.
GlobeSoft is a China-based software company with a global delivery model, 40-plus engineers, and more than 300 delivered projects. We work with founders to define the MVP before we quote the build, because a defined MVP is in everyone's interest: it gives you a like-for-like comparison and gives us a scope we can actually estimate.
Our stack runs on Java, Spring Boot, Spring Cloud, Go, Node, Python, Vue, and React, with MySQL, Redis, and Nginx underneath, and we have taken products from first MVP through to paying customers. Our clients own their source code, and we work in English and Portuguese across time zones.
If you have an idea and are not sure what the first version should be, that is a conversation, not a contract. Tell us the problem, the user, and the metric, and we can help you cut it down to a must-have list and a realistic plan before you commit to anything.
How long does defining an MVP take?
A focused founder can produce a one-page scope in a few days of part-time work. It is not a big time investment, and it pays for itself by preventing months of rework and by making your quotes comparable.
Do I need a developer to define the MVP?
No. Defining the MVP is a product decision, not a technical one. A good vendor can help you refine it, but the core decisions, what problem, what user, what metric, are yours to make.
What if I get the MVP wrong?
That is expected, and it is the point. The MVP is a bet you test cheaply. The one-page scope and the success metric exist so you find out you were wrong in two months for a small cost, rather than in twelve months for a large one.
How few features can an MVP have?
As few as one core job, done end to end. Some of the best products we have seen started as a single workflow with a signup. The test is whether a real user can complete the core job and whether you can measure it.
Does defining the MVP first slow the project down?
The opposite. The time you spend defining the MVP comes out of the build, not on top of it. Clear scope is the single biggest reason a project ships on time instead of dragging.
Defining the MVP before you hire developers is the cheapest insurance you can buy on a software project. It makes your quotes comparable, your build shorter, and your first version something people actually use. If you want help turning an idea into a one-page MVP scope, get in touch.
Tell us what you are building and where you are today. We typically reply within 24 hours.
