Why in-house apps so often die unmaintained — and how to avoid that trap

Every business has at least one ghost app—a tool that once seemed like a brilliant idea, built by an internal team or a contractor, now sitting unused or barely functioning. It might be a customer portal, an inventory tracker, or a reporting dashboard. Perhaps it had a launch party. Now, nobody touches it. The original developer has left. Documentation, if it ever existed, is stale. The database schema is a mystery. And the cost of resurrecting it feels higher than starting over.

This pattern is so common it has its own name: “shelfware.” And when we talk to business leaders, they often assume the problem is technical—bad architecture, the wrong programming language, a flawed data model. But in our experience delivering custom web applications for clients, the root cause is almost never technical. It is almost always a failure in the sustainment model—the set of decisions about who owns, maintains, and evolves the app after it goes live.

The three hidden reasons in-house apps fade

We have seen the same three patterns repeat across industries, from legal firms to logistics companies. Recognizing them early is the first step to preventing them.

1. The “build it and forget it” budget

Most internal app projects are approved with a single capital expenditure: the cost of development. Once the app is delivered, the budget line closes. There is no ongoing allocation for minor bug fixes, security patches, or feature tweaks. When a user reports a problem six months later, the request goes to an already-overloaded IT team that has no incentive to touch it. The app becomes a liability.

What we advise clients to evaluate: before signing off on any custom build, ask for a three-year total cost of ownership that includes 15–20% of the original build cost annually for maintenance. If that number feels too high, the app might not be worth building in the first place.

2. The single-developer dependency

When an internal app is built by one person—often a talented but overworked employee—that person becomes the only source of knowledge about how it works. They might have used a niche framework, written unconventional logic, or skipped documentation because “it’s just internal.” When they leave, the app becomes a black box.

We have been called in to rescue several such apps. In every case, the business had to pay a premium to reverse-engineer the code, or worse, rebuild it from scratch. The cost of that rescue often exceeds the original build cost by 50% or more. The mitigation is simple in theory but rarely practiced: enforce code reviews and documentation as part of the delivery process, and ensure at least two team members understand the system.

3. The “we’ll fix it later” feature creep

In-house teams are notorious for piling on requests during development. “Can we just add one more field to the form?” “Oh, and can it also send an email when the status changes?” These small additions seem harmless but accumulate into a fragile system that was never designed for them. The result is an app that works for the original three use cases but breaks on the fourth. Users get frustrated. They stop using it. The app dies.

From a procurement perspective, the solution is scope governance. Define a clear minimum viable product (MVP), and treat every additional feature as a separate project with its own budget and timeline. If the business cannot tolerate that discipline, then a packaged software product—even with its own limitations—may be a safer bet.

When custom apps make sense despite the risks

We are not arguing against building in-house software. For many businesses, custom apps are the only way to handle unique workflows, integrate proprietary data, or differentiate from competitors. The key is to enter the project with eyes open about the maintenance burden.

We have seen successful in-house apps thrive when three conditions are met:

• The app serves a core business function, not a nice-to-have. If it fails, revenue or compliance is directly affected. This ensures ongoing executive attention.
• The business has internal technical leadership—either a CTO, a senior engineer, or a product manager—who treats the app as a product, not a project. They own its roadmap and budget.
• The app is built with maintainability as a first-class goal. That means documented code, automated tests, and a deployment pipeline that does not require a wizard.

How to avoid the trap as a buyer

If you are a business leader procuring a custom web application—whether from an agency, a freelancer, or your own team—ask these questions before committing:

• Who will maintain this app after launch, and what is the budget for that maintenance?
• Is the codebase written in a mainstream technology stack that is easy to hire for? (Avoid obscure frameworks that only one person knows.)
• Will the delivery include automated tests, deployment scripts, and end-user documentation? Or just a “handover” email?
• What happens if the original developer leaves or the agency goes out of business? Is the source code escrowed or fully owned by you?
• Can we run a small pilot with a subset of users before committing to a full build?

These questions are not technical. They are business questions about risk, continuity, and value. If the answers are vague or dismissive, you are likely building the next ghost app.

At AUMCREATE, we have seen too many ambitious projects become silent cost centers. When we build custom applications for clients, we bake sustainment into the proposal—not as an afterthought, but as a core requirement. If your team is evaluating a custom build and wants to avoid the maintenance trap, talk to us.