Cheap to build, not cheap to own

AI-assisted building lowers the cost of a first version to hours. The costs that remain show up later, in review, maintenance, running costs and tools nobody owns.

How build versus buy shifts

01A prototype takes hoursAn idea can be tested before anyone writes a business case. That changes which ideas get tried at all.
02The long tail becomes reachableWork that was too small to buy or staff can now be built by the people who know it. Emerson reports $52,754 in vendor costs avoided in the first months of its access platform.
03Buying still wins for common problemsWhere the market is mature, a vendor carries upgrades, support, accessibility and contract terms on data. Rebuilding that is rarely cheaper.
04Configuration sits in betweenLow-code platforms and extensible enterprise systems often get most of the value with less to own. Platforms

Total cost

Where the cost actually goes

The build is the smallest line. The continuum’s “Cost to watch” row shows how the mix changes by band.

Cost	When it shows up	What keeps it in check
Build time	Up front; usually small	A short spec and a clear scope
Review and verification	Every change	Review scaled to the control tier, not applied the same way everywhere
Maintenance	Ongoing: dependencies, model changes, platform updates	A catalog of approved models with retirement dates; version control
Support and monitoring	After launch, when it breaks	A named owner and a support path before others rely on it. Promotion signals
Token and API spend	Every run; grows with agents and loops	Per-team budgets, alerts and a kill switch. Shared budget case
Orphaned tools	When the builder moves on	A registry entry and offboarding that reassigns or retires the tool
Proliferation	When many tools solve the same problem without integrating	Enterprise fit checks before building

Decision signals

Buy, build or neither

A cheaper path is still a cost if nobody wanted the result or nobody can keep it running.

Buy or configure

When the problem is common

A mature market already serves it
The vendor carries compliance, accessibility and data terms
It is, or feeds, a system of record
Nobody is available to own custom code

Build with AI-assisted methods

When the work is local

The process is niche or specific to the institution
A domain expert is available and involved
The data fits approved tools
There is an owner and an exit path

Don’t build

Even when it’s cheap

Nobody will own it
It duplicates an enterprise capability
It makes high-stakes decisions you can’t validate
The real problem is a process or policy
There’s no way to tell whether it helped

Speed

Faster pilots, sooner questions

Faster experiments surface value sooner and kill weak ideas cheaply. They also bring ownership questions sooner: a prototype can have users within a week.

01Set the exit path at the startDecide whether it will be retired, handed off or promoted, and what would trigger each.
02Time-box pilotsGive every pilot a review date. When it arrives, keep, change or stop.
03Count people’s timeA domain expert building a tool isn’t doing their day job. That time is the largest cost on many projects.
04Decide who pays to run itAgree before launch who covers tokens, hosting and support once the pilot ends.

Keep the economics grounded

Controls that already cover this

Operating controls: budgets, rate limits, kill switch, registry and offboarding
The shared token budget: what happens when one loop drains a shared pool
Enterprise fit: four checks before building
Governance checklist: who sets budgets and who owns what

Dollar figures are as reported by Emerson College.

Next: see the continuum, or jump to what it takes to move from experiment to production.