An MVP is not a small version of everything. It is all of one thing.
That distinction decides whether the first release ships in months or drifts for a year. But there is a second distinction that matters just as much: some decisions are cheap to change later, and three are not.
The three you cannot cheaply reverse
The tenancy model. Shared schema with a tenant column, a schema per tenant, or a database per tenant. Each has genuine consequences for isolation, cost, backup granularity, compliance posture and query complexity. Changing it later is close to a rewrite, because every query, migration and backup procedure assumes it.
The permission model. Not "we'll add roles later". Whether permissions attach to users, to memberships, or to resources; whether an organisation can contain teams; whether a user can belong to several organisations. Retrofitting a real permission model into a product built on if (user.isAdmin) means touching every endpoint.
The data model's core relationships. Specifically: what owns what. If a document belongs to a user and you later need it to belong to an organisation, every reference, every access check and every migration is affected.
Everything else — the UI, the feature set, the billing tiers, the onboarding flow, even the framework — can be changed later at reasonable cost. These three cannot.
Build the boring layer first
The interesting part of a product is the part that solves the customer's problem. The part that lets you sell it is authentication, organisations, roles, invitations, billing, limits and admin tooling.
Teams build the interesting part first, demo it successfully, and then discover that shipping it to a second customer requires two months of unglamorous work nobody scoped.
Build the boring layer first. It is genuinely less enjoyable, and it is the difference between a prototype and a product.
The admin tooling deserves specific mention, because it is skipped most often. Without impersonation, audit logs, usage views and safe manual overrides, your support process becomes "a developer opens the production database". That is a security problem, an availability problem and a scaling problem simultaneously, and it gets worse with every customer.
What "smallest sellable version" actually means
The test is not "would this demo well". It is: could a real customer use this in production, and could you invoice them for it without embarrassment?
That reframing usually cuts scope hard. It also usually adds a few things teams wanted to defer — because a customer who cannot reset their own password, or cannot add a colleague, or cannot see what they are being charged for, is not a customer you can invoice.
A useful exercise: write the onboarding sequence a new customer goes through, step by step, with no developer involved at any point. Whatever that sequence requires is in scope. Whatever it does not is negotiable.
Instrument from the first customer
Activation, usage and churn signals need to exist from day one. Retro-fitting analytics after launch means the earliest and most informative data — how your first ten customers actually behaved — is simply gone.
The minimum: what did each account do in its first session, what did it do in its first week, and which accounts stopped doing anything. Three questions, answerable from the start, worth more than an elaborate dashboard added in month six.
Write down what you deferred
Every architectural decision that was postponed should be recorded with two things: what was deferred, and what it will cost to revisit.
This document is the single most valuable artefact you hand to whoever maintains the product next — including your future self. Code shows what was built. It never shows what was considered and rejected, or why, or under what constraint. Six months later, that context is the difference between a confident change and an archaeological expedition.
And be willing to find out you were wrong
The point of a small first version is to learn cheaply. If nobody wants the product, the MVP proves it in months rather than after eighteen months of platform work.
That is a successful outcome, not a failed one — though it rarely feels like it at the time. The failure mode is building the full platform first and discovering the same thing later, having spent ten times as much to learn it.