Founder Tips No. 7: Your First MVP

One of the easiest ways to waste the first six months of a startup is to misunderstand what an MVP is.

Founders hear “minimum viable product” and somehow end up building user permissions, settings pages, analytics, notifications, multiple dashboards, admin panels and six different workflows.

That is not an MVP.

In my experience, the first version should test one idea and one idea only. You are not building the company yet. You are building enough of the company to find out whether the assumption underneath it is correct. In Start small I said that evidence has to exist before you go all in. Often it will tell you the original idea was wrong.

One Idea, One Dashboard, One Workflow

My rule for an early alpha is very simple:

One idea. One basic signup/login. One dashboard. One complete workflow.

Anything substantially beyond that and you are probably already overbuilding.

The important word here is workflow. Especially in B2B, doing “one thing” does not mean building one isolated button or feature. The user needs to be able to complete something meaningful from beginning to end.

B2B vs B2C was the base of this: every important Excel spreadsheet with macros can potentially hide a point solution.

Imagine a company has an Excel workbook used every month to reconcile data from several files before somebody manually prepares a final report. Do not build an entire enterprise platform around it. Your MVP might simply be one workflow:

The dashboard might show the latest processing runs, their status and any exceptions requiring attention. The user logs in, completes the workflow and gets an outcome that previously required the spreadsheet. That is enough.

You do not need advanced analytics, fifteen user roles, a mobile application, custom reporting, integrations with every enterprise system or a marketplace of additional tools. If the first workflow is not valuable, none of those things will save you.

The purpose of the alpha is to answer one question:

Does solving this particular problem create enough value that somebody actually wants to use the product?

Show, Do Not Tell

There is one problem with taking minimalism too far: users do not want to look at an empty product. You might know that it is an alpha. They do not care.

An empty dashboard with three grey boxes, “No data yet” everywhere and instructions telling the user what will eventually appear does not feel like a product. It feels unfinished.

For demos, populate it. If you are building a deal platform, show a few example deals. If you are building analytics software, show realistic charts. If you are replacing an Excel process, have a sample workflow already completed so the user can immediately understand the before and after.

Show them what success looks like. The user should not need to imagine your product working.

Show, do not tell.

This does not mean pretending that fake data is real customer data. Label demo or sample data appropriately. The point is simply that the product should demonstrate its own value without requiring a twenty-minute explanation from the founder. If you have to narrate everything the user is supposed to be seeing, the product is probably not communicating clearly enough yet.

Simple Does Not Mean Ugly

An alpha should be simple, but it should still feel credible.

I personally like the Apple approach to design: familiar typography, generous spacing, limited colours, obvious hierarchy and very little visual noise. It looks professional without trying too hard.

There is an important balance here. Minimal does not mean empty, bland or unfinished. You still need enough information on the screen for the product to feel alive. The interface should make the user think “I understand this,” not “Where is everything?” and definitely not “Why are there forty buttons?”

For the first version, familiarity is your friend. This is not the moment to invent an entirely new navigation system or demonstrate how creative your UI designer can be. The innovation should be in what the product enables, not in making the user learn how buttons work again.

Build the Alpha Around the Test

Before writing code, I would be able to describe exactly what I am trying to prove in one sentence. For example:

“We believe engineering managers will pay to automate the weekly reporting workflow currently maintained in spreadsheets.”

Good. Now build only enough product to test that:

The moment you start adding another completely different workflow, ask yourself whether it helps answer the original question. If it does not, leave it out. You can build it later.

This discipline is incredibly important because early-stage founders have almost unlimited ideas and extremely limited evidence. The evidence needs to catch up before the product expands.

Secure the Domain and Handles Early

Once I am serious enough about an idea to build the alpha, I also secure the basic digital footprint. Buy the domain. Secure the relevant social handles. Create the company profiles you are likely to need. Try to keep the naming consistent across them.

This is cheap insurance.

You do not need to spend £50,000 buying the perfect one-word .com for an idea nobody has validated yet. A sensible domain that matches the product is perfectly sufficient at this stage. But you also do not want to discover six months later, after customers know the name, that somebody else owns every useful domain and social handle associated with it.

At minimum I normally think about the primary domain and the platforms relevant to the audience: LinkedIn for most B2B companies, X where appropriate, Instagram or TikTok for consumer brands, GitHub for developer-facing products and any other channel where the name genuinely matters.

Then stop. Do not spend three weeks designing social banners, brand guidelines, merchandise and animated logos.

Secure the territory. Do not build an empire on it yet.

Your alpha website itself should be equally simple. Explain what the product does in one sentence, show what it looks like and give the visitor one obvious action to take: sign up, book a demo or try the product. Whatever your test requires. The page exists to move somebody into the experiment, not to win a design award.

