A first release small enough to ship and large enough to be used

A small team with domain expertise in energy reporting and a product idea validated through consulting work they were already doing manually for clients. They had a long feature list, a limited runway, and no agreed first release.

The engagement started as discovery specifically to answer one question: what is the smallest thing worth paying for?

Discovery mapped the workflow the founders were already performing manually for clients, end to end, including every step done in a spreadsheet. The first release was then defined as that one workflow, complete – data import, validation, calculation, review and export – rather than a shallow version of five workflows.

The scoping principle we applied: a first release should do one job properly rather than several jobs partially. A narrow product that finishes a task is purchasable; a broad product that finishes nothing is a demo.

Everything deferred was written down as deferred, with the reasoning, so the roadmap was a record rather than a set of dropped promises.

The interface was designed around the review step, because that is where trust in the product is won or lost. If a user cannot see how a number was derived, they will rebuild it in a spreadsheet to check – and once they do that, the product has failed regardless of its other features.

Every calculated value is traceable to its inputs in the interface. Empty states, partial-data states and error states were designed alongside the ideal state, because a data product spends most of its early life in one of the first three.

A design system with tokens, components and documentation was delivered so the client team could build new screens consistently after handover.

Multi-tenancy, organisations, roles and record-level permissions were built first, before any feature. This is unglamorous and it is the decision that most reliably determines whether a SaaS product can grow.

Test coverage was concentrated on the calculation engine, where a silent error would be worse than a crash: a wrong number sent to a client is a business problem, and an obviously broken page is only an inconvenience.

Usage analytics were implemented as part of the first release, with a documented event taxonomy tied to the workflow steps – so the question "where do users stop" had an answer from the first week rather than after a later instrumentation project.

The team went from a feature list to a product in front of users. The narrow first release meant the roadmap that followed was informed by observed behaviour rather than by internal opinion.

The handover was the other objective. The client team took over development with documentation, a design system, test coverage on the critical paths and a deployment pipeline they can operate, with us retained for continuous development on the parts they choose not to own.