What a first version of your product should include

A first version should be embarrassing in the right places. If nothing about it makes you wince, you built too much, and you paid for it in time you did not have.

"MVP" gets used loosely. Here it means the smallest thing that lets a real user do the one job your product exists for, so you can find out whether they want it. It is a test, not a cheaper copy of the finished product.

Start with one job

Write the product's purpose as a single sentence with a person, an action and a result. "A clinic receptionist books a follow-up in under a minute." "A distributor's customer reorders last month's order." If the sentence needs the word "and", you have two products.

Everything in the first version either serves that sentence or waits. This is harder than it sounds, because every feature has a reasonable argument for being included.

What a first version should include

The core action, done properly. Not faked, not a mock-up. If the job is booking, a booking has to actually happen and be recorded.

A way for you to see what happened. Even a plain list of records or a spreadsheet export. Without it you cannot learn from the first users, which defeats the point.

Basic login, only if the job needs it. If people can use the product without an account, do not make them create one yet.

Real data for a handful of real people. Five users who need this beat five hundred who are curious.

What it should leave out

Admin dashboards. You can change things directly in the database or a spreadsheet for the first few weeks. It looks unprofessional and it costs almost nothing.

Payments, unless payment is the test. If you are checking whether people want the thing, an invoice sent by hand tells you as much. If they will not pay by bank transfer, they will not pay by card.

Roles and permissions. One kind of user until a second kind actually shows up.

Every platform. A mobile web page that works is a fair first version. Whether a native app is worth it is a separate question we cover in app or website.

Integrations with everything. Connect the one system the job cannot run without. The rest can be a manual step for now. Where automation should start applies here too.

If a feature is not needed to learn whether people want the product, it is not part of the first version. It is part of the second, if there is one.

The case where you should not build yet

Sometimes the cheapest test is not software. If the process can be run by hand, with a form, a spreadsheet and a WhatsApp group, run it that way for a month. You learn more from doing it manually than from a build, and it costs a fraction. If nobody uses the manual version, software will not fix that.

We would rather you do this than pay us to build something to be told it was unneeded. It costs us a project. It saves you the money, and you may come back with a much sharper brief, which makes any build go better.

Building it so it can grow

A small first version does not have to be a throwaway. Keep the data clean, keep the code simple, and write down what you deliberately left out. Then version two is an addition, not a rewrite.

What does go wrong is a rushed build with no thought about where the data lives. Users' records are the one thing you cannot easily rebuild. Get that part right even when everything around it is rough.

A sensible way to begin

Write your one-sentence job. List everything you think the product needs, then cross out everything that does not serve the sentence. What is left is your first version, and it is probably smaller than you feared.

If you want a second opinion on where to draw that line, that is what custom software development conversations often start as, and the cost calculator will show what size of project you are describing before you talk to anyone.