Build Your Own AI Tool vs Buy: Opportunities and Limits

Ever since AI started helping with programming, I hear one question more and more often: is it even worth buying software any more when I can have it built myself? The honest answer is: yes, building your own is a real lever today. I build my own tools, from the audit helper to the small component that sits alongside the ERP. But I build them as someone who also audits. And from that vantage point I will tell you this: the quick prototype is one half. The other half, security, tests and data architecture, decides whether you have built yourself an advantage or a liability.

What AI-assisted development can really do today

The leap is real. A small tool tailored to your business now costs days, not months. A script that pulls order data and flags overdue invoices. A prototype that photographs a component and reports deviations. A helper that pre-sorts job applications. Things like these have moved within reach for mid-sized companies, without you having to build a software department.

I do this myself. My website, small tools around auditing and evidence, components that let two systems talk to each other. The pace is impressive. A managing director who a year ago received a quote in the mid five figures for a single automated process now has a running prototype in a week. That is the good news, and it is genuine.

• Internal helpers that consolidate and prepare data from existing systems.
• Prototypes for a specific idea, before you sink serious money into a finished product.
• Small bridges between programs that no vendor sells in exactly that form.
• Reports and dashboards for questions only your business asks.

The prototype is lying to you

Now comes the part the hype likes to skip. A demo that works on your screen with clean test data is not yet a system. It is the happy case. The AI is only too keen to write the code that makes the demonstration succeed. It does not, of its own accord, write the code for the ugly Tuesday morning when the data is skewed, two users save at the same time, and someone leaves a field empty that should never be empty.

Between prototype and production-readiness lies precisely the work you do not see at first glance. And the three gaps I most often find are always the same.

Security: the part where I, as an auditor, prick up my ears

A self-built tool that touches customer or personnel data needs access control, a secure place for passwords and keys, and logging of who saw what and when. AI-generated code often leaves out exactly that of its own accord. The key sits in plain text in the code. There is no sign-in. Nothing is recorded. On a small scale this goes unnoticed. In operation it is an open item.

Take the application pre-sorter from earlier. If it sorts applications and stores the data somewhere without access control and without a deletion concept, you have not built a tool, you have built a data protection problem. The same applies to the visual inspection on the production line that stores images and order numbers on the side, and to the ERP component that has access to real revenue figures.

A tool that touches customer data but does not log who saw what and when is not a tool in an audit. It is an open item.

Tests and auditability: what the hype leaves out

Without automated tests, you do not know after the next change whether your tool still does what it should. And with AI you change a lot, fast. You ask for a small adjustment, and behind the scenes something gets rewritten in three other places. Without tests this breaks quietly, and you only notice when a number no longer adds up.

For anything that touches money or makes decisions, this is not optional. An ERP-adjacent component that touches invoices has to remain auditable. Whoever rejects an application has to remain able to justify it. Auditability is not a hobby-horse of mine as an auditor; it is embedded as a requirement in accounting record-keeping rules and in ISO management systems. A tool that makes a decision no one can trace is, in the ISO 42001 sense, exactly the kind of AI you should not let run unchecked.

Data architecture: where the prototype turns into legacy debt

This was my own costliest lesson: prototype excellent, architecture forgotten. The data just sits there somehow, as long as the demo runs. No clean separation, no plan for how to migrate later. Six months on, half the business hangs off this tool, and no one dares change anything, because every change breaks something else. The quick win has turned into a new dependency, this time on your own stopgap.

Let's cut to the chase. The data architecture is the difference between a tool that grows with you and one you will have to replace at great cost in two years. It does not emerge on its own just because an AI types quickly. It emerges because someone thinks ahead about who owns the data, how it is structured, and how you get it back out again.

Self-built does not mean unaudited

The moment you build a tool, it becomes part of your IT and AI landscape, whether it is on a list or not. In an ISO 42001 or 27001 audit, the self-built application pre-sorter or your own visual inspection is no longer a hobby project but a system that processes data and sometimes makes decisions. It belongs in your inventory, with an owner, a purpose and a risk classification. Tools no one has written down are shadow IT. And shadow IT is exactly what blows up in an audit and when things go wrong.

This is not bureaucracy for its own sake. It is the difference between saying you use AI responsibly and being able to demonstrate that you do. A single line stating what the tool does, which data it touches, who is responsible and whether it has been tested turns a private script into an auditable operational asset. And it ensures you have an answer when someone asks: who actually decided that this application should be thrown out?

Build or buy: how I decide

This is not a matter of faith but of classification. Buy when the problem is solved, regulated and standard. Payroll, the core of financial accounting, anything where vendors have taken on liability and maintenance for years. There you build nothing yourself; that would be expensively wasted time.

Build when it concerns your specific process, your edge, a bridge no one sells in exactly that form, and when the data should stay with you. But then treat the self-built tool like any other supplier: with the same questions about security, auditability and data sovereignty that you would put to an external vendor. The only difference is that the supplier is now you.

• Buy makes sense when: a standard problem, a regulated area, liability and maintenance matter more than idiosyncrasies.
• Build makes sense when: your own process, a genuine competitive advantage, data sovereignty, a gap between systems.
• Build is a bad idea when: no one in-house will maintain and own the tool afterwards.

AI-assisted development is a real lever for mid-sized companies, not a toy. But the lever only works if you do not treat the second half of the work as an afterthought. The prototype is free. Production-readiness you have to earn.