Insights

AI has two cost curves. I’m tired of only talking about one.

There’s a sentence I’ve heard in nearly every operations conversation I’ve had this year: “We don’t need to buy a tool – we’ll just have AI build us one.”

Sometimes it’s Lovable. Sometimes it’s Claude Code. Sometimes it’s “we’ll just put everything in Notion and have an AI assistant sit on top.” And the demos are impressive – a working web application from a prompt in 90 minutes is not nothing.

But the conclusion is wrong. And getting it wrong is starting to cost organisations real money, real time, and real morale, when the tool they thought they could just build turns into a maintenance burden no one signed up for.

The misconception: people think AI has changed the cost of building software. What it’s actually changed is the cost of writing it. Those are not the same thing, and the difference is most of the work.

The two cost curves

Software has two cost curves, and they behave very differently.

The first is creation – writing the code, designing the screens, wiring up the database, getting it to work. AI has compressed this dramatically. What used to take a developer weeks now takes a non-developer a few hours and £50 in credits. This is the curve that gets all the headlines and all the demos.

The second is ownership – keeping it running, fixing it when it breaks, maintaining the database, patching security vulnerabilities, recovering from incidents, migrating the schema as needs evolve, making sure backups exist and have been tested. This is the work that starts the day after launch and doesn’t stop.

AI has barely dented the second curve. Yes, it can help with debugging and code suggestions during maintenance, but the shape of operating a piece of software looks largely the same as it did five years ago. Backups aren’t easier. Authentication problems haven’t vanished. Dependency vulnerabilities haven’t become less frequent. The gap between the two curves is wider than it has ever been – the build has become dramatically cheaper while the operate has stayed roughly the same. And operate is where most of the money goes. Robert Glass’s Facts and Fallacies of Software Engineering put maintenance at 40-80% of total lifetime software cost, with 60% as the average. That research has held up for decades, and nothing about AI has changed it.

If you didn’t have the operational capability to maintain custom software before AI, AI doesn’t give it to you. It gives you something you cannot maintain.

Why this hits mission-driven organisations harder

This pattern affects charities and social enterprises more sharply than it affects commercial businesses, for one reason: most mission-driven organisations are running with no spare capacity. The case for “let’s just build our own” is most appealing to teams who struggle to justify the subscription cost of a proper SaaS product. But those are exactly the teams who can least afford to take on the operational ownership of software they didn’t budget for.

I’ve seen this play out a few times now. A charity gets excited about an AI app builder. A programme manager spends a weekend building something that does 80% of what they need, and for a few weeks the team is delighted. Then the login flow breaks for new users. Then a database migration comes along that nobody knows how to handle. Then the only person who understood the prompt history leaves. Six months in, the charity is paying for a piece of software that nobody can fix and nobody can confidently turn off.

The tool was free to build. It is not free to own.

AI is an amplifier, not a substitute

There’s a bigger version of this misconception that goes beyond software costs – the idea that AI is a substitute for capability. It isn’t. It’s an amplifier. It amplifies whatever you bring to it.

A skilled developer using Claude Code can often double their output. A non-developer using Claude Code generates code they cannot read. A team with disciplined operations and clean data gets enormous productivity gains from AI. A team with messy spreadsheets and unclear processes gets messier output, faster. It works in both directions.

What this means in practice: AI is making operational maturity more valuable, not less. The bottleneck for any team trying to use AI well is no longer “how do we execute the work” but “how clearly can we define what we want.”

Operations, properly understood, is the discipline of defining clearly.

The clearer your processes, the more an AI can run them. The fuzzier your processes, the more an AI just produces fuzz at higher volume.

The right order

If AI hasn’t replaced operations work but raised its stakes, the right sequence for any organisation thinking about AI tools becomes much clearer.

Do the operations work first. Map your current state. Define what good looks like. Make your implicit processes explicit. Identify what actually hurts.

Then choose tools that fit – off-the-shelf where possible, properly integrated, with the data flows and permissions that match how the team actually works.

Then let AI sit on top of all of it. Use Claude, Copilot, or whatever stack you choose to add productivity gains to a system that’s already coherent.

I’m being deliberately binary here to make the point, and as with most things the reality has a middle ground. Tools like n8n and other middleware platforms let you build hybrid models – bespoke automations and integrations that are far more tailored than off-the-shelf, but still sit on top of well-managed, properly owned SaaS tools rather than replacing them. That middle ground is often the sweet spot, and it still depends on the operations work being done first.

If someone is telling you to skip the operations work and jump straight to AI, be cautious. The demos are compelling, but operational debt accumulates anywhere you skip the definition step, and it compounds faster than most teams expect.

What this means for your organisation

If you’re considering an “AI-built” approach to a real operational tool – a CRM, a project tracker, a member portal – three honest questions are worth asking before you commit.

Do you have someone on the team who can read code well enough to debug it when something breaks? If not, owning custom software is a higher-risk choice than the build cost suggests.

Are your current processes clear enough that you could describe them to a new team member in a one-pager? If not, no AI-built tool will fix that. It will only encode the confusion at higher resolution.

What would the annual subscription to an off-the-shelf tool actually cost, compared to the hours you’ll spend maintaining a custom one? The build is cheap. The five-year total is the real number.

If those questions feel uncomfortable, they’re probably the ones you need to answer first. The work that needs doing is upstream of the tool decision.

The opportunity

None of this is an argument against AI. It’s an argument that AI works best for organisations that have already done the operations work AI assumes you’ve done.

For mission-driven organisations, this is good news. The skills that matter most for getting value from AI – clarity of process, discipline around data, an integrated view of how the team works – are exactly the skills that make a charity or social enterprise effective at delivering its mission. They aren’t separate disciplines. They’re the same discipline, viewed from different angles.

Get the operations right, and AI becomes one of the most powerful amplifiers your team has ever had access to. Skip the operations and reach for AI as a shortcut, and you’ll get a more expensive version of the same problem you started with.

The order matters.

---

Working through these questions?

Scale Impact helps mission-driven organisations get their operations right before reaching for new tools – whether that’s AI, middleware, or a better SaaS stack. If you’re weighing up what to build, what to buy, and how to integrate AI into how you actually work, we’re happy to talk it through.

Get in touch for a no-obligation conversation about what might work for your organisation.