The Build Got Cheap. The Handoffs Didn't.

AI made the execution cheaper. The bigger change is what happens when the person who understands the business can direct the build without translating the problem through five other people first.

In June, a client asked me for two things: a safe foundation for the AI their team was already using, and a set of assistants the team could actually rely on.

Three months later, the security review had determined the order of the work that followed it. Applications holding client data had moved off the no-code environment they were built on and onto infrastructure the client owns. There was a new operating platform for accounts, documents and approvals. A live event platform was running for sponsors and attendees. The documentation site had grown to 101 pages and updated with the code. A developer on the client's team was contributing directly to the platform.

The following weekend, the new company website went live.

One quarter. One operator holding the problem end to end.

That doesn't mean one person wrote every line. By the end of the sprint, a developer on the client's side had contributed 84 commits to the core platform. It means the business problem did not have to be re-explained every time the work changed shape.

When I walk people through that, the question is almost always about the tools. Which model? Which coding agents? What does the setup look like?

It's a reasonable question. It's aimed at the wrong half of the story.

The tools made the build cheap. What made it fast was that nothing had to be translated.

The build got cheap. The translation didn't.

Every media company I've worked in had the same project on the wall. Everybody agreed it mattered. It had a budget line. And it was always about six months from done.

You know the shape of it.

The revenue side knows what's broken. Someone writes it up. Product or IT turns the write-up into requirements. A vendor or agency turns the requirements into a statement of work, then a discovery phase, then a design review. Developers build what the documents say.

Then the first version comes back and the person who raised the problem in the first place says the sentence everybody dreads:

"That's not what we meant."

Nobody in that chain did bad work. Every handoff was reasonable.

But each one took time, and each one created another opportunity for the meaning to change. The person who knew the customer explained it to someone who knew requirements, who explained it to someone who knew design, who explained it to someone who knew software. By the time the thing shipped, it answered a slightly different question from the one the business asked, months after the business asked it.

AI didn't fix that chain.

It made the last link cheap enough that you can finally see how expensive the rest of it was.

Promethean Research's 2026 agency data is already showing the economic pressure. AI is reducing the time required for execution across coding, writing, analysis and design, while agencies built around selling time are being forced to reconsider where their value sits.

The production cost changed.

The organization around the production mostly hasn't.

Most of the calendar is the handoffs

Brooks made the geometry explicit. When work has to be coordinated across n people, there can be n(n-1)/2 pairwise communication paths. Two people have one. Five have ten. Six have fifteen.

None of those lines is automatically waste. Every one is another place the meaning has to survive.

Brooks' famous warning in The Mythical Man-Month was about adding people to a software project that was already behind schedule, not about keeping teams artificially small. But the argument underneath it is broader: people and time aren't interchangeable when the work has to be coordinated. Adding capacity also adds training, communication and context that have to be carried across the team.

Modern software-delivery research points at the same problem from another direction. DORA's value-stream guidance tells teams to measure the waiting between steps and pay particular attention to handoffs between teams because they are common sources of delay and miscommunication.

That waiting is easy to mistake for development time because it lives on the same project calendar.

It's also why software scopes get expensive so quickly. Clutch's current data puts the average reviewed custom-software project at about $132,000 and roughly 13 months. Promethean reports that 29% of digital agencies charge between $175 and $199 an hour. Those aren't estimates for any particular build, and project scopes vary enormously. They do show the economics of moving complicated work through multiple specialized people.

Now take some of the handoffs out.

The person who understands why the renewal process leaks is the same person deciding how the fix gets built. No requirements document has to teach somebody else the business from scratch. No discovery phase has to rediscover what the operator already knows. When the first version is wrong, the person who can see why it's wrong can change the direction immediately.

That's the change AI made possible that interests me much more than faster code.

Building used to be expensive enough that it had to be handed to specialists. Handing it off meant translating it.

For a growing class of internal systems, AI has lowered the execution cost enough that the person with the operating judgment can stay attached to the problem all the way through the build.

Speed on the right work

I've written before that speed on the wrong work just buys you more of the wrong work.

That still holds. It's why the operator matters more than the tools.

Look at the order that quarter ran in.

It didn't start with a demo.

