Why We Ship Complete Products, Not MVPs

The minimum viable product has become the default approach to software development. Ship something small, get feedback, iterate. For consumer apps and experimental products, this makes sense. For operational software — the tools people use to run their businesses — it is a disservice.

When a sole trader adopts bookkeeping software, they need it to work. Not mostly work. Not work for the common cases. Work. If the software cannot handle a particular type of transaction, or a specific tax calculation, or an edge case in their business, they are stuck. They cannot wait for the next release to fix it. They need to file their tax return now, submit their VAT return now, reconcile their bank account now.

An MVP bookkeeping tool that handles basic income and expenses but cannot process CIS deductions, or mileage claims, or foreign currency transactions, is not a viable product for the businesses that need those features. It is a demo that creates frustration and forces users to maintain parallel systems — the software for most things and a manual process for everything else.

Our approach is to ship complete products. This means that when a product launches, it handles the full scope of its intended use case. For Accounted, that meant launching with MTD compliance, bank connections, receipt capture, tax calculations, VAT handling, CIS support, accountant access, and reporting. Not all at once in a single release, but all present and working before we called the product ready.

The specification process makes this possible. Because we design the full system before building, we know the complete scope from the start. We can sequence development to deliver the most critical features first while building towards completeness. We can test the full system end-to-end before launch rather than testing individual features in isolation.

Feedback is still valuable and incorporated continuously. But it is feedback on a complete product that works, not feedback on a partial product that is waiting to be finished. Users who experience a complete product provide qualitative feedback — this could be better, this is confusing, this workflow could be streamlined. Users who experience an incomplete product provide functional feedback — this does not work, this feature is missing, I cannot do my job. The second type of feedback is not insight — it is a bug report for a known gap.

The trade-off is launch timing. A complete product takes longer to build than an MVP. But an MVP in operational software often takes longer to reach viability than a well-planned complete product, because the iteration cycles include not just feature development but also the rework required when early architectural decisions prove inadequate for later features.

There is also a trust dimension. A business that adopts operational software makes a commitment. They migrate their data, change their processes, and train their team. If the software is incomplete, that commitment feels betrayed. Trust is hard to rebuild once lost. Launching complete — even if it means launching later — preserves the trust that makes long-term customer relationships possible.

This does not mean launching with every possible feature. It means launching with every necessary feature for the intended audience. The scope is defined by the specification, which is defined by the business requirement, which is defined by the users we serve. Features outside that scope are future development, not missing functionality.

Complete products are harder to build and take longer to deliver. But they are the products that people can actually rely on. In a market full of MVPs that promise to improve over time, a product that works fully on day one is a competitive advantage.