Does Your Tech Business Need to Be AI-Driven to Survive?

Every pitch now says AI. The businesses that last are driven by something else: a problem they understand better than anyone.

AI is everywhere right now, and so is the fatigue. Every feed, inbox and conference agenda is fighting for the same scrap of your attention, and the vocabulary changes every few months. Not long ago the talk of the town was large language models. Then it was agents. By the time you read this, it may be something else.

Look at any accelerator cohort this year, the groups of young startups going through a support programme together, and most of the pitch decks say AI. Ask the founders what problem they actually solve, and for whom, and the answer often gets vague. It’s the same pause I described in Traction Isn’t Validation, when a founder with a polished AI-built tool couldn’t say who had tested it. A lot of them have started with the tool and gone looking for a job for it.

A checklist doing the rounds online puts it bluntly: is your business AI-proof? Give yourself a point for every yes.

Not one of those questions asks whether you use AI. And there’s a harder question underneath. If AI agents can build, copy or reverse-engineer almost any standard software platform on demand, why invest in software platforms at all? Why pay for a subscription when a coding agent can build a working alternative for a fraction of the cost? Copying how something works is often legal. And if anyone can build the same thing with the same model in a weekend, what stops them?

That’s what this piece is about: what keeps a tech business alive when anyone can build software.

The AI badge

“AI-powered” has become the default label on new products, and investors often look for it first. But a label isn’t a business, and regulators on both sides of the Atlantic have started checking the claims. “AI washing”, saying you use AI when you don’t, or not in the way you say, now comes with real penalties.

If AI is in the pitch, it has to be in the product, doing something that matters.

The elephant in the room

Let’s be honest. Tech isn’t usually a problem-first industry, whatever the mission statements say. A lot of it runs on venture capital: money from investors who back risky young companies, hoping a few will return ten or a hundred times what they put in. That pushes founders towards growth at all costs, and sometimes away from the problem they set out to fix.

It also explains the hype cycles. When money floods into a trend, whether that was crypto, Web3 or now generative AI, founders pitch the words investors want to hear, and plenty of people hope to get out before the boom ends. Some of the most profitable products didn’t fix an existing problem at all. They created a new habit, and then a dependency.

So why does problem-first matter now? Because the easy playbook is getting harder. When an AI agent can copy a simple app for next to nothing, backing one is a worse bet than it used to be. That leaves founders with a real choice: chase the hype and hope to cash out in time, or build something that lasts. This article is for the second group.

Code is no longer a moat

In business, your moat is whatever stops a competitor copying you. For software companies, the code itself used to do a lot of that work.

Now an AI coding agent, an AI that writes software for you, can build a working version of a standard tool in days. Back in August 2024, Matthew Lucas of the investment bank Goldman Sachs warned of a “deflation of software”: if AI keeps making development cheaper, businesses could swap the software they buy for tools they build themselves. This year investors took that seriously. By Morgan Stanley’s count, the rush to sell software shares wiped nearly $2 trillion off the value of software companies.

You can see why on the ground. I recently watched someone skip the usual presentation software altogether and build their own, with live polls and mobile integration built in, then use it in a classroom. Partway through, a bug turned up, and they had to jump into Claude Code to fix it on the spot. But the bug isn’t the real story. The hunger is. People want software shaped around exactly what they do, and AI now lets them build it. In the past you’d raise a ticket with a big tech company and wait ages for a custom feature that might never arrive.

That bug was a small taste of the real cost. Building is the cheap part. Owning software is where the cost sits. Picture that poll tool at a big conference. The venue Wi-Fi drops just as 300 phones try to vote at once. The answers people give are personal data that someone has to look after under UK GDPR, the law on handling people’s information. Next spring a security flaw turns up in one of the building blocks it relies on, and the person who made it has moved on. Part of what a software licence pays for is someone else owning all of that.

So the products most at risk are the simple, one-job ones. Products woven into regulated, messy, real-world work are holding their ground, and Morgan Stanley’s review of the sell-off agrees: the firms holding up run systems customers can’t do without, or own data nobody else has. Don’t count on the law to protect your code, either. What protects you is your brand, your licences, your relationships and the rules of the platforms you sell through.

The same goes for AI itself. Lift the lid on many “AI platforms” today and you won’t find new technology. You’ll find a thin layer of code sending requests to models from OpenAI, Anthropic or Google. There’s nothing wrong with building on those models. But if that’s all there is, anyone can rebuild it, and you’ve rented the core of your product from someone else, along with its risks. You don’t control how the model was trained or when it changes. Researchers have even shown that models trained over and over on AI-generated data can degrade, like a photocopy of a photocopy.

Should you wait for the dust to settle? I don’t think it will, not in the sense of a calm moment when the rules are clear. But the direction is clear enough to act on. The moat’s still there. It’s just not in the code, or in the model, any more.

What actually makes a tech business

A tech business uses technology to solve a problem better, faster or more cheaply than the alternatives. The tech is how you do it. The problem is why anyone pays you.

The companies that last understand one customer’s problem better than anyone else does. Sometimes AI is the right tool, sometimes it’s part of the answer, and sometimes it’s the wrong tool altogether. So don’t start by asking whether you’re AI-driven. Ask what problem you’re here to fix.

Look back at the checklist and most of the answers have nothing to do with the technology. They come from the layer around it: the people and permissions that stand behind what it produces.

That’s the moat nobody talks about. It’s the validation around the model.

