Why Devalo Is Taking the Long Road to Launch

A week ago I wrote about the final sprint to production. Since then I have done something that every founder tells you not to do. I pushed the launch date.

Not by a day. By months.

The reason is simple and entirely unglamorous. Devalo is a platform that handles Australian small business data — invoicing, customer records, GST-accurate tax invoices, client communications. To issue a valid tax invoice in this country you need a registered Australian Business Number on it. Without one, the invoice is not compliant with the ATO’s requirements, and a platform that issues non-compliant invoices to real paying customers is not a platform. It is a liability. The ABN registration is in progress. It arrives when it arrives.

What I could have done, and very nearly did, was keep pushing to launch with a placeholder and fix the ABN paperwork “later.” That framing is the seductive shortcut of every early-stage startup. Ship now, polish later, deal with compliance when someone makes us. I have watched enough companies do exactly that and then spend two years untangling the decisions they made in the rush. I am not building Devalo to spend two years fixing it.

So the launch date moved. And then an odd thing happened. The pressure that had been driving me toward rushing the final 10% released, and what I had been treating as the final sprint turned out to be the midpoint. The modules that were “done” had audit items I was planning to defer. The tests I had been meaning to write got written. Three modules I was about to ship half-finished — a CRM with no frontend, an invoicing module with no Xero integration, a marketing system with broken A/B logic — went onto the honest list of what was actually ready and what was not. The CRM got shelved entirely. Fourteen thousand lines of scaffolded backend code that would have taken two more months to finish. Gone, for now. It stays in git history. When Devalo is real and has real customers and real revenue, we rebuild it in a month, not a quarter.

What the extra runway bought was not more features. It was the ability to make the launch version complete. Every module we ship is a module we actually finished. Every test we commit is a test that would catch the bug it was written for. The automated test suite that validates cross-organisation isolation, webhook idempotency, and the login flow now runs on every push — not so that I can feel good about CI badges, but because I cannot always be at my desk to verify things by hand, and a trustworthy platform has to verify itself.

There is also something to be said about the story this tells a customer. A business owner signing up to a platform on day one is taking a bet that the platform will still be here in three years. The version of me that launched in two weeks with an unfinished CRM and a broken A/B test would have been easier to catch out. The version that launches in three months with a small number of modules, each of them worked through to completion, says something different. It says the person who built this was willing to say no to themselves when it mattered.

AI-assisted development is supposed to be about speed, and it absolutely is. The modules that make up this platform would not exist without it. But the more interesting gift, and the one I did not see coming, is the freedom from the sunk-cost trap. When the cost of building something is weeks instead of months, the cost of throwing it away and building it better is also weeks instead of months. The CRM scaffold that got shelved was not a failure. It was an investment in figuring out what the shape of a CRM needed to be — and now I know, I can build the right one at the right time, without the pressure of finishing the wrong one first.

The next time I write one of these, I intend to have a date. Not a guess at a date. A date.