It started with the security review, because the fastest way to hurt a client is to build more capability on top of a foundation that shouldn't be carrying it. The findings changed the build order. The systems holding client information moved first. The exciting things came after the boring things were safe.

Nobody handed me that sequence.

It came from knowing what a services business can survive and what it can't. It's the same judgment that decides which line in the budget gets cut or which customer problem gets fixed first, applied to software.

And the speed came with discipline, not instead of it.

Test suites. Versioned database changes. Proposed actions waiting in an approval queue before they run. Sign-in and access by role. Client-owned accounts. Documentation attached to the code rather than sitting in a forgotten folder six months out of date.

DORA's 2025 research is useful here because it describes AI as an amplifier. Put it inside a strong operating system and it magnifies the strengths. Put it inside fragmented tooling, weak controls and bad processes and it magnifies those too. Faster code generation can simply create faster downstream disorder.

Fast is not fragile.

But fast without a foundation can be.

It can't live in one person's head either

There's an honest objection here, and I made it myself a few notes ago: a business that depends on one person remembering how things work is fragile, however good that person is.

That's right.

Removing the handoffs while something is being built does not mean the finished system should depend on the builder afterward.

Those are two different problems, and you have to solve both.

The rule runs both ways: one person can hold the whole problem while it's being built, but the finished system has to hold what that person knew when the work is done.

The accounts belong to the client. The code sits in the client's repositories. The documentation changes with the software. Architecture decisions, operating instructions and approval rules are written down.

And then there's the test that actually matters.

Can somebody else change it?

By the end of that first quarter, the client's own developer had made 84 commits to the core platform.

That's a more important number to me than how quickly I built it.

If you're considering this model, make that one of the first questions you ask. Not only:

How fast can you build this?

Ask:

Can we run it without you?

What this means for a publisher

Most local media companies cannot staff a software team of four or six people for most of a year, so they've drawn the obvious conclusion: ambitious custom systems aren't for them.

Buy the platform. Wait for the roadmap. Bend the workflow around somebody else's product.

That conclusion made sense when every meaningful build required a team of specialists.

It makes less sense now.

Developers still matter. Security specialists still matter. Architecture still matters. There are plenty of systems a publisher has no business building itself, which is why the build, buy or partner decision still holds.

But raw coding capacity is no longer the only gate.

For a lot of revenue and operating systems, the scarcer thing may be the person who knows exactly why the process is broken, understands what happens economically if you fix the wrong part first, and can hold that judgment all the way through the build.

Sometimes that person is already on your staff and buried in the work.

Sometimes you bring one in for a quarter.

The important distinction is that the person directing the software does not have to hand the problem to someone who has to learn the business from a requirements document before anything can happen.

That's a different question from "which vendor?"

And it produces a very different timeline.

This isn't a promise that every project takes a quarter. Access matters. Data matters. Security matters. Decisions matter. Some systems really are difficult, and AI does not repeal complexity.

But a lot of the projects stuck on the wall aren't stuck because the software is impossibly large.

They're stuck in a long line of people translating for each other.

Count the handoffs

Pick one project everybody agrees matters and nobody can seem to finish.

Then trace it from the person who first understood the problem to the thing that's supposed to ship.

• How many times has the idea changed hands?

• At each handoff, who had to learn the business from a document instead of from doing the work?

• How much of the project calendar is work, and how much is waiting for the next person?

• Who can tell whether the finished thing actually solves the original problem?

• Is that the same person who can change it?

That last question is the one I'd sit with.

If the person who knows it's wrong has to explain the problem to someone who explains it to someone who can fix it, the technology may not be what's making the project slow.

The translation is.

I wake up every morning thinking about ways to save local media, and more and more that means expanding what these businesses believe they can actually build.

The capacity is closer than it looks.

The code got cheaper.

The build got cheap. The handoffs didn't. Take them out.

Sources

• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975; anniversary edition 1995)

• Project Management Institute: Understanding — Overcoming Communications Complexity in Projects

• DORA: State of AI-assisted Software Development 2025

• DORA: Value Stream Mapping for Software Delivery

• DORA: Platform Engineering

• Promethean Research: 2026 Digital Agency Industry Report

• Clutch: Software Development Company Pricing Guide