I build the thing that does it in minutes

A job shows up every week, it takes a few hours, and those hours land on the same day the decisions have to be made. That is the signal. Not that the work is boring, but that it is arriving late because of how long it takes to do.

I do not build on the first week. I let the manual version run until it stops changing shape. A process that is still being argued over is not ready, because anything built now freezes the version that happened to exist today and then defends it, since there is a script saying so.

What gets built is usually smaller than it sounds. One job, done the same way every time, in minutes instead of hours. Nobody is impressed by it, which is roughly the right reaction.

A budget bot that runs daily and flags when something should change. It returns three scenarios, scale up, scale down, hold, and what each one does downstream. It does not move money. It makes the case and a person decides.

The ad platforms, product analytics, CRM and the payment gateways connected into one place, with the business context written down alongside them as a skill. Any revenue or performance question becomes one prompt. The context file is the part that does the work, because an answer is only as good as whether the thing answering knows what a paying customer means in this business.

Creative pipeline automation, where naming, storage, the repository, the links and the push to both ad platforms are one step instead of six. Every asset gets a promo ID the moment it is created, which is what ties a cut back to what it earned six weeks later. And a reporting app with dashboards the marketing team opens daily, which is the only test of these things that counts.

Naming conventions. A join between two tables that disagree about what a transaction is. An ID assigned early enough to survive the rest of the process. A scheduled job that runs at six and sends one message. That is the bulk of it.

The model was never the constraint. The data model underneath it was. Two platforms report the same event differently, the gateway settles on its own clock, and the MMP has a third opinion. Reconciling those three is the project. The interface on top is an afternoon.

Get the plumbing wrong and the tool is worse than nothing, because it answers confidently and budget moves against it the same afternoon. A slow manual number that is right beats a fast one that is quietly off.

Claude Code, ChatGPT and Codex for the building. n8n for the scheduled jobs. Replit, Vercel, Railway and Cloudflare to host whatever comes out. Git, because things get broken and need going back. SQL and the platform APIs underneath all of it.

I am not an engineer. What I bring is knowing the data model well enough to specify it precisely, and the tools close the rest of the gap. Anything that needs real uptime guarantees or a security review is not mine to own, and I say that up front rather than after it breaks.

Some of these started as a written SOP. Some of them stopped there, and that was the right outcome. A procedure people actually follow fixes more than a script nobody maintains.

Every tool has a running cost and it is paid in attention. A platform changes a field name, a job fails silently, and for two weeks the numbers are wrong in a direction nobody checks. A tool that breaks loudly is fine. A tool that breaks quietly is a liability, and the second kind is more common.

Frequency decides it. Something that runs weekly is worth automating. Something that runs once a quarter is worth doing by hand, because by the next quarter the process has changed anyway and you are rebuilding it with less context than you had the first time.

And none of it decides anything. These tools say what the spend did. They cannot say whether it was worth making, whether the ceiling has moved, or whether the number in front of you is real. That judgement sits with whoever holds the budget, and no amount of tooling moves it somewhere more comfortable.