Why I Started Building My Own Products

For most of my career, I built systems for other people. Consulting means you bring your expertise to someone else's problem, deliver a solution, and move on. The work is interesting, the challenges are real, and the pay is good. But there is a fundamental limitation: you never own the outcome. The system you build belongs to the client. The product decisions are theirs. The long-term direction is theirs. You are a skilled executor, not a creator.

The shift from consulting to product building was not sudden. It was a gradual recognition that the problems I kept seeing in consulting — fragmented tools, poor data quality, compliance gaps, underserved users — were not going to be solved by building better systems for large organisations. They were going to be solved by building better products for the organisations that could not afford consulting.

Running Vanda's Kitchen was the catalyst. As a food business owner, I experienced the software market as a customer rather than a builder. And the experience was frustrating. The bookkeeping tools available to a small food business were either too basic to be useful or too complex to be practical. The compliance tools assumed a level of expertise that food business owners do not typically have. The operational tools were designed for offices, not kitchens.

I found myself building spreadsheets and manual processes to fill the gaps that commercial software left. This was absurd. I had spent decades building sophisticated systems for banks and telecoms companies, and here I was creating manual workarounds for basic business operations because the available tools were inadequate. If I — with deep technical expertise — was struggling, what were non-technical business owners doing?

The answer, I discovered, was suffering quietly. Small business owners accept poor tools as normal. They spend hours on tasks that should take minutes. They miss deductions because their bookkeeping is incomplete. They file late because their compliance tracking is manual. They make decisions on gut feeling because their data is fragmented. These are not personal failings — they are the predictable consequence of tools that were never built for them.

The decision to build was therefore a decision to solve the problems I had both observed professionally and experienced personally. Not one tool for one problem, but an ecosystem of tools for the complete operational picture. The same architecture, the same data discipline, the same compliance rigour that I had applied in enterprise consulting — but scoped, designed, and priced for the businesses that needed it most.

The first product was Accounted — bookkeeping software for UK sole traders and landlords. The choice was deliberate. MTD was approaching, creating a mandatory need. The existing tools were inadequate. The compliance requirements were well-defined, which suited our architecture-first approach. And the audience — sole traders and small landlords — was exactly the underserved market I wanted to build for.

Building your own product is fundamentally different from consulting. In consulting, the requirement is given to you. In product building, you must discover it. In consulting, success is defined by the client. In product building, success is defined by users who voted with their attention and their money. The accountability is direct and the feedback is immediate.

The transition from consulting to product building was the best professional decision I have made. Not because the work is easier — it is harder. Not because the risk is lower — it is higher. But because the impact is direct. Every feature we ship, every bug we fix, every compliance requirement we meet directly affects real people running real businesses. That connection between effort and impact is what makes product building compelling in a way that consulting never was.