Custom Tool Development With an AI Agent

I manage 43 ad accounts and 16 WordPress sites single-handedly — not with manpower, but by directing AI coding agents like Claude Code. This service is the same method: I build a small, working tool to your needs, but instead of weeks like a classic software team, I do it in days.

I need to state the limits upfront: this isn’t the right method for a SaaS product that needs to scale, or for critical infrastructure. But for an internal tool, a panel, or an automation script that makes daily work easier for one person or a small team, it’s a fast and fitting way to go.

What this method is good for, and what it isn’t

AI coding agents can understand a request and produce real, working code — a small web panel, a data-processing script, an API integration. Where it works well: clearly defined tools that solve a single job.

Where it doesn’t work well: multi-user, security-critical systems that will be maintained by a large team long-term. If you have that kind of need, I’ll say so upfront and point you to a real software team.

How we work

I connect remotely by screen-sharing, or you describe the need in writing, I build it with an AI agent and show you the result. A small tool is usually working within a few hours, something a bit more involved within 2-3 days.

We work on hourly billing — if the scope isn’t clear, we build a small prototype first and continue from there, so you’re not committing to a large budget upfront.

Example work

Examples of what I’ve built with this method so far: turning an Excel file into a web-based panel, a script that merges data from multiple sources into a single table, a small tool that regularly pulls data from a specific API and reports it.

The source code is entirely yours, and you can hand it off to someone else whenever you want — I don’t set up a model that keeps you dependent on me.

How do we start? First, a free 20–30 minute intro call. We talk about what you want and what’s realistic. If it makes sense, I send the scope and price in writing, then we start. You can reach me from the contact page.

The five steps I follow when building a tool

1. Narrowing down the need. Most of the first call goes here. “Let’s move Excel to the web” isn’t a need; “three people should be able to log in at the same time and see who changed what” is a need. Requests that aren’t narrowed down turn into tools that go unused after they’re built.

2. Clarifying the data source. Where the tool gets its data from, where it writes to. Usually the step with the most surprises.

3. A working prototype. Not complete — working. Within a few hours you have something you can try; you decide whether to continue based on that.

4. Testing with real data. Everything works with sample data. The real test is whether it works with your actual, messy data.

5. Handover. The code, the instructions to run it, and how to modify it. The job isn’t done without this step.

What “the code stays yours” actually means in practice

Everyone says this sentence, and most of the time it doesn’t mean anything. What I concretely mean is these four things: the full source code (in a repository, under your access), run instructions (how to get it running with zero prior knowledge), a dependency list (which services, which keys are needed), known limits (what it doesn’t do, where it breaks).

The fourth is the most important and the least often given. Knowing in writing what a tool doesn’t do is what the person who takes it over later needs most.

Keys and accounts are also opened in your name — I don’t build a setup that runs through my own account, because then it’s not really yours.

The weak points of AI-written code — and what I do about them

I stand behind this method, but not blindly. AI agent-generated code has three known weak points.

Error handling. It’s easy to write code that works when everything goes right; what happens when the internet drops, a file arrives corrupted, a service doesn’t respond — that usually gets left out. I separately test and complete this.

Edge cases. Empty lists, single-line files, Turkish characters, very large data. This is why I test with real data.

Security habits. Things like keys getting written directly into the code happen. I move these into separate configuration before handover.

In short: the agent writes fast, the responsibility stays with me. “AI wrote it” isn’t an excuse.

How the cost is made up

There are two line items. My time — clarifying the need, building it, testing, and handover. The tools’ own cost — the AI subscription used and any hosting, if applicable. The second goes through your own account, independent of me.

If the scope is unclear, we first agree on a small prototype. That way, without committing to a large budget upfront, you see something working and then decide whether to continue. Deciding not to continue is entirely reasonable too — at that point you’re left with a working prototype.

Frequently Asked Questions

Is a real developer doing this, or is it all AI?

Both together. The AI agent writes the code, I define what’s being asked for, and I test and fix what comes out. I’m responsible for the resulting code — I don’t say “AI wrote it, I don’t know.”

How long does it take to finish?

A small tool (a single-function script, a simple panel) is done in a few hours; a system with multiple parts becomes working within 2-3 days. If it’s bigger than that, I say so upfront — it’s outside this service’s scope.

Do I keep the source code?

Yes, entirely. When I deliver, I explain the code and how it works — someone else can continue it if you want. I don’t leave you dependent on me.

What kind of work isn’t this service suited for?

Not suited for multi-user systems, systems that process payments, hold personal data, or are security-critical. If you have that kind of need, I’ll say so honestly and recommend working with a real software team.

What’s the code quality like — can someone else maintain it later?

Yes, I deliberately make sure of this. What I deliver isn’t just the code itself; it includes run instructions, a dependency list, and known limits in writing. A developer can continue from there.

What if the tool breaks one day?

Usually the reason it breaks is a service it connects to has changed. If you write to me I’ll take a look, but since you have the dependency list, someone else can too. I don’t build this to force you to call me.

For what kind of work is this method better than classic development?

For work with small scope, few users, and needs specific to you. Internal tools that make a team’s daily work easier fit exactly this description. As the number of users grows, or payments or personal data get involved, classic development becomes the more correct choice.