AI Made Building Cheap. It Made Owning Expensive. That’s Why Standards Matter More Than Ever.

Before we start: this is a personal opinion piece. No survey data, no analyst quadrant — just my own read on where this is heading, from building and monitoring integrations for a living. Disagreement welcome; that’s what the comments are for.

Here’s a prediction that requires no courage at all: your organization will have more applications next year than it has today.

Not because anyone planned it. Because building an app stopped being expensive. Give a domain expert an AI assistant and a free afternoon, and they’ll come back with a working tool — a genuinely useful one, with a nicer UI than the thing IT quoted six months and a steering committee for. This is happening in every company right now, and mostly it’s a good thing.

But building was never the expensive part.

The maintenance bill arrives either way

Every application, no matter who or what wrote it, comes with the same lifetime subscription: dependencies age, APIs it calls get deprecated, certificates expire, the data it was designed around drifts, and the person who understood it changes jobs. That subscription used to be paid in developer hours. Now it’s paid in developer hours and tokens — you can ask the AI to fix and extend the app, and it will, cheerfully, by the hour, at a price. Either way, the currency converts to money.

The awkward economics: AI collapsed the cost of creating software by an order of magnitude, and did much less to the cost of operating it. So the ratio changed. When building is cheap, you build more. When you build more, the operating side of the ledger — the side nobody demos — quietly becomes the whole ledger.

ai-standards-build-vs-operate

Fewer standard apps, more custom ones

There’s a second shift hiding inside the first. For decades, the safe choice was the standardized product: buy the thing 10,000 other companies use, because building your own was madness. That calculation is wobbling. Why tolerate the CRM’s workflow when a tailored tool costs a week? Why buy the nichey integration middleware when the AI can generate exactly the glue you need?

So the portfolio inverts: the count of standardized, off-the-shelf applications goes down, and the count of custom-built ones goes up. Each custom app is a little more perfectly fitted to your business — and a little more yours to keep alive. The 10,000 other companies aren’t finding your bugs anymore. You are. Ideally before your customers do, which is a monitoring problem.

And these apps don’t sit alone. They call each other. They call the ERP, the queue, the partner’s API. Every new custom tool is another integration edge in a graph that no single person can hold in their head anymore. The failure mode of this world isn’t the app that crashes loudly — it’s the flow between two apps that stops silently on a Friday afternoon.

The one thing pushing back: standards

Here’s the part I find almost funny. In a world where every app is bespoke, the highest-value thing left to standardize is how they tell you they’re in trouble.

You can’t standardize the apps anymore — that ship has sailed, piloted by an enthusiastic language model. But you can standardize the telemetry. One protocol for emitting traces, metrics, and logs. One set of semantic conventions so a “request” means the same thing whether the code came from a senior engineer, a vendor, or a prompt. One collector pipeline you point everything at, instead of one proprietary agent per tool.

That’s OpenTelemetry. It’s vendor-neutral, it’s a CNCF standard, and — this matters in the AI context — it’s extremely well represented in the training data. Ask an AI assistant to instrument the app it just wrote with OTel, and it usually does a respectable job, because it has seen the conventions ten thousand times. Your custom apps can be as weird as your business needs them to be, and their telemetry can still all speak the same language. The apps diverge; the observability converges.

ai-standards-convergence

This is also, not coincidentally, the bet we made with Sluicio. We didn’t build proprietary agents, because in the world described above, proprietary agents are a tax on every new app you create. Sluicio ingests standard OTLP from a standard Collector and models what integration teams actually care about — the flows between the systems, not just the systems. When your portfolio doubles, your instrumentation approach shouldn’t have to change; you point the new thing at the same pipeline.

Not friction-free. Easier.

I want to be honest about the size of this claim, because the observability industry has a habit of promising weather control. Standards don’t make operating fifty custom apps painless. You still have to decide what to alert on. You still have to teach the AI (or the intern, or yourself) which spans matter. Semantic conventions get argued about. Instrumentation has gaps.

What a standard buys you is that the problem stays one problem. Fifty apps with OpenTelemetry is one telemetry estate with fifty sources. Fifty apps with fifty bespoke logging schemes is fifty separate archaeology projects, scheduled for the worst possible moment.

Easier, not friction-free. In infrastructure, that’s about as good as promises get — and it compounds. Every app you add to a standardized pipeline costs less to observe than the one before it. Every app you add to a bespoke setup costs more.

The AI wave is going to fill your organization with software. Most of it will be useful. All of it will need watching. Pick the standard before the wave picks your schedule.