Build an MVP with somewhere to grow.

There is a familiar story in software. A team builds a minimum viable product quickly. It works, customers arrive, and a year later the team is rewriting it, because the shortcuts that made it fast have become the reasons it cannot change.

The problem is not speed. The problem is which corners were cut. Some shortcuts are free to undo later. Others are load-bearing, and removing them means taking the building apart.

Our approach to a first release is simple to state: keep the features small and the foundations honest.

The MVP trap

Engineers sometimes describe decisions as two-way doors and one-way doors. A two-way door can be walked back through: a page layout, a button label, the wording of an email. A one-way door is expensive to reverse: how customers' data is separated, how identity works, how the database is shaped.

The trap is treating every decision as a two-way door because the deadline is close. An MVP should go through two-way doors quickly and often. It should go through one-way doors slowly, and on purpose.

Keep the features small and the foundations honest.

What we keep simple on day one

Everything on this list is a two-way door. If the product needs more later, each item can be extended without touching the rest.

• Features. One core workflow done properly, not five done halfway.
• Infrastructure. One application, one database, one deployment. No microservices, queues or clusters until there is a measured reason.
• Interface. A small set of components used consistently, rather than a bespoke design for every screen.
• Admin tools. Plain, fast screens built for the people who will use them every day.
• Reporting. A handful of queries that answer the questions the business actually asks.

What we design for growth from the start

Everything on this list is a one-way door. Each item costs little to get right at the start and a great deal to change later.

• Auth and roles. Even with a single role today, users have roles and permissions are checked in one place. Adding a "manager" later becomes configuration, not surgery.
• Multi-tenancy. If the product could ever serve more than one organisation, every record belongs to a tenant from day one. Retrofitting tenant boundaries into a live database is one of the most expensive changes we know.
• Billing hooks. Perhaps no payments on day one, but a clear place for plans and limits to live, so billing arrives as a feature rather than a rewrite.
• Data model. Names that match the business, constraints that enforce its rules, and no columns called "misc".
• Internationalisation. Text comes from translation files from the first screen, so adding a language later is a content task rather than an engineering project. The details are in Multilingual is a data problem.

Together these cost a few extra days at the start. Here is what that looks like in a single entity:

@Entity
public class Booking {

    @Id @GeneratedValue
    private UUID id;

    @ManyToOne(optional = false)
    private Tenant tenant;          // every record knows whose it is

    @Enumerated(EnumType.STRING)
    private BookingStatus status;   // explicit states, not booleans

    private Instant createdAt;      // history starts on day one
}

None of those fields is a feature. All of them are expensive to add once real data exists.

From dashboard to portal to product

A path we see often starts with something small. A quote form on a heating installer's website or a booking form on a tyre workshop's site produces requests. The next question is always the same: where do those requests go, and who manages them?

1. Admin dashboard. The business needs to manage something internally: bookings, quote requests, jobs, customers. We build a dashboard for staff. One tenant, two roles.
2. Client portal. Customers start asking to see their own bookings, documents or job status. Because records already carry ownership and roles already exist, the portal is a new role and a new set of screens over the same data, not a second system.
3. Product. Another business in the same industry wants the same tool. Because records carry a tenant, that business becomes a new tenant rather than a copy of the codebase. The billing hooks become plans.

Stage 1   Admin dashboard    1 tenant  · roles: admin, staff
Stage 2   Client portal      1 tenant  · + role: client
Stage 3   Product            n tenants · plans · billing

          same data model · same codebase · same deployment

Each stage is an addition. None of them is a rewrite, because the one-way doors were walked through carefully at the start.

This is not planning for a future that may never come. It is the same few decisions, made early, that let each stage happen when the business asks for it.

The boring decisions that make scaling cheap

On the backend we use TypeScript, with PostgreSQL when the data is relational, on well-documented platforms such as Next.js and Supabase. Not because they are fashionable, but because they are predictable.

Conventions. Keeping each framework's standard layout means a developer who has never seen the codebase knows where the routes, the business logic and the database queries live. That makes handover cheaper, and hiring later cheaper still.

Migrations. Every schema change is a versioned migration file in the repository. The database's history can be reviewed like code, and any environment can be rebuilt from scratch. Moving from stage 1 to stage 2 above is, at the database level, a short and readable change:

-- V12__client_portal.sql
INSERT INTO role (name) VALUES ('CLIENT');

ALTER TABLE booking ADD COLUMN client_id UUID REFERENCES app_user (id);

CREATE INDEX idx_booking_tenant_client ON booking (tenant_id, client_id);

Clean APIs. The interface talks to the backend through a versioned, documented API. The same API can later serve a mobile app, an integration or a client's own system without a second backend.

Tests where it matters. We test the guarantees first, the things that must never break, rather than chasing a coverage number.

None of these choices is interesting on its own. Together they are why the second year of a product costs less than the first.

When the timeline is tight

Every first release meets a deadline that is tighter than the list of wishes. Something has to give, and the choice of what gives is the most important scoping decision in an MVP.

It is always features, never foundations. Cutting a workflow costs nothing later: it ships in the next release, on the same base. Cutting a foundation, such as skipping roles or leaving records without a tenant, saves a few days now and costs a rewrite later.

In practice that means splitting the list of workflows, not the list of foundations:

FIRST RELEASE    one workflow, end to end · every foundation above
NEXT RELEASE     the second workflow · on the same base
LATER            reports, integrations, extra roles · as they are needed

The other lever is feedback. A first release shown to real users while it is still being built, rather than revealed at the end, changes course while changing course is still cheap.

A first release that does one workflow properly, on a base that can carry the next ten, is a better business decision than one that does five workflows on a base that will have to be replaced.

Related: see how a first release is planned and delivered →