VladislavSoftware Engineer

How I approach building an MVP

· 2 min read · #mvp #product #process

Most first versions I'm asked to build are too big. Not too ambitious — too big. The idea is usually fine; the problem is that it arrives with fifteen features attached, and only two of them decide whether the thing works at all.

So the first conversation is rarely about technology. It's about finding the one loop the product lives or dies on.

Find the loop

Every product has a core loop: a user arrives, does something, gets value, comes back. For a booking product it's find a slot → book it → show up. For an internal tool it's import data → fix it → export it. Everything else — settings pages, admin panels, notification preferences — supports that loop or delays it.

I write the loop down in a sentence. If it takes a paragraph, we haven't found it yet.

Build the loop, fake the rest

Once the loop is clear, the plan is boring on purpose:

  • Build the loop end to end, with real data and real deployment.
  • Stub or manually operate everything around it. Emails sent by hand are fine at ten users.
  • Keep one environment the client can open at any time.

A stakeholder who can click through the real thing on Tuesday gives better feedback than one who reads a spec for three weeks.

Choose dull technology

For a first version I want tools I can debug at 2am: a relational database, a typed language, a hosting platform that redeploys on push. Interesting infrastructure is a cost you pay before you know whether anyone wants the product.

// The boring version is usually the correct one.
async function bookSlot(userId: string, slotId: string) {
  return db.transaction(async (tx) => {
    const slot = await tx.slots.lockById(slotId);
    if (slot.takenBy) throw new SlotTakenError(slotId);
    return tx.slots.assign(slotId, userId);
  });
}

That transaction is the kind of thing worth getting right early. A queue system for a product with no users is not.

Ship, then decide

The point of an MVP isn't to be small. It's to be decisive — to produce information you couldn't get from a document. After launch there are usually three honest outcomes: people use it and ask for more, people use it differently than expected, or nobody uses it.

All three are useful. Only the last one is expensive if you spent six months first.

← All writing