Validating the regulation is not validating the customer
We built Making Tax Digital filing software against a compulsory obligation with a hard deadline, and it still did not reach launch. The mistake was treating a mandate as evidence of demand.
8 August 2026 · 3 min read · Sabia Solutions
There is a category of product idea that feels safe because the law is doing the selling. The obligation is statutory, the deadline is published, the affected population is countable. Nobody has to be persuaded that the problem exists.
We built one of those. Easy Tax Digital is Making Tax Digital filing software for sole traders and landlords, engineered against the live HMRC API surface, and its launch was deferred. The code works. The commercial case for taking it to market did not.
What we actually validated
We validated that people would need to file quarterly. That part was never in doubt, and confirming it took no work at all, which should have been the warning.
What we did not validate was who chooses the software. For a large share of that population the answer is an accountant or a bookkeeper who already has a product, already has it configured across a client book, and has no reason to move. The buyer is not the person with the obligation. We had spent months on the person with the obligation.
A mandate tells you that a purchase will happen. It tells you nothing about who makes it, what they compare it against, or what would make them switch. Those are separate questions and they are the ones that decide whether you have a business.
The sequencing error underneath it
There is a second mistake in that build and it is more ordinary. We built breadth before we built approval.
The codebase has payroll, invoicing, timesheets and bank import sitting alongside the filing path. None of it mattered, because none of it could reach a customer until the core submission could reach HMRC in production, and that requires passing a recognition process we never entered. The correct order was the narrowest filing product that could clear recognition, then everything else, in whatever order customers asked for it.
The reason we did not do that is worth naming honestly. Building features is legible progress. You can see it accumulate. Working through a recognition regime is slow, unglamorous, and produces nothing you can show anyone until it is finished. Given a choice between the two, a build team will drift towards the visible one unless somebody stops it.
What we would ask now
The questions we now put to our own ideas, and to anyone who asks us about theirs:
Who signs, and what are they using today? Not who has the problem. Who has the budget line and the authority. If those are different people, that gap is the product’s main risk, not a detail.
What is the smallest thing that could take money? If the answer involves a certification, an integration or an approval, that is the project. Everything else is a queue behind it.
What would have to be true for this to fail? Write it down before you start, so that when it happens you recognise it as the thing you predicted rather than a surprise to be worked around.
Why it is on the site
Easy Tax Digital is in our portfolio with its status stated plainly, because the alternative is a portfolio that only contains work that went well, and that is a sales page.
It is also the single most useful thing we own for the sort of work we do. A firm that has confused a regulation with a market, at its own cost, is better placed to spot somebody else doing it than a firm that has only read about it.
Written by
Sabia Solutions
Written by whoever did the work, reviewed before it goes out. If you want to take issue with any of it, hello@sabiasolutions.co.uk reaches us.