Rethinking the Custom Software Objection

The Maintainability Myth

A business owner told me recently why he’d chosen a well-known commercial platform over a system designed around his firm. Among his reasons was one I hear constantly: if the people who build it ever walked away, he’d be stranded. Finding somebody new to learn a one-off system would be slow, expensive, and uncertain.

That’s a fair concern, and I told him so. It’s also one of the most durable rules of thumb in business technology – which is exactly why it’s overdue for a fresh look.

The assumption underneath it goes like this. “Custom” means built specifically for you rather than off the shelf. To get that customization, builders reach for whatever tools and conventions get the job done, and the result is a system only the authors can really make sense of – or one that would cost a small fortune to hand off to someone else if something went wrong.

And for about the last forty years, that has pretty much been true.

Where organizations genuinely get trapped

The U.S. Government Accountability Office recently examined the federal government’s most critical aging systems and found eleven of them that ranged from 23 and 60 years old. Eight of them use outdated programming languages. The Treasury Department runs two on COBOL and Assembly, supported by what the report calls a dwindling pool of people with the necessary skills. Per the GAO, roughly 80 percent of federal IT spending goes to operating and maintaining what already exists rather than building anything new.

Those systems are hard to service for reasons you can name and diagnose: an obsolete language, business logic that lives in nobody’s documentation, and hardware the manufacturer stopped supporting years ago.

But being purpose-built isn’t what caused the failure. Plenty of perfectly healthy systems are just as purpose-built as these eleven, and they aren’t currently stranded. If customization itself were the issue, you’d expect custom systems to fail at a noticeably higher rate than everything else out there – but they don’t. What actually stranded these is that group of choices specific to those projects, not the fact that they were built to order. Most of those choices were sensible at the time. COBOL was industry standard in the 1960s and 70s, not a fringe pick.

Standard parts, custom arrangement

Today, most developers are building with the same small set of tools. That’s what “commodity technology” means in practice: languages and frameworks so common that finding someone who already knows them is closer to a formality than a search.

The 2025 Stack Overflow survey of roughly 49,000 developers backs that up. Two out of three use JavaScript. Well over half use SQL or Python. Close to half use TypeScript. Node and React lead the framework list, and Postgres and SQL Server lead the databases. However you combine those pieces, you’re drawing from the deepest talent pool in the industry.

A system assembled from those pieces is written in the languages the largest available population of working developers already knows. The arrangement of those pieces can be specific to how your business runs, but the materials belong to everybody.

That distinction changes the continuity math. Sure, hiring somebody to pick up a system written in a vendor’s proprietary scripting language is a challenge. But hiring somebody to pick up a Python and Postgres system is an ordinary recruiting task with a deep candidate pool.

This concept isn’t even unique to software. Think about two custom homes: one is framed with standard lumber, wired to code, and plumbed with fittings you can buy at any hardware store, while the other has hand-forged hardware and a complicated boiler only its original installer understands. Both were built to order. Only one leaves you dependent on a single person with specialized expertise. Conversely, any licensed electrician or plumber can work on the first house, because the parts inside it are the parts they’ve handled their entire career.

Software works the same way, and the fittings matter far more than the floor plan.

The rules are changing

Something else is shrinking that continuity math even further: the cost of onboardingWhen you join us as a new client, we take all the necessary ... someone new onto a well-built system is falling, and falling fast.

The old bottleneck had two parts: how fast a human developer could read unfamiliar code, and that person’s working memory – i.e. how many interdependent pieces they could actively hold in mind at once. Building a map of any system used to take weeks. But that exploration phase is collapsing. Developers no longer start from zero. AI still can’t write the replacement code perfectly. But it meaningfully compresses the “get oriented” phase, which used to be the expensive part.

That said, it’s critical to understand that this collapse cuts both ways. Google’s 2025 DORA report on AI-assisted software development found that AI functions mainly as an amplifier, magnifying an organization’s existing strengths and weaknesses. Applied to a codebase, that’s exactly the catch: point a capable coding agent at a disciplined system with clear naming, current dependencies, and a test suite, and it gets oriented in hours. Point it at a tangle nobody has documented since 2011, and it produces confident changes that break things.

So the onboarding-cost drop isn’t the same for every project. It’s largest for code that was already well-organized – clear naming, current dependencies, a test suite – and smallest for code that wasn’t.

The Four-Question Test

“Custom” sits on a spectrum, and you can place any proposal on it with four questions. Ask them of a vendor before you sign, and of the systems you already depend on now.

What is it built with? Look for languages and frameworks that show up near the top of any developer survey. Treat proprietary scripting languages and platform-specific automation logic as the thing that narrows your options later.

Where does the knowledge live? In someone’s head, or in the code, the documentation, and the written specifications? Ask to see how one feature was documented. That’s more revealing than asking whether documentation exists.

Is there a test suite? Tests are what let somebody new change your system without holding their breath. Without them, every future change is a wager on somebody’s memory.

Who holds the keys? Source code, repository access, data export, hosting credentials – if the contract doesn’t name them, the vendor keeps them by default. Named, a dispute is an inconvenience. Assumed, it could be an emergency.

There’s a gut check that covers all four: could a competent outsider, human or AI, get oriented in about a week? Any vendor should be able to answer that plainly. Better still, ask what happens if you hire somebody else to make the next change. The answer tells you how portable the work is.

The same risk, repackaged

Commercial platforms carry a version of the same risk, just worn differently. Vendors get acquired. Products get sunset. Pricing shifts at renewal once your data is already inside and your team has built five years of habits around the interface. Buying standard software simply relocates the continuity question rather than settling it.

Which brings both options back to the same question: if this relationship ended tomorrow, what would it cost me to move? That number tells you more about your exposure than the word “custom” ever can.

Pick the system your business would miss most on a Monday morning and run it through the four questions. If one of the answers bothers you, you’ve found something worth fixing while it’s still cheap to fix.

If you’d find it useful to run these questions against something you’re evaluating or already living with, I keep time open for exactly that kind of conversation. No deck and no pitch, just a working session on what you have and what it would cost you to change course. You can grab a free consultation with me here.