Building Your Own Tool: Code Is No Longer the Barrier 🛠️

This time, let's talk about that curious person. Because there are more of them every month.

Until a few years ago there was only one path from a business idea to working software: a request form, a priority queue, months of waiting, and finally a screen that covered roughly 60% of what you needed. Today, someone who knows the process can produce a working prototype the same evening.

That is a genuinely big shift. But it comes with a very clear boundary, and that boundary is what this article is really about.

🛠️ What Changed Isn't Our Skill — It's the Distance

Think back to the proforma → bank instruction automation from my first article. What drove that wasn't curiosity about technology; it was the fatigue of retyping the same fields into Word over and over again.

What I noticed building it was this: the hard part was never the code. The hard part was knowing how the process actually works. AI can now be the side that writes the code. But knowing “which line holds the amount on this proforma, which format this supplier sends documents in, in which case the payment gets split in two” still lives in the field.

So what changed is not our capability; it is the distance between an idea and a working tool.

💡 The Real Advantage of Knowing the Process

When you work with a developer, the first job is explaining the process to them. And the hardest part of that is the exceptions, because most of them are not written down anywhere; they live in the team's heads. “Documents from this company always come in scanned upside down” never makes it into a requirements document, yet it decides the fate of the project.

Someone who knows the process never has to make that handover. They already hold the most valuable input. The only thing they used to be missing was code, and code has become the easiest part to obtain.

That's why I don't agree with the claim that AI is taking developers' jobs. What AI removed is not the need for developers; it is the first-step barrier in front of people who know the process. Those are two very different things, and the rest of this article is about the difference.

⚠️ “I Can Build It” and “I Can Sustain It” Are Not the Same Sentence

This is the critical point. With AI you can get something working in two hours. Keeping it alive for two years is an entirely different job. Five walls I've hit in the field:

1. Code you don't understand. It works, but if you don't know why it works, you can't fix it when it breaks. You don't have to understand it line by line, but you do have to understand the flow: where does the data come from, where is it transformed, where is it written. If you can't answer those three questions, what you have isn't a tool — it's a black box.

2. No error handling. The first version always solves the happy path. On the first malformed file it either stops, or worse, produces a wrong output without any warning. A system that stops annoys you and gets fixed; a system that silently produces wrong results goes unnoticed for weeks. The second is far more expensive.

3. No backup and no rollback. The cost of undoing an automation that wrote the wrong records can exceed all the time that automation ever saved. Before discussing how much time a tool saves, discuss how much time it will cost you on the day it gets something wrong.

4. Dependence on one person. A system that stops when you go on holiday is not a process; it's a habit. This is exactly where the “project with no owner” problem from my last article is born. If you built the tool, someone other than you must be able to run it.

5. Shadow systems. Tools IT doesn't know about, that never passed a security review, and whose data destination is unclear. Organising files in your own folder, that's fine. Customer lists, pricing or contracts are an entirely different matter.

📏 How Far on Your Own, and Where Should a Professional Step In?

You can draw a fairly clear line here. Safe to build yourself:

• Single-user, internal-facing

• Steps that can be undone

• Reading, compiling, drafting

• Things where a failure doesn't stop the business

Don't do alone:

• Team-wide, multi-user

• Anything with financial or irreversible consequences

• Anything writing permanent records into a system

• Outputs that reach the customer directly

• Critical flows where a failure stops the business

A simple rule: if a mistake by the tool would only embarrass you, build it yourself. If it would cost the company money, don't build it alone.

✅ 5 Rules for Anyone Building Their Own Tool

1️⃣ Solve exactly one pain. Don't build a tool that does everything; build one that does a single job all the way to the end. Narrow, but end to end — the sentence I keep repeating in this series.

2️⃣ Test with your dirtiest data. Collect the 20 worst examples you have and run the tool on those. A tool that works on clean data hasn't proven anything yet.

3️⃣ Log every step. When it ran, which file it processed, what it produced. That's the only way you'll ever trace a problem back to its source.

4️⃣ Write one page of documentation. What it does, which folder it watches, where it gets its inputs, where to start when it breaks. That single page is what turns your tool from a hobby into a process.

5️⃣ Route the critical step through a human. Amount, IBAN, tax number, quantity. Trust the design of the process, not the accuracy of the system.

🎯 Final Word

AI shortened the distance between a business idea and a working tool. For people who know the process, that is a genuine opportunity, and there is no good reason to leave it on the table.

But the barrier it removed was only the first-step barrier. Everything after that — error handling, ownership, documentation and trust — is still our job.

“I can build it” is an exciting sentence. But before handing a process over to what you built, the question is always the same: who fixes this when it breaks?