The Build-vs-Buy Math Just Flipped

For years, most software decisions followed the same logic. If a workflow was common enough, companies bought software for it. CRM systems, reporting tools, internal dashboards, and approval platforms all existed because building custom software was expensive, slow, and difficult to maintain.

That tradeoff shaped the entire industry, but the economics behind it are starting to change.

This week, OpenAI expanded Codex beyond a coding assistant and positioned it as something closer to a delegated engineering system. The product messaging is no longer about helping developers autocomplete code faster. It is about assigning work to an AI agent that can plan tasks, write implementation, debug issues, run tests, and operate across multiple engineering jobs in parallel.

On the surface, it looks like another step in AI-assisted development. In practice, it points to something much larger. The cost of building software is starting to collapse.

Most AI coding tools still operate like copilots. You ask for help, the model responds, and the developer stays inside the loop coordinating every step of the process.

Codex is moving toward a different model. Instead of assisting with implementation, the system is starting to handle implementation directly. Multiple tasks can run simultaneously, work can continue in parallel, and the developer shifts from writing each piece manually to reviewing, guiding, and orchestrating the output.

As implementation becomes dramatically cheaper, the bottleneck starts moving toward judgment. Companies need to decide what should be built, which workflows matter, and how systems should behave once they exist. That shift starts changing the build versus buy equation across software.

A large portion of SaaS was built on one assumption: it was cheaper to buy software than to build custom workflows internally.

That assumption may not hold as strongly anymore.

If AI agents can generate reliable internal tools quickly, companies no longer need to accept generic workflows simply because custom software was too expensive to create. Internal reporting systems, operational dashboards, support tooling, approval workflows, and many lightweight business applications suddenly become economically viable to build in-house.

That does not eliminate SaaS, but it changes where SaaS remains defensible. Products built around shallow abstraction layers or standardized workflows may start to lose pricing power when customers can recreate versions of those workflows internally at a fraction of the historical cost.

Defensibility starts moving toward distribution, proprietary data, embedded operational context, and deep workflow expertise. Those advantages become harder to replace than the interface itself.

This issue of Redeployed is brought to you by Tecla: As AI makes software implementation cheaper, the advantage is no longer in simply generating more code. It is in knowing which systems should be built, how they connect to real workflows, and how they are maintained over time. The teams moving fastest are using AI to expand what they can build internally, while bringing in engineers who can operate across architecture, infrastructure, and AI-assisted development. Tecla helps companies hire senior tech talent in the U.S. and nearshore who already work in these environments, so teams can turn AI leverage into reliable software instead of operational debt.

The companies moving fastest are not treating AI coding agents as replacements for engineering teams. They are treating them as leverage.

Internal tooling projects that once sat at the bottom of the roadmap are suddenly becoming feasible. Teams are experimenting more aggressively because the cost of testing ideas is lower, and product groups are building custom operational software tailored to the way the business actually works instead of forcing workflows into rigid third-party systems.

At the same time, engineering organizations are rethinking where human attention creates the most value. Less time is spent manually implementing repetitive systems, while more time goes into defining architecture, validating outputs, managing governance, and understanding business context.

The promise of delegated engineering is speed. The risk is fragmentation.

When software becomes cheap to generate, companies can end up creating large amounts of poorly governed internal tooling without clear ownership or maintenance plans. Systems multiply faster than organizations can manage them.

An internal tool built quickly with AI still needs security reviews, monitoring, documentation, and long-term maintenance. Someone still owns the consequences when the system breaks.

There is also a financial reality underneath this shift. Cheaper implementation does not necessarily mean cheaper infrastructure. As more systems rely on autonomous agents, inference costs, orchestration complexity, and operational overhead increase alongside them.

The work changes shape, but it does not disappear.

This shift changes what companies need from engineering teams.

The value is no longer concentrated only in writing code manually. It moves toward people who can define systems clearly, manage complexity, and understand how software connects to real operational workflows.

Teams are increasingly looking for engineers who can work across AI systems, architecture, infrastructure, and product logic at the same time. Builders who can supervise delegated engineering systems instead of only implementing tasks directly.

Because once implementation becomes abundant, judgment becomes the scarce layer. The companies that scale best in this environment will not necessarily be the ones generating the most code. They will be the ones making the best decisions about what gets built in the first place.

The companies that benefit most from this shift will not stop buying software entirely, but they will start questioning more of the assumptions behind why they buy it.

Some workflows will still favor specialized SaaS products with deep expertise, trust, and ecosystem advantages. Others will become increasingly economical to build internally using AI-assisted engineering systems.

That creates a new operating question for technology leaders.

Not simply: “Should we use AI?”

But: “Which parts of our business should still be products we rent, and which should become systems we own?”

Because AI is not just changing software development. It is quietly changing the economics of software itself.

Connect With Other Technology Leaders

If you want to connect with other technology leaders having real conversations about AI and how it is changing business, check out GILD Curated Circuit.

More to come…

✔️ The Math on AI Agents Doesn’t Add Up - WIRED

✔️ Vibe coding is coding, period - Fast Company

✔️ For open source programs, AI coding tools are a mixed blessing - TechCrunch