In March 2024, OpenAI released GPT-4 Turbo with a 128K context window. Three months later, Claude 3.5 Sonnet landed with meaningfully better reasoning. By December, Google shipped Gemini 2.0. Every one of those releases changed the architecture assumptions underneath any AI support system built on the previous model.

If your engineering team built an AI support agent on GPT-4 in early 2024, they've already had to make at least two significant rebuild decisions by now. That's the part nobody talks about when the "build" conversation starts.

The V1 trap

Every competent engineering team can build a V1. That's the problem. A basic retrieval-augmented generation setup that pulls from your knowledge base and generates answers to simple questions is genuinely not that hard. A senior engineer can have a working prototype in a few weeks. It answers easy questions, the demo looks great, and leadership signs off on a roadmap.

What happens next is predictable. The prototype handles the 30% of tickets that are simple lookups - password resets, return policies, hours of operation. But the remaining 70% require understanding context, following multi-step processes, taking actions in backend systems, and knowing when to escalate. Building for that second tier is a fundamentally different problem than building V1, and it typically takes 3-5x the original build timeline.

The V1 trap works because it creates a false sense of progress. You've spent $80K in engineering time, you have a working demo, and walking away feels like waste. So you keep building. This is the sunk cost fallacy wearing a technical disguise.

The rebuild cycle nobody budgets for

The 3-year cost model for building in-house AI support looks nothing like what gets approved in the original business case.

Year 1 is the build. Two engineers, six months to get V1 live, another four months to iterate it toward production quality. At a fully loaded cost of $175K per engineer, that's $350K before you've handled a single real ticket at scale. You start getting meaningful AI resolution around month 10.

Year 2 is the first rebuild. The foundation model you built on has been superseded. A new architecture - maybe agentic workflows, maybe a different retrieval approach - offers meaningfully better performance. Your team spends three months evaluating, two months rebuilding core components, and the rest of the year stabilizing. You also need at least 0.5 FTE on ongoing maintenance, prompt tuning, and edge case management. That's another $260K.

Year 3 is the second rebuild, or the year your best engineer on the project leaves and you discover how much institutional knowledge walked out the door with them. Either way, you're spending $175K-$260K again.

The 3-year total lands somewhere around $500K-$870K depending on team size and salary levels. And that's just the direct cost - it doesn't account for the opportunity cost of those engineers not building your actual product.

Opportunity cost is the real number

A Series B support technology company allocated two senior engineers to build an internal AI support agent in early 2024. Those engineers spent 14 months on the project before the company switched to a vendor solution. The AI agent they built handled roughly 20% of inbound volume by the time they sunset it.

The CTO later estimated the opportunity cost at over $600K when you factored in the product features those engineers would have otherwise shipped. Two senior engineers over 14 months is meaningful product velocity - features that drive revenue, reduce churn, or open new markets.

This is the calculation that rarely makes it into the build-vs-buy spreadsheet. Engineering capacity is finite. Every sprint spent maintaining an AI support system is a sprint not spent on your core product. For most companies, AI-powered customer support is not the product, it's infrastructure.

When building actually makes sense

Building makes sense in exactly one scenario: when your support operation is so unique that no vendor can accommodate it, and AI support is a core competitive differentiator for your business.

If you're a developer tools company where the support experience is indistinguishable from the product experience, that might be you. If you're running a consumer fintech app where regulatory requirements create genuinely novel support workflows that no horizontal platform can handle, maybe.

For the other 95% of companies, the support workflows are more similar than different. Customers ask questions, need status updates, want to make changes to their accounts, and occasionally need complex multi-step resolutions. The specifics vary by industry, but the patterns don't. That's exactly the kind of problem where buying a purpose-built solution beats building a custom one.

The vendor equation

The buy side of the comparison is simpler math. Integration takes 2-4 weeks of engineering time for most modern platforms, not months. Ongoing administration is a part-time responsibility for a CX operations person, not a full-time engineering role. And the vendor absorbs the model upgrade cycles, the architecture shifts, and the maintenance burden.

A typical vendor engagement runs $4K-$6K per month depending on volume, with time to value measured in weeks rather than months. Over three years, that's $144K-$216K - less than half the build cost in most scenarios, with AI handling tickets from month 2 instead of month 10.

That eight-month gap in time to value matters more than it looks on a spreadsheet. Eight months of tickets handled by AI at even 30% automation is meaningful headcount capacity freed up, faster response times delivered, and operational data collected that improves the system.

Running your own numbers

The framework is straightforward: compare the 3-year fully loaded cost of building (including rebuild cycles, maintenance, and opportunity cost) against the 3-year cost of buying (including integration, administration, and vendor fees). Then factor in time to value - when each option starts actually resolving tickets.

We built an interactive calculator at lorikeet.tools/build-vs-buy that runs this comparison with your actual numbers. Plug in your engineering salaries, estimated build timeline, and vendor costs. The default scenario shows a $344K gap over three years ($522K build vs $178.5K buy), but the point isn't the default - it's what happens when you use your real inputs. Adjust the rebuild assumptions, change the engineer count, update the salary numbers. The gap narrows or widens, but in almost every scenario, it doesn't close.

The decision that matters

The build-vs-buy question isn't really a technical question, it's a capital allocation question. Your engineering team can build an AI support agent. The question is whether they should, given what else they could build with that same time and budget.

The companies getting this right are the ones who separate ego from analysis. Yes, your engineers are talented enough to build it. No, that doesn't mean building it is the highest-value use of their next 18 months. Run the numbers with honest assumptions about rebuild cycles and maintenance burden. The answer is usually clear, and it's usually buy. But before you sign a vendor contract, make sure your team is ready to deploy AI effectively — buying a platform doesn't help if the operational foundation isn't there.