Scoping an MVP: how to ship v1 in weeks without painting yourself into a corner

A minimum viable product has one job: to test whether a specific group of people will use or pay for a specific solution to a specific problem. Everything that does not serve that test is scope that delays the answer. Yet MVPs routinely balloon into six-month projects with admin panels, role hierarchies and settings pages that nobody has asked for.

The opposite failure is just as real. Teams cut so aggressively that the first version cannot evolve, and success triggers a rewrite at exactly the moment they should be doubling down. The skill is knowing which corners can be cut safely. This is the framework we use when scoping v1 with founders.

Start with the riskiest assumption, not the feature list

Feature lists are the wrong starting point because every feature looks necessary in isolation. Start instead by writing down the assumptions your business depends on, then rank them by how uncertain they are and how fatal it would be if they were wrong.

• Problem risk: do target users actually have this problem, and is it painful enough to change behaviour?
• Solution risk: does our approach solve it better than what they do today, including spreadsheets and doing nothing?
• Channel risk: can we reach these users at a reasonable cost?
• Technical risk: can we build the hard part at all, at acceptable quality and cost?

Your MVP should attack the top one or two. If the riskiest question is whether people will pay, a landing page, a concierge service and a payment link may answer it faster than any software. If the riskiest question is technical, such as whether an AI pipeline can reach acceptable accuracy on real documents, then a narrow prototype of that pipeline is the MVP, and the user interface can be minimal.

Define one core loop and cut everything else

Describe the single path a user takes to get value, in one sentence. A clinic manager uploads a supplier invoice and gets it reconciled against the purchase order. A sales rep pastes a company name and receives a researched brief. That sentence is your core loop. Every screen and endpoint in v1 must be on it or directly required to support it, such as sign-in.

Then sort everything else into three buckets:

1. Build properly: on the core loop and hard to change later.
2. Fake or do manually: needed occasionally, but a human can do it behind the scenes for the first users. Onboarding, report generation, account changes and refunds are classic examples.
3. Defer: everything else. Write it down in a later list so stakeholders know it is parked, not forgotten.

Cut scope, not foundations

The painted-into-a-corner problem comes from cutting the wrong things. Some decisions are cheap to defer and some become exponentially more expensive with every week of production data and every new feature built on top. We sort them like this.

Get right from day one

• Data model and tenancy. Decide early whether data belongs to users or to organisations. Retrofitting multi-tenancy onto a single-user schema touches every query.
• Authentication. Use a proven provider or library. Rolling your own is slower and riskier, and migrating users later is painful.
• Identifiers and money. Use UUIDs or similar for public ids, store currency amounts as integers in minor units, and store timestamps in UTC.
• A relational database. Postgres covers relational data, JSON documents, full-text search and queues well enough for most early products.
• Deployment and backups. Automated deploys from the main branch and tested database backups. These take a day to set up and save weeks later.
• Basic security. Secrets out of the repository, authorisation checks on every endpoint, input validation at the boundary.

Safe to defer

• Microservices. A well-structured modular monolith is faster to build and easy to split later.
• Granular roles and permissions beyond owner and member.
• Self-serve billing management, when invoices or a hosted checkout page will do.
• Admin dashboards. Use a database GUI or a lightweight internal tool at first.
• Horizontal scaling, multi-region deployment and elaborate caching.
• Native mobile apps, when a responsive web app can validate the loop.

A simple example of a cheap decision that saves a migration later: put tenancy in the schema even if v1 has exactly one user per organisation.

CREATE TABLE organisations (
  id         uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  name       text NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE memberships (
  organisation_id uuid NOT NULL REFERENCES organisations(id),
  user_id         uuid NOT NULL REFERENCES users(id),
  role            text NOT NULL DEFAULT 'owner', -- owner | member, expand later
  PRIMARY KEY (organisation_id, user_id)
);

-- Every business table carries organisation_id from the start.
CREATE TABLE invoices (
  id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  organisation_id uuid NOT NULL REFERENCES organisations(id),
  amount_minor    bigint NOT NULL,  -- money as integer minor units
  currency        char(3) NOT NULL,
  created_at      timestamptz NOT NULL DEFAULT now()
);

This costs an extra table and a column. Adding it later, after customers ask to invite colleagues, means migrating every row and auditing every query for data leaks between accounts.

Time-box the build and work backwards

Fix the time and let scope flex, not the other way round. Pick a launch date a few weeks out, then plan backwards: the final days for testing with real users and fixing what they hit, the days before that for the core loop end to end, and the first days for foundations such as auth, the data model and deployment. If something does not fit, it moves to the later list rather than pushing the date.

Two habits keep the time box honest. First, get the core loop working end to end, however roughly, as early as possible, and then improve it. A polished half-loop teaches you nothing. Second, demo working software every week to the people who will judge the product. Scope disagreements surface quickly when everyone is looking at the same screen.

Instrument the answer you are looking for

An MVP that ships without measurement has only tested whether you can ship. Before launch, write down what result would count as success or failure for your riskiest assumption, and make sure you can see it. That usually means a handful of product events on the core loop, such as signed up, completed first action and returned within a week, plus a direct line to early users for qualitative feedback. Talking to ten users will often tell you more than any dashboard at this stage.

// A tiny, typed event helper is enough for v1. Swap the sink later.
type ProductEvent =
  | { name: "signed_up"; orgId: string }
  | { name: "invoice_uploaded"; orgId: string; invoiceId: string }
  | { name: "invoice_reconciled"; orgId: string; invoiceId: string; automatic: boolean };

export async function track(event: ProductEvent) {
  await db.query(
    "INSERT INTO product_events (name, org_id, properties) VALUES ($1, $2, $3)",
    [event.name, event.orgId, JSON.stringify(event)],
  );
}

Plan for v2 without building it

You do not need to build for scale, but you should keep the path open. Organise code by domain rather than by technical layer, keep business logic out of route handlers and UI components, and write tests for the core loop so you can change it with confidence. Leave short notes on deliberate shortcuts so the next person knows which ones were intentional. When the MVP works, these habits let you extend it instead of starting again.

Key takeaways

• Scope from your riskiest assumptions, not from a feature wish list.
• Define one core loop; build it properly, fake the occasional work, defer everything else.
• Cut features freely, but get the data model, tenancy, auth, money handling, deploys and backups right from day one.
• Fix the launch date and let scope flex; get the core loop working end to end early.
• Decide in advance what success looks like and instrument it before launch.

We help founders scope and ship first versions with production-grade foundations across backend and frontend. If you have an idea to validate, let's talk.