Never Let One User Design Your Product

Once the alpha is working, one of the most dangerous things you can do is speak to one enthusiastic person and rebuild the entire product around their feedback. One person is an opinion. You are looking for patterns. See How not to run a startup: stay close to users, but do not let ego, or a single conversation, design the company.

My preferred starting point is around ten people who theoretically match the target audience. Give them the product, watch them use it, talk to them afterwards and write down everything they mention. Do not rely on memory. Make a table.

Suddenly feedback becomes much easier to interpret. One customer desperately requesting something does not necessarily make it a priority. Seven customers independently encountering the same problem probably does.

After each feedback cycle, I normally want to tackle the three strongest repeating problems, then run another cycle. This prevents the product from becoming a collection of features requested by whichever customer spoke to you most recently. It also forces you to distinguish between noise and signal.

Watch What They Do, Not Just What They Say

Feedback is useful, but behaviour is much more valuable.

People are polite. They will tell you something is interesting, that they can see themselves using it, that they congratulate you on the idea. None of that means very much. What matters is what happens when you put the product in front of them.

If ten theoretically relevant users try it and almost nobody comes back, that is a serious signal. If most of the feedback effectively amounts to reasons why they would never use the product, you probably have zero meaningful validation of the original idea. Do not respond by building another fifteen features. Question the assumption. If they keep asking for something else, the real opportunity may not be where you thought it was.

On the other hand, if users are actually completing the workflow, returning to the product and then complaining about particular parts of it, that is far more interesting. Now there is something to assess. Complaints from active users can be extremely valuable because they are effectively saying:

“I want this, but this part is stopping me.”

Fixing those barriers is very different from trying to convince somebody who fundamentally has no need for the product.

Put a Price on It

This is where I think founders make another major mistake. They give everything away for free.

I hate using free as the primary validation mechanism because free removes one of the most important questions from the experiment:

Is this problem actually painful enough that somebody will pay to make it disappear?

You can get enormous amounts of misleading validation from free users. Of course somebody will try something if it costs nothing. That does not mean you have a business. Fundraising do’s and don’ts is the same argument from the other side: capital is not validation. A working experiment is.

I would always want some paid option in place early. It does not need to represent your eventual pricing model. You can change the price, manually onboard the first customers, offer an early-adopter rate or, for B2B, invoice manually rather than wasting time building a sophisticated billing system.

What matters is introducing the moment where the user has to exchange something real for the value you provide. Money changes the quality of the signal.

YC has repeatedly pushed founders towards extremely simple MVPs, launching quickly and getting the product into users' hands rather than spending months completing the imagined final version. I agree strongly with that philosophy. But I would take the validation one step further:

Usage tells you that somebody wants the product. Payment tells you that the problem may be commercially valuable.

If people use the product, return to it, complain about specific problems and are willing to pay, you have something worth investigating aggressively. If people love the demo but disappear when payment is introduced, you do not yet have product-market fit.

That does not automatically mean the entire company is dead. Your pricing could be wrong, the buyer could be wrong, the positioning could be wrong or the problem may simply not be painful enough. But do not hide from the signal by removing the price. That only makes the experiment easier to pass while making the result less useful.

The First MVP Is an Experiment

The first alpha should feel almost uncomfortable in how little it contains. That is normally a good sign. You will know about all the things it could have. The customer does not. They only see whether the thing in front of them solves their problem.

Keep the experiment clean enough that you can throw it away.

Choose one assumption. Build one complete workflow. Make it look credible. Populate the demo. Secure the name. Put it in front of ten relevant users. Record every piece of feedback. Then look at what they actually do.

They may use it, return, complain because they want it to work better, and pay. That is the best case.

They may also tell you they want something else entirely: a different workflow, a different buyer, a different problem. That is not a failed MVP. That is the MVP doing its job.

The original assumption may be completely wrong. You show the product to people and discover they do not want what you built. They want the adjacent thing, the opposite thing, or nothing you are offering. With Superjoi, the first version was project financing for creators. The market pulled us somewhere else. The product was small enough to follow.

If you have already built six dashboards and an admin panel, you will defend the original idea because you spent too long on it. If the product is small, you can change direction without pretending the first version was sacred.

Those questions still matter: do they use it, do they return, do they complain because they want it to work better, will they pay? They matter far more than dark mode, twenty integrations or the perfect settings page.

Your first MVP is not supposed to prove that you can build a lot of software. It is not even supposed to prove that you should build the rest of the original plan.

It is supposed to tell you, as cheaply as possible, whether you are building the right thing at all.