The maintenance gap · 02
It's the question nobody asks at build time, because build time is exciting and maintenance is invisible. Then the freelancer stops answering emails, or the ops manager who built the Airtable empire hands in notice, and a system the business runs on becomes a system nobody understands. Anyone can build it now. That was never the gap.
The engagement ends, the invoice is paid, and the maintenance relationship was never part of the deal. Developer forums are full of the other side of this story - clients whose builder "disappeared mid-project" or after delivery. Not usually malice: freelancers are paid to build, not to answer a broken-webhook email eleven months later. The incentive structure ends at handover.
Every growing company has one: the operations person who built the interlocking spreadsheet-Zapier-Notion machine the whole company quietly depends on. It works beautifully until they resign. What engineers find when they inherit these systems is well documented in their own words: no tests, outdated documentation, original builders gone, a mess nobody wants to own. The tool didn't break - the knowledge walked out the door.
The newest variant. An AI builder produced the app in an afternoon, which was precisely the appeal - no developer needed. But that means no developer exists when it breaks, and the person who prompted it can't read a stack trace. The failure modes of this category earned their own page.
The subtlest version: maintenance was "assigned" to someone with a full-time job doing something else. Unfunded maintenance loses to urgent work every single week, and eighteen months later the result is indistinguishable from having no maintainer at all - as one engineer put it in a widely-read discussion of internal tooling: don't forget maintenance; when was the last forced upgrade because a tool no longer supported its environment?
The word sounds passive - like dusting. It isn't. A production tool has four active jobs attached:
If all three have good answers - build with whatever you like. If any answer is "nobody", the honest options are two: fund the maintainer, or build on a platform that owns the runtime.
Chromoly exists because "nobody" is the most common answer. It generates custom tools and AI automations from plain language - and then the platform does the four jobs: integrations migrated when providers change them, security patches applied, a dependency map that makes change safe, and 24/7 monitoring that alerts before users notice. The builder can leave, the freelancer can finish, the prompter can stay non-technical - the system stays maintained, for the lifetime of the account. That's the whole thesis: anyone can build it; the product is that someone keeps it running.
Four ongoing jobs: integration upkeep as APIs change, platform drift (patches, framework and model migrations), safe change management, and incident response. A tool with nobody doing these has an expiry date.
The documented pattern: no tests, stale docs, code nobody wants to touch. It runs until the first breaking change, then it's a costly rescue or abandonment - true for freelancer code, internal no-code empires, and AI-generated apps alike.
Ask who fixes API changes, who reviews changes for side effects, and who gets alerted on failure. Fund a maintainer (10-20% of build cost/year) or build on a platform that owns the runtime.
Describe what you need in plain language. The platform keeps it running - free tier forever, no credit card.
Start free →