What has genuinely changed
Not marketing language: the economics of software have moved, and anyone telling you otherwise is protecting something. Work that took a developer three weeks in 2021 can take two days now. Prototypes that needed a budget approval can be built in an afternoon by the person who wants them. A competent non-developer can produce something that runs.
That's real, and we've restructured around it. Our continuous ownership programs exist partly because AI made it viable to charge a fixed fee for unlimited development — the cost curve changed enough that we could stop billing for effort and start charging for outcomes. We'd be poor advisors if we pretended the tools hadn't moved.
The question was never whether AI can write code. It obviously can. The question is what happens to that code between month two and year four.
Where building it yourself genuinely works
We'd actively encourage it in these cases, and we say so on calls regularly enough that it costs us work.
- Internal tools with a small, known audience. A dashboard for your own team, a calculator, a form that replaces a spreadsheet. If ten people use it and the worst failure is mild inconvenience, build it.
- Prototypes and proofs of concept. Building the thing is now the cheapest way to find out whether you want it. This has genuinely inverted — prototype first, specify after.
- One-off data work. Cleaning a file, reformatting an export, a migration that runs once and is then discarded.
- Automating your own repetitive work. If it's your process, your data and your problem, you are the best person to automate it and you no longer need us to.
- Anything where you can inspect the output. If a person sees the result and would notice it being wrong, the risk profile is completely different.
The common thread is containment. Small blast radius, visible failures, low cost of being wrong, and no obligation for it to still work in three years.
Where it breaks, by category
Product and internal application development
AI is excellent at producing something that works on the first path through. What it does not reliably produce is the other ninety percent of an application: permissions, concurrency, audit trails, validation against real-world data, error states, and the accumulated handling of edge cases that only emerge in production.
The characteristic failure isn't that it doesn't work. It's that it works beautifully for four months and then a user does something unanticipated, and there's no one who understands the codebase well enough to work out why. The build was cheap; the archaeology is not.
Integrations with live systems
This is where we see the most expensive outcomes, and it's the least intuitive category. Writing the integration is genuinely straightforward now. What AI doesn't do is answer the questions that actually matter: what happens when the API is down at 2am, when a record partially writes, when the platform changes a field next quarter, when the same order syncs twice.
An integration that fails loudly is fine. An integration that fails quietly for three weeks and corrupts your inventory is a different kind of event, and we've been called in to unpick several of them. The cost of the cleanup routinely exceeds what the integration would have cost built properly.
Managing and evolving live systems
Nothing about AI changes the fact that software needs owning. Someone has to apply security patches, respond when a platform deprecates something, notice that a scheduled job stopped running, and decide what to do when requirements change.
AI makes each of those tasks faster. It does not make anyone accountable for noticing them. In our experience the thing that kills self-built systems isn't the build quality — it's that the person who built it moved on, got busy, or changed roles, and nobody inherited it.
Legacy management and rebuilds
Counter-intuitively this is where AI helps us most and helps you least. Reading and explaining unfamiliar code is one of the strongest current capabilities, and it has materially shortened our legacy assessments.
But understanding what legacy code does is only half the problem. The other half is knowing what it's supposed to do, which lives in the business rather than the codebase — undocumented rules, deliberate exceptions, and the reason a particular customer is handled differently since 2016. AI will confidently reimplement a bug as a feature because it has no way to know the difference.
Anything touching money, compliance or personal data
Payment flows, payroll, tax, personal information, safety-critical records. Not because AI writes insecure code — it writes more secure code than most hand-rolled equivalents — but because the accountability question has no good answer. When a regulator or an insurer asks who reviewed this, "the model produced it and it looked right" is not a position anyone wants to be in.
The cost that doesn't appear in the comparison
The usual comparison is a weekend of your time against a five-figure quote, which makes the decision look obvious. The comparison that matters is over four years.
- Who maintains it when the person who built it changes role
- What happens when a platform it depends on changes its API
- How you find out it has stopped working, and how long that takes
- What it costs to extend when the requirement changes, if nobody understands it
- What the failure costs — in orders, in reconciliation time, in customer trust
None of these are arguments against building it yourself. They're arguments for being honest about which column the costs land in. Plenty of self-built systems clear that bar comfortably. The ones that don't tend to be the ones nobody asked the question about.
What we do differently because of AI
It would be strange to write this page and not say how we've changed. We use AI heavily — for code generation, for reading unfamiliar systems, for documentation, for test coverage, for the legacy archaeology described above.
What that buys you is not a lower hourly rate, because we don't bill hourly. It's that fixed-fee unlimited development became viable. Under Champion1 Foundation we can commit to a monthly number and unlimited scope precisely because the cost of producing software fell. That pricing model would not have worked five years ago.
So the honest framing isn't us versus AI. It's that AI changed what a development partner should charge for, and we changed what we charge for. Anyone still selling you hours has not passed that saving on.
The test we'd actually apply
Before building something yourself, answer these in writing. If you're comfortable with all five, build it and don't call us.
- If this stops working silently, how long before someone notices?
- If the person who built it left tomorrow, who could change it?
- Does it write to any system that other processes depend on?
- Would a regulator, auditor or insurer ever ask about it?
- Will it still need to work in three years?
Two or more uncomfortable answers is usually the line. Not because you can't build it — because the build was never the expensive part.
