MVP development: from an idea or a spreadsheet to a working product

• ·You have a problem customers told you about, and maybe a first customer ready to try the solution.
• ·Your company runs a process on spreadsheets, forms and WhatsApp groups, and it breaks every time the team grows.
• ·You built a no-code prototype and it hit a wall: speed, permissions, integrations or price per user.
• ·You need it on the web, on phones, or both.

First versions fail on scope more often than on code. Every feature added before launch delays the day you learn what customers will use and pay for.

The shortcuts that feel harmless at the start, like shared logins, loosely organized data or payments handled by hand, get expensive once real accounts and real money are in the system.

Each month spent building features nobody asked for is a month without feedback, and often without revenue.

A spreadsheet process depends on the one person who understands it. When that person is away, the work stops or goes wrong.

Rebuilding a product after launch because the base was rushed costs more than building the base properly the first time.

• ·You put a working product in front of real users early, and decide the next step from what they do.
• ·The process runs the same way for everyone, with each person seeing the data they should see.
• ·The code, data and accounts are yours, documented so another developer or your future team can continue.

1. 01A scope document: the main workflow, what’s in version one, what waits, and how the data is organized.
2. 02The application, on the web, on phones or both, running on accounts in your name.
3. 03Logins, teams and permissions, and payments through the provider you choose.
4. 04An admin area for what your team needs on day one.
5. 05Automated tests on the parts that handle money and data, and backups configured.
6. 06Error alerts, so problems reach me or your team before customers report them.
7. 07Documentation written for the next developer.

1. Step 1: 01

   Short, and the most important step

   Scope

   We cut the idea down to the smallest product someone will use and pay for, and write it down.

2. Step 2: 02

   Early

   Foundations

   Accounts, data structure, logins and publishing come first, so every feature after that goes straight to a real address you can test.

3. Step 3: 03

   Most of the project

   Main workflow

   The part your customers need, delivered in steps you can click through on a preview link.

4. Step 4: 04

   Short

   Launch

   Payments, first access for users, alerts and the first real accounts.

5. Step 5: 05

   As agreed

   After launch

   Fixes and next features based on what users do, or a clean handover to your team.

• ·Someone who makes product decisions and answers questions quickly, with at least one check-in a week.
• ·Examples of the real data and of how the people who’ll use it work today, including the spreadsheet if there is one.
• ·Accounts in your company’s name for hosting, domain, payments and email, or the willingness to create them.
• ·The list of what must be in version one, and the willingness to cut the rest.

A product I’ve worked on for years, and open-source work you can inspect.

• Maqnar (maqnar.io)External site

  A platform for agricultural fleets: tractors, harvesters and implements tracked in real time, maintenance kept on schedule and machine data turned into reports. I’ve worked on it since 2024.

• COSMQExternal site

  An open-source mobile app I built for iOS, Android and the web that connects straight to PostgreSQL and MySQL databases.

How much does it cost to build an MVP?

The price comes from the scope, which is why the scope comes first. Send a short brief, we talk through the main workflow, and you get a written proposal with the price of that first version before any work starts.

How long does it take?

Almost entirely a function of scope. A tighter first version goes live sooner, which is why the scoping step cuts hard. The proposal gives dates for the agreed scope and names what would change them.

We already built part of it, or we have a technology in mind. Is that a problem?

No. If there is existing code or a no-code prototype, I review it first and recommend continuing, reworking parts or starting over, with the reasons in writing. If you have no preference, I pick tools that are easy to hire for later.

I already have a developer. Can you work with them?

Yes. I can set up the foundations and the main workflow and hand over to them, or work alongside them on the parts that need more hands. The code lives in your repository, so nobody gets locked out.

What if the product doesn’t take off?

Nobody can promise that a market will buy, and I don’t. What the process controls is how much you spend to find out: a small first version, in front of real users early. The code, data and documentation stay yours whatever you decide next.