The agency-vs-in-house comparisons all skip the same third option
A search for this topic surfaces mostly agency blogs, and the pattern is consistent: frame the decision as agency versus in-house, walk through the tradeoffs, and land on hiring an agency — their agency — as the sensible middle ground. In-house gets cast as the expensive, slow alternative; the piece rarely mentions that a working system can be bought outright and operated by the buyer's own people.
That framing isn't dishonest so much as incomplete — it's the comparison an agency has a reason to write, not necessarily the one a reader trying to make this decision actually needs. A reader searching this exact phrase is usually already past 'should we use AI at all' and stuck on who should be the one running it day to day, which is a question a two-option framing can't actually answer.
The real dividing line isn't cost — it's who moves when something breaks
With an agency, a fix — or a response to a platform changing its rules — depends on someone else's ticket queue and someone else's priorities that week. That can work fine when things are calm, and it becomes the exact bottleneck that matters most the moment something isn't calm.
With an in-house build, the team owns the full stack and can move the instant it decides to — but building it from zero competes for engineering time against everything else already on the roadmap, and that opportunity cost rarely shows up in a comparison chart.
Owning a system that's already built and handed over sits in between those two failure modes without inheriting either one: the system exists on day one instead of needing to be built, and the fix happens inside the buyer's own walls instead of waiting on a vendor's queue, because the buyer's own team has real access and already knows how it runs.
That combination is why it belongs in the comparison at all. It isn't a compromise between the other two options' downsides — it removes the build-from-zero cost that makes in-house slow to start, and it removes the outside-queue dependency that makes an agency slow to react, without requiring the buyer to have an engineering team large enough to build the equivalent from scratch.
Why the specific cost and timeline figures floating around aren't worth anchoring on
A pattern shows up across this whole genre of article: the same rough shape of comparison — a fast, cheap agency timeline against a slow, expensive in-house build — gets repeated from piece to piece, with the underlying figures shifting noticeably between articles covering the same theoretical scenario and no primary source cited for any of them.
That's worth naming outright rather than repeating: a number with no source behind it, published by a party with a stake in which option looks better, isn't a data point a reader can check — it's a persuasion device dressed up as a fact. This piece intentionally doesn't add another set of numbers to that pile. The decision below runs on an operational test instead, one a reader can actually verify against their own team.
The same caution applies to headcount and timeline claims made in either direction — how long a build 'really' takes, or how many people an agency 'really' needs on an account, varies enormously by scope and is rarely disclosed with enough detail to compare across companies. Treat any of those figures as a sales input from whoever published them, not as a benchmark to plan against.
A short test that sorts the three options without a spreadsheet
Ask one question: if the system broke tonight, who has both the access and the standing knowledge to fix it before tomorrow? If the honest answer is 'a vendor we'd have to email and wait on,' that's the agency model. If it's 'no one — we'd have to build that expertise from scratch first,' that's an in-house build, and it only clears the bar when this is genuinely the team's top priority. If the answer is 'someone on our own team, because they already run this system day to day,' that's an owned system already delivered running.
None of those three answers is wrong in the abstract — each fits a different starting point. The mistake is picking based on a cost table copied from an article with no source, instead of the one question that actually predicts what happens the day something needs fixing fast.