The first version of your product (MVP): how to build one you can actually sell

What a first version is, and what it is not

The first version of a product, known in the industry as an MVP, is the smallest version a first customer will pay for. It does one thing end to end: the customer arrives, understands what they will get, pays and receives what they paid for.

It is not a mock-up or a prototype for show. A mock-up can be shown in a meeting but cannot be sold. A prototype works on one screen and breaks on the second. A first version works for real, in a narrow scope.

Nor is it the whole product you have in your head. The features in your notes come later, if customers want them. Most never will, because customers will want something else.

One thing end to end instead of everything at once

A common mistake with a first version is building ten features to 60 percent. The result looks rich, but the customer never reaches the end anywhere. Sign-up works, payment does not, the report shows without half the data.

So I start with one question: what exactly will the first customer pay for, and what path do they have to take to get it. I build that one path in full: from the page they land on, through the account and the payment, to the thing they bought. Everything off that path waits.

The detailed list of what a first version must have and what can wait is on a separate page. In short: the core of the product, accounts, payments with invoicing, an admin panel and a sales page. An app in the stores, several languages and a referral programme can wait.

Two roads to a first version

A new product is built from scratch while its customers are still being found. The first version has two jobs: sell to the first customers and show an investor that the product works for real.

An existing company adds a new online service to what it already sells. It has customers and a brand, and lacks a product that sells itself without a phone call or an email. Here the first version has to fit the rest of the company from day one: the same invoices, the same address, the same customer service.

I work the same way in both cases. What differs is who makes the decisions and how quickly results have to show.

Scale differs too. Polskill is a two-sided recruitment platform in three languages, with chat between employer and worker: two sets of screens, matching and a conversation between the sides in one product. A scope that size can still be split into stages, each ending with a working part.

How the build runs

1. A conversation about the product. You tell me who the customer is, what they pay for and what they do from arriving to paying. You do not need a specification. I ask the questions that usually surface only halfway through a build.
2. The scope of the first version in writing. I write down that one customer path step by step and split the product into modules, meaning self-contained parts: accounts, payments, the core, the panel. You get the order, the timing and the prices.
3. Monthly stages. Each month ends with a working part you can click through and show. After the first month you usually have something to present to an investor, not mock-ups.
4. Start of sales. The product runs on your server or with a provider we choose together, with a domain, payments and backups. The first customers pay.
5. Changes after the first customers. What they say goes into the next stages. Features nobody asks for do not get built.

That is how mScanner works, a product sold without a subscription: the customer pastes a link to a property listing, pays and gets a report about the flat, invoice included. One path from arriving to paying, built in full.

The code and credentials are yours

The code, the documentation and every credential pass to you with each stage you pay for, not only after the last invoice. That matters at two moments.

When you talk to an investor. The investor asks whether the product can run without its author and who owns what they are putting money into. “It is all ours, here is the documentation” closes that topic.

When you change vendors or hire your own team. Another developer takes over the product with its documentation and does not have to call me for a password. If you would rather I stayed with the product after launch, we agree how much care you need. At the start-up DepotRacer I have been responsible for the design and build of the whole system since 2026.

What it costs and how to choose a developer

You pay for a stage after accepting it, usually monthly, not up front for the whole. If the money runs out halfway, you keep a working part that can be shown and taken further with anyone. What drives the cost and how to keep it under control is on the page how much a first version costs.

Before you choose a developer, ask them a few questions about code, credentials, billing and what you get after the first month. I have collected those questions and the warning signs on the page how to choose a developer. The scope of what I do on a product is described under websites and applications, in the section on products from scratch.

Describe in the form below who your product’s customer is and what they pay for. I will get back to you with questions or a proposed scope for the first version.