28 Years in Technology Delivery

I started in technology in 1998. The web was young, enterprise software was sold in shrink-wrapped boxes, and the idea that a small business might run its operations through a browser would have seemed ambitious. Twenty-eight years later, the technology has changed completely. The principles of building things that work have not changed at all.

The most important lesson from nearly three decades is that technology ages but architecture endures. Every framework, language, and platform I have worked with has eventually been replaced by something newer. But the systems designed with clear separation of concerns, well-defined interfaces, and strong data models outlived the specific technologies they were built with. Architecture is the part of the system that survives technology change.

In the early 2000s, I was working on enterprise systems for large organisations — financial services, government, telecommunications. These were big, complex projects with teams of dozens or hundreds. The patterns were consistent: projects that started with thorough architecture and specification delivered on time and within budget. Projects that started coding immediately delivered late, over budget, and usually needed significant rework.

The consulting years taught me what good and bad look like at scale. I saw systems that processed millions of transactions daily without error because they were designed with rigour. I saw systems that failed under load because they were designed for the demo, not for production. The difference was never talent — both types had skilled engineers. The difference was process. Disciplined teams with clear specifications built reliable systems. Talented teams without specifications built impressive but fragile ones.

The financial services sector specifically shaped my views on governance and compliance. When software handles money, the standard for correctness is absolute. A banking system that processes a payment incorrectly does not get a second chance. A trading system that calculates risk wrong can cause catastrophic losses. Working in this environment taught me that governance is not overhead — it is the mechanism that prevents disaster.

The shift to cloud computing in the 2010s changed the economics of software delivery but not the principles. Infrastructure became elastic, deployment became automated, and the cost of serving customers decreased dramatically. This democratisation of infrastructure is what makes neart.ai possible — building enterprise-grade software for smaller businesses is economically viable in a way it was not fifteen years ago.

The rise of AI as a development tool is the most significant change I have seen. AI does not replace engineering judgement — but it dramatically accelerates execution. What used to take a team of five engineers three months can now be accomplished in a fraction of the time. The key is that AI amplifies the quality of the input. Give AI a clear, detailed specification and it produces excellent code. Give it a vague brief and it produces plausible but unreliable code. This is why specification-first development matters more in the AI era, not less.

Running Vanda's Kitchen gave me a perspective that pure technologists lack. I experienced firsthand the gap between the tools available to small businesses and the tools they actually need. The accounting software was clunky. The scheduling tools were designed for offices, not kitchens. The compliance tracking was manual and error-prone. These were not technology problems — they were problems that technology could solve if someone built the right products.

The decision to build an ecosystem rather than a single product came from this accumulated experience. Twenty-eight years taught me that businesses need operational infrastructure — not just one tool but a coherent set of tools that work together. The SaaS market is full of individual products that solve individual problems. What is missing is the integrated platform that handles the complete operational picture for businesses that are serious about their work but underserved by existing tools.