Build or buy: when custom AI is actually worth it

At some point, a business that has climbed the AI ladder hits a job no off-the-shelf tool quite does. The volume is real, the workflow is yours alone, and someone on the team (or close to it) can code, especially now that tools like Claude Code let one technical person build what used to take a team.

This is the top level of the ladder, and it needs saying plainly: most businesses should not be here, and the ones that should need a discipline before they need a developer. Custom AI is where small businesses burn the most money for the least return, not because building is impossible but because the thing they built already existed for $50 a month.

Who this fits

Three conditions, all required: a specific job with real volume (daily, not monthly), someone technical who would genuinely own the build and its upkeep, and at least one workflow automation already running well. Missing any of the three? You will get more from the previous level. That is not a consolation prize; a well-run automation level often beats a badly run custom one on pure return.

The scoping discipline

Step one: write the job as one sentence

"What goes in, what comes out, who checks it." For example: "Inbound product photos go in, a draft listing with title, description, and category comes out, and the shop manager approves each one." If you cannot write that sentence, you are not ready to build. Vague jobs make expensive software.

Step two: spend one day trying to buy it

Before any code, take one full day and try to do the job with existing tools: an off-the-shelf product, a Claude Project with good instructions, a Zapier chain. Set a bar in advance: if something reaches 80% of what you need, you buy, and you spend your energy on the remaining 20% of process instead.

Most build ideas die honorably here. That is the discipline working, not failing. The market is producing purpose-built AI tools faster than any small team can build them, and every month you wait, the buy option gets better.

Step three: do the real cost math

If nothing passes the 80% test, price the build honestly. Three numbers:

1. Build time, including the technical person's normal duties not getting done.
2. Running cost: API usage at your actual volume. Model calls are cheap per unit and surprising in aggregate; estimate monthly volume and multiply before you commit, not after.
3. Maintenance: who fixes it when a model version changes or an integration breaks. A custom tool with no owner is an outage on a timer. If the honest answer to "who maintains this?" is "nobody, really," buy instead, or do not do it at all.

Step four: define quality checks before writing code

Decide, in advance, what a wrong answer looks like and how you will catch it. Concretely: collect twenty real examples of the job with known-good outputs, and agree what score the system must hit before a human stops reviewing every result. Builders call these evals; you can call it the twenty-example test. Teams that skip this step end up trusting a system nobody ever measured, and they find out at the worst possible moment.

Step five: build the smallest version that works

One workflow, the human checkpoint kept in place, running beside the old process for a few weeks, exactly like your first automation. Expand only on evidence. And keep the shape simple: a reliable pipeline with one AI step almost always beats a clever autonomous agent. Even among large enterprises, only a small fraction of AI deployments are genuinely autonomous systems; most of what gets called an agent is a well-designed workflow, and well-designed workflows are what actually ship.

A word on the tools

Claude Code and similar coding assistants have changed the economics here: a scoped internal tool that once needed a contractor and a month can be a technical founder's focused week. That makes the discipline more important, not less, because the cost of building the wrong thing just dropped below the threshold where anyone stops to ask whether they should. The APIs themselves (Anthropic's, OpenAI's) are the raw material. None of these companies pay us, and the right stack is the one your technical person already knows.

What to expect

A well-scoped custom build on a real-volume job typically pays for itself within a quarter and becomes a genuine competitive edge, because it encodes how your business works rather than how software vendors think businesses work. A badly scoped one becomes unowned infrastructure that everyone is slightly afraid of. The difference was decided back at steps one and two, before any code existed.

The top of the ladder

There is no level six. What sits above custom builds is not more technology; it is the compounding of everything below: clean data, standardized workflows, a team fluent in the tools, and now capabilities shaped exactly to your business. The ladder was never the point. The business was.

If you have read this whole series and want to know where your organization actually stands, and which rung to work on next, that is what our assessment does in about ten minutes of conversation.

This week: write the one-sentence job description, and spend the day trying to buy it.