Most People Don't Need More Software

Before we talk about building anything, I ask one quiet question: do you need new software at all? Most of the time, the honest answer is no. After years of sitting across the table from founders, operators, and ops leads, I've come to believe that the reflex to buy or build another tool is usually a symptom, not a solution. The real problem is almost never "we don't have the software." It's that a process is unclear, the data is a mess, or nobody owns the outcome. New software rarely fixes any of those — it just gives them a more expensive place to hide.

This isn't a comfortable thing for an AI and software studio to say out loud. We make our living building systems. But the fastest way to lose a client's trust is to sell them a platform they'll never fully use, so I'd rather start here.

Do you need new software, or do you need clarity?

When someone tells me they need a new system, I try to separate the want from the need. The want is usually concrete — a dashboard, an app, an AI agent, a portal. The need underneath it is fuzzier: "I can't see what's going on," "my team wastes hours on this," "we keep dropping things." Those are real problems. But notice that none of them actually names software as the answer. They name a gap in visibility, time, or accountability.

Nine times out of ten, when we trace a feature request back to its root, we find a process that was never written down, a spreadsheet doing the job of a database, or two teams quietly duplicating each other's work. Build a slick new tool on top of that, and you've automated the confusion. It runs faster now, and it's still wrong.

The hidden cost of "just one more tool"

Every piece of software you add has a cost that never appears on the invoice. Someone has to learn it. Someone has to maintain it. It has to talk to the five tools you already own, and when it doesn't, a human becomes the integration — copying data from one screen to another at 6pm. The more tools a small team carries, the more of their week is spent tending the tools instead of doing the work.

I've walked into companies running a dozen overlapping subscriptions where half the seats are unused and nobody can quite remember why they bought the third project tracker. That's not a technology problem. It's the accumulated residue of a hundred reasonable-sounding decisions to add "just one more thing." Adding AI to that pile, without cleaning it up first, doesn't modernise it. It just gives the mess a chatbot.

New software rarely fixes a broken process. It just gives the confusion a faster, more expensive place to hide.

What usually works better than new software

When we genuinely save a client money, it's rarely by shipping the biggest thing on their wishlist. It's by doing something smaller and less glamorous first.

• Fix the process before you automate it. Write down how the work actually happens — not how the org chart says it does. Half the time, the fix is removing a step, not adding a system. Automating a broken process just makes the breakage repeatable.
• Use what you already own. Most teams use a fraction of the tools they pay for. The feature you're about to buy is often already sitting in a product you have, two menus deep, switched off.
• Clean the data first. An AI model or a new app is only as good as what you feed it. We often do data engineering work that makes a planned tool unnecessary, because once the data is trustworthy the original problem evaporates.
• Add a thin layer, not a platform. When automation does help, the right answer is usually small — a script, an agent that handles one annoying task, a single integration — not a sprawling system that takes six months and rewrites how everyone works.

This is the heart of how we approach AI implementation: the smallest intervention that solves the actual problem, not the largest one we could plausibly bill for.

When you genuinely do need to build

So when is new software the right call? When the constraint is real and the existing tools genuinely can't bend to fit it. A few honest signals that building is justified:

• The work is core to how you compete. If a capability is your edge — the thing customers choose you for — owning it makes sense. You don't want your differentiator living inside someone else's roadmap.

• You've outgrown the workaround. The spreadsheet that ran the business for three years is now a daily risk, and no off-the-shelf product fits the shape of your operation.
• The volume justifies it. A task you do five times a month isn't worth automating. The same task five hundred times a day is a different conversation entirely.
• You've already fixed the process. You know exactly what the system should do because the manual version already works. Now you just want it faster and at scale.

When those boxes are ticked, building is the right move, and we'll say so plainly. You can see how that plays out in our case studies — the projects that worked started from a clear, narrow problem, not a long feature list.

How a good partner should behave here

Here's a test you can use on anyone trying to sell you software, us included. A good partner will try to talk you out of scope before they try to talk you into it. They'll ask what you've already got and whether it can do the job. They'll be visibly relieved when the answer is "you don't need us to build this," because the alternative — taking your money for something that won't get used — costs them their reputation and you your budget.

If someone reaches for the biggest possible build in the first conversation, before they understand your process, that tells you who they're optimising for. The right sequence is the reverse: understand the problem, exhaust the cheap fixes, and only then reach for a custom machine learning or software build when nothing smaller will do.

A five-minute gut-check before you buy

Before you sign up for anything, run through a short, honest checklist. It takes five minutes and it has saved more than one client a five-figure mistake.

• Can I name the problem in one sentence without mentioning a product? If not, you're shopping for a solution to a problem you haven't defined yet.
• Have I checked whether a tool I already pay for does this? The feature is often already there, switched off.
• Is the process it would automate actually working today, manually? If the manual version is broken, automation locks the breakage in.
• Will someone own this after launch? Software without an owner becomes shelfware within a quarter.
• What's the smallest version that would tell me if this is worth it? Start there, not with the full build.

If you can't get past the first two questions, you almost certainly don't need new software yet. You need a clearer problem. That's free, and it's where every good project actually starts. If you'd rather not do that alone, our transparent pricing begins with a low-cost audit to map the right use case — often the most valuable step is realising which build you can skip.

The honest version

Most people don't need more software. They need less friction, clearer processes, and data they can trust — and sometimes, on top of that foundation, a small, well-aimed piece of automation that earns its keep. The job isn't to add. It's to figure out the one change that actually moves the needle, and to be honest when that change isn't a thing we get to build.

That's the conversation worth having before any code gets written. If you're weighing up whether a new system is really the answer, we're happy to be the people who tell you when it isn't.

Frequently asked questions