Who checks the work, when AI can build?

If agents can build almost anything, what’s left for people? An early answer comes from inside an AI lab. In October, Anthropic published a report on how work has changed among its own staff.

It’s one company, and an unusual one, so treat it as a glimpse of what’s coming rather than a forecast. But wider research points the same way. A Harvard working paper by Fiona Chen and James Stratton, covering more than 700 software firms, found AI coding agents added about 30% more code but no measurable rise in finished work, because reviewing it took 49% longer. Schools show the same pattern. A YouGov survey for Bett found 52% of UK teachers now use AI every week, but only about a third of them are working fewer hours. The time saved on one job gets swallowed by another, a point the AI Awareness Day campaign makes in Is the human the new bottleneck?

So when building gets cheap, the scarce skill is knowing what’s worth building, and checking that what was built is right. That still takes people.

There’s a catch. People learn that judgement by building things early in their careers. A government snapshot of LinkedIn data found UK entry-level hiring down 14% in the year to April 2026, and entry-level software engineering down 27%. It warns that isn’t proof AI is the cause, and the Institute of Student Employers found graduate hiring up 4% this year. But if junior roles do dry up, where does the next generation of checkers come from? For the UKBlackTech community, that question decides who gets a foot in the door at all.

I’ve taught thousands of young people over the years. For a long time that meant digital skills and the opportunities they open up. Now I start with application: how do you apply AI to a local challenge, or to a sector that runs on necessity, like life sciences? The shift is in mindset. Instead of learning a tool and hoping for a job, students learn to point their creativity and talent at a real problem, and either change something or spot the opportunity and go for it. That’s how the next generation of checkers gets made.

Problem-driven, then AI where it helps

So does your tech business need to be AI-driven to survive? No. It needs to be problem-driven, and to use AI where it genuinely helps with that problem. In practice:

• Start with the problem, not the model. Who has it, how often, and what does it cost them today?
• Ask the people who live with it: the people who use it every day, the people who pay, and the people who regulate it. They’ll tell you which parts AI can handle, and which need a person, a licence or a relationship.
• Write down what makes you hard to copy. That’s your moat.
• Sell the result. Most customers don’t care which model you use. They care that the job gets done, safely and well.
• Be straight about your claims. Say what the AI does and what it doesn’t.

And when an investor asks “what’s your AI story?”, as many still will in the first five minutes, don’t lead with the model. Lead with the evidence: are people still using it after 90 days, are they recommending it without being asked, is it saving them real hours every week, and has someone signed a contract? I set out those signals in Traction Isn’t Validation. Then show where AI makes that cheaper or faster. That’s an AI story worth backing.

Put it through the PRL

You don’t need a framework to ask these questions, but it helps. That’s why we built the UKBT Institute’s Practitioner Readiness Level (PRL). Engineers use technology readiness levels to ask “can we build it?” The PRL asks “should we build it?”, and it has to come first.

We run it through the Townhouse, the Institute’s way of bringing the right people into one room, floor by floor. Most of the startups that land in our inbox are wellbeing apps, cyber security products and productivity tools. The Townhouse pushes back on that. It’s sector-led, not tool-led: we start with a sector and the people in it, and only then ask what to build. One of our Townhouses focuses on sickle cell. We’ve also tested the approach in women’s health, through hackathons, low-tech solutions for women, and work on how women can tell better stories about their own bodies in a way that’s ethical, confidential and personalised.

Here’s how the floors work, using an illustrative case: a care home manager losing three hours a week to rota changes.

Notice where AI comes in. It doesn’t appear on Floor 1 at all. It arrives on Floor 2, as one possible answer to “what technology should we use?” An idea that starts with AI and can’t get past Floor 1 is a solution looking for a problem.

The bar is deliberately high. It’s designed to stop weak ideas early, when stopping is cheap. That means it will sometimes pass over a good idea, such as a problem that comes up rarely but costs a lot when it does. We accept that, because backing the wrong idea costs far more.

And it’s why the practitioners matter so much. The nurse knows which parts of a shift can be automated and which can’t. The compliance officer knows which approvals take a year. That knowledge is what turns a clever AI product into a business that lasts.

What to watch

I’m getting my predictions in early. These are the five things I’ll be watching over the next few months and into 2027, and I’ll come back to them next year to see what played out.

My read: AI is moving value away from the software and towards whoever owns the problem and the judgement. What’s still open is how fast that happens, and who gets trained to do the judging.

Start with the friction

At the start I said the vocabulary changes every few months. Large language models, then agents, then whatever comes next. That won’t stop, and you don’t need to keep up with every word of it. The people you build for don’t care what we call the technology. They care that it works on the day.

So before you rewrite your roadmap, your plan for what to build next, around the latest trend, look closely at the hassle your customers deal with every day. If AI really is the best way to remove it, use it, and use it well. Your value lies in how well you understand the problem, not in the buzzwords you use to describe the tech.

• If you’re building a tech business: test whether your product is really problem-driven by putting it through the UKBT Institute’s PRL.
• If you’re buying or using tech: next time a platform calls itself “AI-powered”, look past the feature list and ask one question: what messy, real-world problem does this actually solve for me?

Mark Martin MBE is the founder of the UKBT Institute, and an Assistant Professor in Computer Science and Education Practice.

Through the UKBT Institute’s Townhouse, he brings founders, practitioners and communities together to test new technology before it scales.