The long-tail realities of on-demand software

More than twenty years ago, a mentor gave me a piece of advice I've never forgotten: never believe that anything you build is temporary, even if you’re told it is. There's never time to come back and improve something already built, and if it works, it works — which is why it stays around.

He was commenting on a tool he had built for collecting data, something thrown together six years earlier as a stopgap. By the time he was mentioning it to me, that "stopgap" had quietly become the backbone of the company’s service stack, and we were building bigger layers on top of it. Nobody had decided to make it a critical piece of our business, it just became that. The advice to never assume something is temporary has never been more relevant than it is right now, because we've just handed the ability to build software to everyone, and chances are they’re focused on solving problems today, not thinking about its continued use months and potentially years later.

On-demand software is already reshaping development.

You've probably heard it called vibe coding: you describe what you want in plain language, an AI writes the code, and you get something that runs — often without anyone reading a line of it. Out of that comes on-demand software. A tool spun up in an afternoon to solve one immediate problem, frequently by someone who has never thought of themselves as a developer.

The appeal is obvious, and it's real. Why pay for another single-purpose tool or subscription when you can generate the exact thing you need in an hour? On-demand software is quietly replacing entire categories of small SaaS tools and one-off utilities, and for a lot of quick problems, that's a genuinely good trade.

That’s where my mentor's voice gets loud.

The tool you built last quarter is still in use, and needs fixes.

Nobody sets out to build software that lasts a decade. They set out to solve a problem by Friday. But the thing that solves the problem by Friday is still running the following spring, because it works, and because no one has time to work on something that already works. The "temporary" label was never a plan. It was a hope.

So the question stops being can you build it and becomes who supports it in eighteen months. When the person who generated the tool has moved on, when the AI that wrote it has moved three versions ahead, when the one edge case it never handled finally shows up in production — who fixes that code? On-demand software tends to be short-sighted by design. It optimizes for the moment it's created and goes quiet about every moment after. Chances are you can vibe code a tool in an afternoon, but will you maintain it over time?

Developers didn't get lucky. They built systems.

Working developers live with the same truth — that everything they ship might outlive its purpose — and they've spent decades building systems so it doesn't hurt. It's worth naming them, because they're the exact things on-demand software often skips:

• Code persistence and revision history: Ensure nothing important lives only in one person's chat window and every change can be traced, explained and undone.

• Peer-reviewed gating: Prevent any one author from being the only person who has ever understood how a thing works before it reaches production.

• Predictable, repeatable deployments: Turn shipping a fix into a routine act rather than an act of courage.

• Documentation: Make the software legible to people who were never in the room when it was built — the next developer, a new hire, a partner, an auditor — instead of living only in the head of whoever generated it.

That last one is where business continuity lives. A tool that only its author understands is a tool that walks out the door when they do. Documentation and external visibility are what turn a personal shortcut into something a business actually owns — something that survives a resignation, an acquisition or a due-diligence review without a scramble to reverse-engineer what it does.

None of that is bureaucracy. It's what lets software survive contact with time and with other people. And it raises the real question hanging over this whole shift: will on-demand builders ramp up on those disciplines themselves? Will they always need someone else standing behind them to carry the software the moment "it works" stops being enough, or will existing systems evolve and new tools be built to support non-traditional creators? These paths lead to a new breed of developers or a bunch of orphaned tools looking for a parent.

The more exciting bet is the coordinated one.

It would be easy to read all this as a warning, and it isn't. The same AI that produces a throwaway tool becomes far more interesting when you incorporate it into a system that was built to hold together.

When everything runs on shared conventions and shared infrastructure — a real component library, a known deployment path, one coherent way things fit together — the tools you build stop being isolated. A feature you build once becomes a feature in a bigger picture. A pattern you prove in one place compounds across every place. You can see the whole system at once, reason about it, and extend it with confidence, because it was designed to be extended.

That's the part we find genuinely exciting at Alloy. A quick on-demand tool can impress you in an afternoon. A coordinated system lets a small team do things that afternoon-tools can't reach — and it keeps doing them next year, because it was never pretending to be temporary in the first place.

The suggested future here isn't fewer tools, and it isn't a warning label on AI. It's a simple test worth applying before you generate the next quick fix: build it as if it's going to last, because it likely will if it was useful — whether you meant it to or not.