What MVP Should Mean When You Have Three Months of Runway

You have an idea, some savings or a small cheque, and roughly three months before you need either paying customers or more money. Someone has told you to build an MVP, and every developer you speak to hears something different when you say the word. This post is about what an MVP should mean for a founder with three months of runway: the smallest product that proves a customer will pay, built so that those first customers are not thrown away when you grow.

The word has stopped meaning anything

To one developer, an MVP is the full product built quickly and badly. To another, it is a landing page with a sign-up form. To a founder under pressure it often becomes a list of everything a competitor has, minus the polish. None of these fit three months.

The definition we use is narrower. An MVP is the smallest thing that lets one real customer get one job done, end to end, and lets you take money or a firm commitment for it. Minimum is about scope. Viable is about the customer's job actually getting done. You can cut polish, options and screens. You cannot cut the job.

Start from the reason customers pay

Before any feature list, write one sentence and keep it visible for the whole three months:

[Customer] pays us because [job] is now faster, cheaper or possible at all.

Take a delivery business as an example. Its customers do not pay for an app. They pay because an order reaches the right rider within minutes instead of being phoned around. So the dispatching flow is the product. Invoicing, ratings, promotions and a merchant dashboard are all real needs, and none of them are the reason money changes hands.

Now write down every feature you have in mind and sort each one into three columns:

1. The job. The customer cannot get what they pay for without it.

2. Makes the job possible. Login, a way to pay, a way to reach you when something breaks.

3. Nice. Everything that makes the product look finished rather than work.

In our experience the third column is always the longest, and it is the one founders find hardest to leave alone. Your first release is columns one and two. Column three waits until a paying customer asks for something in it.

What to cut, and what you cannot cut

Scope cuts that rarely hurt a first release:

• An admin dashboard. A spreadsheet fed by a database export does the job for the first few dozen customers.

• More than one notification channel. Pick SMS, WhatsApp or push, not all three.

• Roles and permissions. One admin account is enough until you have staff.

• Native apps for both iOS and Android. Pick one platform, or ship a web app that works on a cheap phone.

• Analytics screens, settings pages, multiple languages, dark mode, onboarding tours.

Cuts that look like savings and are not:

• The core job working end to end on the phones and networks your customers really use, not on your laptop over office Wi-Fi.

• Taking money. Even if the first version records a mobile money reference by hand, the moment of payment must exist in the product.

• Basic security: passwords stored properly, HTTPS everywhere, a nightly backup that someone has actually restored once.

• A simple record of what users do. Not a dashboard, just events in a table you can query when you need to know.

• A way for users to reach a human. A WhatsApp number inside the app has saved more early products than any feature.

The test for any cut is the sentence from the previous section. If removing something breaks the moment the customer gets what they paid for, it stays.

Plan the three months backwards

Three months is about twelve working weeks. Start from the end and work back, because the end is the only date that matters:

1. Week 12: paying customers are using the product without you standing next to them.

2. Week 10: real users are on it. Friends and family do not count; they forgive everything.

3. Week 6: the core job works end to end. It is ugly, and that is fine.

4. Week 2: the scope, the platform and the data model are decided and written down.

5. Week 1: the brief is done. A one-page brief a developer can quote is enough; we wrote up how to write one.

Ask for a working demo every week from week two, on a real phone, not a screen recording. The most useful check comes at week six. If the core job does not work by then, the scope is still too big. Cut again. Do not extend the deadline, because the deadline is your bank balance.

Minimum does not mean throwaway

The fear behind most over-scoped MVPs is that a small first version will have to be rebuilt from scratch. In practice, what gets rebuilt is the user interface and the features. What survives, and what hurts when it was done carelessly, is the data.

Spend your care on three things and let the rest be rough:

• The core records. Customers, orders, payments, or whatever your job is made of. Get their names and relationships right now; renaming them later touches everything.

• Payment records. Every transaction with its reference, amount, currency and status. You will reconcile against them for years.

• Identity. In most West African markets a phone number is the account. Decide that early and do not make people invent passwords for a product they have not yet trusted.

Use boring technology your developer already knows well. Host on one small server with monitoring and backups rather than a cloud setup designed for scale you do not have. A web app that loads on an entry-level Android phone over a weak connection is often a better first release than a store-listed app, and it saves the weeks that app store reviews and device testing take.

What to do next

Three things you can do this week, before you spend anything:

1. Write the one sentence. If you cannot finish it, the product is not ready for a developer yet.

2. Sort your feature list into the three columns and share only the first two.

3. Pick one platform and one payment method for the first release, and write both down.

If you want a second opinion on the scope before you commit your runway, send us the sentence and the sorted list. Talk to us and we will tell you what we would build in twelve weeks and, just as usefully, what we would leave out.