Build, Buy, or Rent: The AI Decision That Locks Everything Else In

Part five of the AI foundations series. The first four posts were about how this technology works. From here it’s about building with it, starting with the decision that’s most expensive to reverse.

The scenario is familiar. Someone above you watched an AI-first demo or read about agents automating entire departments, and now there’s an all-hands where the message is “AI in everything by Q3.” You saw the same demo. It was impressive. You also have questions.

You should. Because what the demo doesn’t mention is that it might be running on $10,000/month of GPU time, and those instant responses were probably cached from hours of preprocessing. At 3am, when your largest customer is trying to finish something critical, that same system can answer confidently, be completely wrong, and burn budget doing it.

The gap between demo and production is where projects die, not dramatically, but slowly, through emergency fixes and budget overruns.

Three decisions lock in everything else

1. Whether you build, buy, or rent your models.
2. How you architect for real production load.
3. How you handle the strange ways models fail.

This post is the first. The next one is the other two.

Why does the first matter so much? Because it’s expensive to unwind. Spend three months building the wrong thing, or sign a two-year contract for the wrong service, and changing course costs more than starting over.

Four paths, with numbers

Fully custom build. Justified only when you have genuinely unique data that creates an advantage, a quant firm with proprietary signals, a medical imaging company with labeled scans nobody else has. If you’re not protecting something unique, you’re paying for control you don’t need.

Fine-tuning. Sounds like a comfortable middle ground, but it’s still a project. Budget a few months and people who understand not just fine-tuning but data prep, evaluation, and drift. Most companies believe they have quality training data. In reality it’s PDFs, spreadsheets, and emails full of contradictions and stale details.

APIs, the rent option. Someone else already spent the money. You get vendor dependency, but you can design for abstraction.

Vendor products, the buy option. Sometimes the markup is genuinely worth it. Sometimes it’s a polished wrapper over the same API you could call directly.

Here’s the comparison that reframed it for me:

Path	Up front	Ongoing	Realistic timeline
Custom build	~$500K minimum	~$30K/month infrastructure, plus team	12–18 months
Fine-tuning	Months of effort	Retraining + evaluation cycles	3–6 months
API	Near zero	~$850/month for a real application	Days
Vendor product	Contract	~$10K/month	Weeks

Some detail behind those numbers, because the aggregates hide things.

Building. The half-million is a floor, and it assumes everything goes right, you already have ML engineers, your data is clean, and you dodge the thousand technical walls everyone hits. Realistically: at least two senior ML engineers at $250–300K each, GPU infrastructure starting around $10K/month for something small but plausibly $50–200K/month under real training loads, plus someone to keep it all running. Best case you’re over $1M in year one. Competitive is more like $2–5M.

APIs. Work an example. Your assistant averages ~2,000 tokens per query including context and response. At $2 per million tokens, 100,000 queries a month is $400 in base API costs. Add rate limit headroom, fallback models, and monitoring and you’re around $850/month. Manageable and, more importantly, predictable.

Vendors. That “reasonable” $10K/month is $120K/year, so inspect what you’re getting beyond API access. Compliance, SLAs, support, real integration work? Possibly worth it. Prompt engineering and a nice UI? Probably not.

The gap between $850/month and $1M/year deserves a hard look before anyone starts building. And the relief of choosing APIs is real: predictable costs, immediate results, and when a better model ships you change a line of code instead of starting a project.

That said, all four paths can be valid. The point is to evaluate them against real costs and real constraints, not demos and promises.

Red flags when evaluating

If you’ve been building long enough you’ve been burned, vaporware, a framework whose problems never got fixed, six months spent learning something everyone else already knew. Those scars are useful here.

Listen for how they talk about failure. This is the single best signal. If failure never comes up, they haven’t run anything in production. Teams who have will tell you straight: the model that produced garbage at 2am, the cost spike that jumped 100x overnight, the confident response that became a customer service incident. They’ll describe those moments specifically.

Vague pricing. “Contact us for enterprise pricing” often means they’ll charge what they think you’ll pay. Usage-based pricing without clear metrics means you can’t budget, and with AI, usage explodes. One runaway loop, or one eager PM enabling a feature for everyone, and the monthly bill goes from hundreds to tens of thousands. “Flexible pricing models” frequently means they haven’t figured it out.

A build plan promising six months. That’s not a sign of efficiency. It’s a sign the team hasn’t done it before.

“It handles everything.” The biggest flag of all.

The questions it suggested asking are about production behavior rather than demo videos, and I like them because they are hard to answer with a deck:

• What’s your P95 latency?
• Can you show me real error logs from last week?
• What happens when the model produces something wrong, because it will?

Good providers have direct answers. They’ll pull up dashboards, walk through failover, explain rate limits. If the conversation drifts when you ask, that’s your signal.

Start from constraints, not wishes

This is the part I found most useful, and it inverts how most teams approach it.

Most teams start with what they want, real-time AI everywhere, and hit the walls later. Start with the walls instead. Write down three things:

1. Your real budget. Not the slide deck number. The one finance will actually approve.
2. Your real timeline. Not the target date. The one where missing it has consequences.
3. The rules you can’t break. Privacy, data retention, compliance.

Those three lines narrow the field faster than any feature comparison. Watch the options fall away, and be glad they do:

• Can’t use cloud services? Most API options are gone.
• Can’t spend ~$500K? Building from scratch is out.
• Need results this quarter? Fine-tuning is out.

What’s left isn’t a compromise. It’s the path that can actually work.

The constraints cascade. Budget shapes build-versus-rent. Timeline determines whether you can do it properly or need quick wins first. Policy decides where data can live and which integrations are even possible. By the time you’ve written the constraints down, the decision often makes itself.

Write your exit criteria now

Every architecture eventually needs replacing. You’ll outgrow it, requirements will change, or a breakthrough will make the current approach obsolete. That’s not failure, it’s progress.

But changing architectures late is brutal. A switch a year in can cost three to five times the original build, and the code rewrite is the easy part. The hard parts are migrating data, retraining people, and running two systems during the cutover.

So write down, while you’re calm:

• What would trigger a redesign? How much growth, or what fundamental change in requirements?
• How would you migrate? What data must be preserved, what can be rebuilt, what runs in parallel?

Do this before you’re in an incident. No debates under pressure, no decisions made in a panic.

Choose something you can live with, or something you can afford to leave.

Next: the second and third decisions. What actually happens to a naive API call when real traffic hits it, and the failure patterns that only show up in production.