Tech in the times of AI: building got easy. Getting it right didn't.

A few months ago, at a gathering of education non-profits, someone walked me through a dashboard they'd built for their programmes. Built in two evenings, they said, with an AI assistant. It was genuinely impressive - clean charts, live numbers, everything a donor presentation would want. Then I asked one question: "Who updates the data on Fridays, and what happens to the spreadsheet it comes from?"

The room went quiet looking for someone to answer the question. Everyone there recognised the question, because everyone there was living some version of it.

Here is the strange thing about this moment. Building software has never been easier. No-code tools, AI that writes working code, templates for every conceivable use case. A website over a weekend. An app in a month. A dashboard in an evening. Everyone around us is doing tech - the organisation down the road has launched an app, the CSR team is asking about AI chatbots, every sector conference has a session on digital transformation.

And yet the struggle hasn't ceased. Reports still take a week to stitch together from four sources. Attendance still lives in three registers and two spreadsheets. Data exists in abundance - but nobody trusts it enough to actually make a decision with it. If tech has become this easy, why does the hard part feel completely unchanged?

Because the hard part was never the building.

Tech without a clear purpose and outcome doesn't reduce the struggle - it adds to it. Every new tool is one more place where the truth lives. One more login for a field coordinator who is already carrying three. One more report format that doesn't match the donor's format. One more system that quietly dies the month the person who championed it moves on. And when building is easy, building becomes the default. The most important question - should this exist at all? - is the one that gets skipped.

AI makes this sharper, not different. AI is a magnifier, not a strategy. It accelerates whatever direction you are already pointing, including the wrong one. Define the work loosely, and AI will deliver the wrong thing faster and more beautifully than any team ever could. A fuzzy idea plus a month of AI-assisted building gets you a polished version of the fuzz. That is not progress; that is a faster route to the same dead end.

The building was always the easy part

I've been building products for fifteen years - five of them, across consumer tech and led a large scale digitisation project in the water sector. I can tell you what the experience taught me: the building was always the easy part. Every product that survived did so because we got brutally clear, before writing a line of code, about what it was for and who would change their behaviour because of it. Every struggle I've watched organisations go through since came from skipping that step. The tools changed. That step didn't.

The gap nobody demos

There's also a gap nobody demos: the gap between a working demo and daily use. Anything can be demoed in a day. The real test of a piece of technology is whether your field team opens it on a rainy Tuesday in a district office without being asked. Whether the programme lead trusts its numbers in the review meeting. Whether the report that used to take a week now takes an hour. That gap has nothing to do with how the software was built and everything to do with whether it was worth building.

The simplest measure of useful tech

Which points to the simplest measure of useful tech, once you cut through everything else: does it give your team time back - permanently, not momentarily, with the hours not quietly taken back multifold by upkeep and new demands? Count it honestly: after implementation and adoption, measured against the process it replaced, not the promise made in the demo. If your team still keeps the old registers "just in case" while also feeding the new system, that's not diligence - that's redundancy, and redundant tech is the wrong tech, whatever it was bought for. A few weeks of parallel running during a migration is discipline; a year of it is a second job. Then a question that belongs to leadership, not the tool: when the hours come back, will you let your team keep them - for teaching, mentoring, the work only humans can do - or refill them with more of the same grind? And read the ledger fully: some tools pay in lumps, not daily wages - the audit that never becomes a fire-drill, the incident trail that takes minutes instead of days. If the ledger is honest and the time still never comes back, you didn't buy a tool. You bought a distraction with a login screen.

Three questions before you say yes

So before you say yes to the next tool - AI-powered or otherwise - three questions, in this order:

This is why every engagement we take starts with a roadmap, not a build - and why the roadmap sometimes ends with "don't build; your spreadsheet is doing this job fine." That answer saves organisations more money than any platform ever will.

AI has made the building cheap. It has not made the thinking optional. The organisations that come out of this decade stronger will not be the ones that built the most - they'll be the ones that knew exactly why they built what they built.

AI is a magnifier, not a strategy. It accelerates whatever direction you are already pointing - including the wrong one.

If you're weighing a tool right now and want a structured way to test it, our 18-question Tech Readiness Checklist takes about six minutes and tells you honestly which band you're in - Paper Cliff, Patchwork, or Build-Ready. Take the checklist.