AI development, Build or Buy

Pay for SaaS, or Build It Yourself with AI?

Build selectively, keep what adds value, and cancel more than you think.  AI coding tools have changed the maths of software. A CRM, a booking page or an approvals workflow that once took a contractor weeks can now be scaffolded in an afternoon. It is tempting to look at your monthly licensing bills, count the subscriptions, and replace them all.  I think that is mostly the wrong move. Not because AI can't build the software, but because building was never the expensive part.

Building is cheap. Owning isn't.

When you replace a SaaS tool, you are not just replacing the app. You are replacing everything the vendor quietly does around it:

• Security and patching. Every homegrown tool is another attack surface, and you are now accountable for it.
• Uptime, backups and restores. When it breaks at 2am, you are the support desk.
• Regulatory change. Tax rules, GDPR, payroll and e-invoicing requirements move constantly. A good vendor shares that burden and absorbs it for you.
• Integrations. The APIs your tool depends on will change, and your glue code will break.
• Your attention. This is the big one. Every hour you spend maintaining an internal CRM is an hour you're not spending on your role.

Run the numbers honestly. A £30-a-month tool costs £360 a year. If owning your replacement takes more than a few hours a year at your day rate, you have lost money, even if the first version took an AI agent an afternoon.  When you multiply by thousands or tens of thousands, the answer looks straightforward, but if this system goes down or data is breached, the true cost can be extreme.

Five questions before you build

Before you cancel a subscription or set of licences and open your AI coding tool, run it through these five questions. If the answers point more often to "buy" than "build", keep paying.

1. Who sets the rules?

If the rules come from HMRC, the card schemes, a regulator or a standards body, buy it unless it gives you a competitive advantage. Accounting, payroll, payments, e-signature and tax filing all fall here. You don't pay for the screens. You pay for someone else to track every rule change and carry the risk if they get it wrong.

2. Is it cheap and working?

Keep it. A tool that costs a few pounds a month and does its job without fuss is the worst possible candidate for a rebuild. The saving is tiny, and you swap a solved problem for a new one you have to maintain.

3. Is it priced per seat?

This is where building starts to make sense. Per-seat pricing grows with every hire, contractor and partner you add. A simple tracker or approvals tool that costs £9 a user a month looks very different at 4,000 users than at 4. If the tool is essentially a few forms, a list, and a workflow, you can pay it back quickly.

4. Does it set you apart?

If the tool encodes how you do things differently from competitors, it is worth owning. Your pricing logic, onboarding flow, or lead-scoring process is part of your edge. Renting them means renting your differentiation, and shaping your process around someone else's product.

5. Who looks after it?

If the honest answer is "nobody", don't build yet. Every piece of software needs an owner: someone who patches it, answers questions and fixes it when an API changes. No owner means the tool slowly rots until it fails at the worst moment. Name the person first, then build.

A practical playbook

1. Audit first. List every subscription + licence. Look for easy wins first.
2. Consolidate onto what you already license. If you pay for Microsoft 365 or Google Workspace, check what is already included. Forms, bookings, lists, task planners and simple low-code apps quietly replace a surprising number of small tools.  Find out whether your employees are using rogue tools; then normalise them.
3. Build only the few that pass the test. Pick the two or three tools where per-seat pricing hurts, the logic is simple, an outage would be an inconvenience rather than a crisis, and you have named an owner.
4. Watch for product signals. If a tool you build solves a pain your peers keep describing too, it may be a product rather than an internal tool.

Summary

AI has made software almost free to build. It has not made software cheap to own. So before you build, ask the five questions. 

1. Who sets the rules? 
2. Is it cheap and working? 
3. Is it priced per seat? 
4. Does it set you apart? 
5. Who looks after it?