There's a graveyard nobody talks about. It's full of half-built AI assistants, abandoned n8n flows, and Slack channels named "#ai-experiments" that haven't seen a message since the Friday somebody got excited about agents.

Every company between 50 and 500 people has one. Maybe yours too.

The pitch is always the same: "We'll build it in-house. It's just an API call. How hard can it be?"

Reader, it is harder than that.

The Demo Always Works. That's the Problem.

Here's the part nobody puts in the kick-off slide: the demo is the easy part.

You wire up a prompt, hit an LLM endpoint, and out pops something that looks like magic. The COO claps. The engineering lead nods. Somebody schedules a follow-up. Everybody feels productive.

Three weeks later the thing is in "MVP." Six weeks later it's in "production." Six months later it's quietly deprecated in a Notion page titled "Tools We Should Probably Update."

What happened? The demo never actually scaled. It just looked like it would.

The Real Reason DIY AI Projects Die

It's not the model. It's not the prompt. It's not even the tools.

It's that nobody owns the boring parts.

Here's what's actually in scope when you "build it in-house":

None of this shows up in the demo. All of it shows up in production. And by then, the one engineer who built the thing has either burned out, switched teams, or — and this is the classic — left the company.

"We'll Just Hire Someone"

Sure. Let's run the numbers.

A solid AI engineer in the DACH region with actual production experience (not just a HuggingFace tutorial) currently costs you between €90k and €140k a year (based on current DACH market rates). Plus benefits. Plus tooling. Plus a manager who can actually evaluate their work — because if you can't tell good AI engineering from bad, you're just gambling with payroll.

And one of them, on their own, is a single point of failure. So now you need two. Maybe three. Maybe a junior to ladder up. Maybe a Head of AI to coordinate.

Suddenly your "let's just try it" experiment is a €400k-a-year department before anyone's even shipped a paying feature.

This is fine if you're Series B with capital to burn. It is absolutely not fine if you're a 120-person operations company trying to use AI to reduce ticket volume by 30%.

The Three Failure Modes (Pick Your Favorite)

The pattern shows up everywhere across the space — mid-sized companies attempting DIY AI follow predictable failure modes.

1. The Hero Engineer. One person builds the whole stack. It works beautifully — until they take a two-week vacation. Now nobody can deploy a prompt change. By the time they're back, everyone has stopped using the tool because "it's faster to just do it manually."

2. The Pilot Purgatory. The MVP works. It even gets used for a while. But nobody budgeted for v2. So the model gets stale, the integrations break when Notion updates their API, and the tool becomes "that thing we tried last year."

3. The Tool Sprawl. Every department spins up their own. Sales has a GPT-based lead enricher. Support has a n8n flow with a Claude node. Marketing has a Python script. None of them talk to each other. None of them are monitored. All of them are technically running.

If you're nodding right now: yes, we've seen your stack. We've seen everyone's stack.

What Actually Works (Spoiler: It's Boring)

The companies that get real value out of AI in this size range have a few things in common, and none of them are sexy.

They treat AI ops like SRE, not a side project. There's an on-call rotation. There's a status page. There are runbooks. The agent gets paged when it misbehaves, just like any other production service.

They version their prompts like code. Git, PRs, review. A prompt change is a code change. If you wouldn't push a Python script to prod without review, don't push a prompt either.

They measure outcomes, not outputs. "We replied to 4,000 tickets" is not a metric. "Average handle time dropped from 8 minutes to 5, customer satisfaction held steady, and the agent escalated 12% of cases correctly" — that's a metric.

They accept that the boring parts are the actual product. The LLM call is 5% of the work. The other 95% is plumbing, monitoring, fallbacks, evals, retries, versioning, and the documentation nobody wants to write.

So What's the Alternative?

You have two real options.

Option A: Build a proper internal AI engineering function. Budget for it like an engineering team, not a hackathon. Plan for at least three people, a manager, and 12-18 months before you see meaningful ROI. Make peace with the bus factor.

Option B: Hand the boring parts to someone who already does them. Keep your team focused on the domain expertise and business logic — the stuff that's actually yours. Pay a flat fee for the plumbing, the monitoring, the on-call, and the prompt-versioning headaches you don't want.

Most companies in the 50-500 range don't actually need to own the AI stack. They need to use it reliably. Those are very different problems, and conflating them is the single most expensive mistake we see.

The Question Worth Asking

Before you greenlight another in-house AI initiative, ask the person proposing it exactly one question:

"In eighteen months, when the engineer who built this has moved on, who maintains it?"

If the answer is a confident plan with a name attached, great — proceed. If the answer is a long pause, a vague gesture, or "we'll figure that out later," you already know how this ends.

The graveyard is full. You don't need to add to it.

Tired of maintaining the graveyard? We handle the plumbing — state management, monitoring, prompt versioning, on-call — so your team stays focused on the business logic that's actually yours.

See how it works at agentic-movers.com