There's a question that used to make my stomach drop a little. "Can you build us a small internal tool for this?" Not because I couldn't do it, but because I knew exactly what saying yes actually meant. Weeks of scoping calls that go nowhere fast, a slow drip of requirements nobody fully agreed on, glue code that nobody enjoys writing, and a deploy that somehow always breaks on a Friday afternoon right as everyone's trying to log off. A tool that's maybe two hundred lines of actual logic, somehow eating an entire month of someone's life.
That's just not true anymore, and honestly the shift caught me off guard the first time I noticed it. So I want to walk through what changed, because I think most people still don't quite believe it until they've done it once themselves.
When I say internal tool, I don't mean someone has a ChatGPT tab open in the background. I mean something small and purpose built that does one job and does it well. Maybe it's a tool that drafts a customer email by pulling context from your CRM and whatever's sitting in your knowledge base. Maybe it's a dashboard that triages inbound leads, scores them, and routes them to whoever should actually own them. Sometimes it's a panel that lets someone on your ops team ask a plain English question about your data without needing to know SQL, with the right guardrails so it doesn't go off the rails. Or a console that quietly checks the overnight numbers and flags anything weird before your morning standup even starts.
All of these used to be multi week builds, every single time, no exceptions. Now they're a day. Sometimes just an afternoon if things go smoothly. Here's roughly how that day actually goes.
The day, broken down
The first half hour is just discovery, and I try really hard to not let it become anything more than that. One call, three questions, that's genuinely it. What does this workflow look like today, step by step. Where is the time actually leaking. What does done look like for version one. I used to chase every possible edge case on this call and honestly it never helped, it just delayed the part where you actually learn what matters, which is putting something real in front of someone.
Then comes an hour for a sketch and what I'd call a data contract, though that sounds fancier than it is. Just a single page wireframe, a screenshot of a rough drawing is genuinely fine. Alongside it a simple list of what fields the tool reads, what it writes, and where those fields actually live. Three columns. This hour, more than any other, is the one everything else refers back to.
"Less typing, more thinking — a nice flip when you're used to it being the other way around."
Next three hours are the actual build, and this is where Claude Code does most of the heavy lifting honestly. I hand it the data contract, a couple of sample inputs with what I expect the output to look like, and ask it to write the acceptance tests before anything else. Then it builds while I review and steer it along. It's not that AI replaces the engineer here, it's more that it takes the parts of the job that were never the interesting part anyway, so I get to spend my actual attention on the decisions that need a human brain behind them.
After that, an hour to wire it into whatever it needs to talk to, your CRM, email, internal systems, whatever's upstream. Most of this is OAuth and webhook plumbing that's been solved a thousand times by now so it moves fast.
Validation, retry logic, proper logging so you can actually see what happened and when, a kill switch in case something needs to stop right now. Building this in on day one costs maybe thirty minutes. Bolting it on later, after something's already gone sideways, costs a week and probably a bit of trust too.
Last half hour, ship it, walk the client through it live, and fix whatever inevitably breaks while we're both staring at the screen together. Everything past this point is just iteration based on how people actually end up using it the following week.
Why Claude Code specifically
I've poked around most of the agentic coding tools out there at this point. A few things keep bringing me back to Claude Code for this kind of work though. It actually operates inside a real repository with real tests, not some sandbox that's disconnected from anything that matters. It can run commands, read what comes back, and correct itself instead of just confidently spitting out a code block and hoping for the best. It's genuinely comfortable with the boring stuff too, environment variables, OAuth, retry handling, all the error states that quietly eat half of any normal build. And when something's actually ambiguous, it tends to just say so rather than guessing wrong with total confidence, which I've come to appreciate more than I expected to.
For automations that don't really need a full standalone app, I'll often reach for n8n alongside it instead. Different shape of problem but the same basic mindset underneath.
What still takes real time, because some things just do
The tooling's gotten a lot better, sure, but a few things haven't changed one bit.
Your data still has to actually be usable, full stop. If your CRM has fourteen contact statuses and three of them secretly mean the exact same thing, no amount of AI fixes that for free, no matter what anyone tells you. That cleanup has to come before the automation, never after.
People also still need an actual reason to open the tool you built them. Software nobody uses doesn't save anyone any time, no matter how cleanly it's built under the hood. A short walkthrough, somewhere easy to send feedback, a check in two weeks later, these things matter more than most people expect going in. Most tools that quietly die off don't die because the code was bad. They die because nobody made adoption part of the actual plan from the start.
And anything touching customer data or money still gets a proper look, every time. Worth doing once and doing it right, rather than skipping it just because the build itself felt fast.
Should you build it, or just buy something
Worth being honest about this before any of the rest even starts. If something off the shelf already covers ninety percent of what you actually need, just buy it. Take the easy win, don't overthink it. But if it only covers sixty percent and that missing forty is where your business genuinely does something different from everyone else, that's worth building yourself. That gap is usually your actual edge, and a generic tool is going to keep fighting you on it forever if you let it.
That break even point has moved hard toward build recently, mostly just because building got so much cheaper than it used to be.
A real one, briefly
There was a 25 person service business losing something like eight hours a week to manually copying form submissions into their CRM, sorting through them, and assigning an owner by hand every single time. We built them a small triage tool instead. The website form hits a webhook, the tool classifies the submission, checks it against the CRM, creates a contact if one doesn't already exist, and posts a message in the right Slack channel with a button to claim it. Every step gets logged along the way.
One day to build it. Eight hours a week handed back to them. It paid for itself before the first week was even over.
Nothing exotic going on there. Just what's genuinely possible now that the engineering loop costs a fraction of what it used to.
Building the tool isn't really the hard part anymore, if I'm being honest. Knowing which one to build first still is. Look for a workflow that touches two systems, happens every week without fail, and currently depends on someone doing pattern matching purely by feel. Sketch it out in an hour. Build it in an afternoon. Ship it before the day's even over.
Bring us the workflow that touches two systems and happens every week. We'll sketch it, build it, and have it running before you'd have finished the first scoping call elsewhere.
Start the conversation →