Application Maintenance and Support: Your App Will Break When You Haven’t Changed a Thing

When someone asks me to help build them a software team, the first question is almost always how much it will cost to build and how long it will take.

That’s a rookie question.

Not because budget and timeline don’t matter, but because they treat shipping as the finish line. The cost and the calendar of custom software development are real, but shipping is the starting line, not the end of it. The day your app goes live is the day the real work begins, and most of that work has a name nobody puts in the original budget: application maintenance and support.

I’ve lived this from every side. I co-founded VinSolutions, grew it into the number one customer relationship management (CRM) product in the auto industry, and sold it for $147 million, and that software needed care every single day it ran. Then I founded Stackify, an application performance monitoring (APM) and logging tool whose entire reason for existing was to tell you why your production software was broken. I spent years building the exact tooling that maintenance and support teams depend on, watching 20 to 30 of our own applications throw hundreds of errors a day. At Full Scale, running maintenance and support for clients is now a core part of what we do.

So here’s what I learned the hard way, the part that surprises every founder who hasn’t been through it yet.

Your app will break when you haven’t changed a single line of code.

What application maintenance and support actually is

Application maintenance and support is everything you do to keep a live application working, secure, and useful after it ships. It runs from the day you launch until the day you finally turn the software off for good.

People lump the two words together, but they’re two different jobs, and knowing the difference is half the battle when you’re staffing the function.

Maintenance is the work that changes the code: fixing bugs, patching security holes, upgrading libraries and frameworks, keeping the app compatible with new operating systems and browsers, tuning performance, and building the small improvements users keep asking for. Support is the work that keeps the running system healthy and the users unblocked: monitoring production, catching incidents, answering tickets, being on call when the server falls over at 9 p.m., and telling customers what’s happening when something goes wrong.

You need both. A team that only fixes code but never watches production finds out about outages from angry customers. A team that only answers tickets but never touches the codebase is just a buffer between your users and a problem that never gets fixed.

Here is the practical split:

	Application maintenance	Application support
The job	Change the code	Keep it running
Typical work	Bug fixes, security patches, version upgrades, performance tuning, small features	Monitoring, incident response, on-call, status updates, end-user help
Measured by	Stability, security posture, technical debt	Uptime, response time, time to resolve
Who feels it	Future developers	Today’s users

When vendors sell application maintenance services, or the fuller “application maintenance and support services,” they’re selling some blend of those two columns. The blend you actually need depends on how critical your app is and how much of this your own team can carry.

Why working software breaks when you haven’t touched it

Early in a project I hear the same hopeful line: if the software is built well, it shouldn’t break. I understand why people want that to be true. It isn’t.

Software breaks for a long list of reasons you don’t control, and the better your app is doing, the more of them you’ll hit.

A while back one of our customers had a web page that worked fine most of the time and then randomly wouldn’t load. They’d report it, I’d go check, and it worked perfectly. Next day, same thing. Nobody could reproduce it, so nobody could fix it. Instead of arguing about whose gut feeling was right, I set up a synthetic monitoring check that loaded the page once a minute and logged the result. Within an hour a pattern jumped off the chart. The page got slow for two or three minutes every fifteen minutes, like clockwork. The cause turned out to be a scheduled job quietly cleaning up logging data we didn’t even use, and it was locking the database every time it ran. Nobody wrote a bad line of code. The system just outgrew an assumption.

That’s the shape of almost every maintenance fire. Something outside your code changes, and your code that worked yesterday stops working today.

Your cloud provider pushes an update that changes how a server behaves. A new version of PHP or .NET ships with breaking changes, Apple launches an iOS release that breaks half the App Store, or Chrome quietly changes something in the browser and your interface stops rendering. Sometimes it isn’t a platform at all, just a customer who signs up and uses your product a hundred times harder than anyone before them. At Stackify, most customers sent us five or ten gigabytes of logs a month, and then we onboarded one sending closer to that every hour. Nothing was wrong with the code. It was just never built to swallow that kind of volume, so things slowed down and timed out until we fixed it.

And then there’s the single most reliable application killer I’ve ever seen, the one that’s pure maintenance and nothing else.

Expired SSL certificates have taken down more software than any bug I can name.

Apple decided Safari would only trust certificates under about a year old, so now everyone renews annually instead of every couple of years, and people forget. One overlooked renewal and the whole site goes dark over something that had nothing to do with your product. The good news is you can automate it now with tools like Let’s Encrypt, which is exactly the kind of boring, unglamorous maintenance that quietly saves you.

Security is the version of this that actually scares me. The code you shipped two years ago is full of vulnerabilities that nobody had discovered yet. When one finally surfaces in a framework you depend on, you don’t get to schedule the fix for next quarter. You’re patching now, and patching can mean weeks of work, because pulling in a security fix often drags a whole major-version upgrade along with it.

None of this is optional, and none of it shows up in the build estimate.

What good application maintenance and support looks like

Once you accept that things will break, the question becomes how you find out and how fast you respond. After doing this across a lot of products, here’s what actually separates a maintenance and support function that works from one that just reacts.

It starts with monitoring, because you can’t support what you can’t see. At the bare minimum every production app needs a simple uptime check, something like Pingdom hitting your homepage and login page. If the app makes you money, you need more than that. Real APM, the kind of tool I built at Stackify or what you’d get from Datadog or New Relic, lets you see error rates, slow database queries, and the weird one-off failure that only happens when one specific user does one specific thing. We watched hundreds of errors a day across our apps. Plenty were noise, but you can’t tell signal from noise if you can’t see either.

Good support also runs on clear service levels. Everyone should have a service level agreement (SLA) for uptime, the classic “99.9 percent” promise. Smart teams add service level objectives (SLOs) for the parts of the system that matter most, because your app can be technically “up” while the one feature your customers actually came for is silently failing. You commit to those pieces specifically and watch them.

Then there’s the human side, which is mostly about telling customers the truth quickly. People are far more forgiving than you expect about outages, but they will not forgive silence. You can’t always fix a problem instantly, but you can acknowledge it instantly. A status page, like the Atlassian Statuspage product that starts around $30 a month, lets customers see what’s happening and subscribe to updates, which turns a panicked support flood into a quiet “we know, we’re on it.”

The last piece is planning for the unplanned. A real maintenance backlog is mostly homework that keeps the machine running, not new features: security patches, compliance work like GDPR or SOC 2, and framework upgrades the cloud provider is forcing on you. This work is invisible to customers and easy to deprioritize until it bites. The skill is judging which items are urgent and which aren’t. We once watched a team agonize over upgrading the framework on an internal app that two people used and couldn’t even be reached from the internet, while real exposure sat elsewhere. Maintenance is as much about knowing what to ignore as what to fix, because you can chase a one-off bug down the rabbit hole forever.

Vendors package all of this into what they call application support models, usually drawn as tiers. Level one (L1) is the front line that takes the incoming issue, triages it, and handles the routine stuff. Level two (L2) digs into the harder technical problems L1 can’t resolve. Level three (L3) is the engineers who can actually change the code when the fix isn’t a setting or a restart. Then there’s the question of who staffs those tiers, which is the real decision: you can carry the work on your own engineers, stand up a dedicated team that does nothing else, or augment your staff with people who plug into your existing process. The tier chart matters far less than one thing, though, which is whether a real person owns each of those jobs and has the tooling to do it. A tidy support model with nobody actually watching production is just an org chart.

Why most teams understaff this, and what it costs

Almost nobody budgets enough for this, and the reason is simple. Maintenance and support don’t feel like progress. There’s no launch and no demo, nothing you can put on a slide. So it gets squeezed, deferred, and handed to whoever is cheapest.

That last instinct is the expensive one.

The trap I see most often is treating a live application like a leaky faucet, where you’ll just call someone to fix it when it breaks. Software doesn’t work that way. A developer who doesn’t know your codebase can’t walk in cold and fix it, the way a plumber can size up your drain in five minutes. They don’t know where the bodies are buried, which means they don’t even know where to start.

Every product carries a huge amount of tribal knowledge, the hard-won understanding of why this service talks to that one and what happens if you touch the thing in the corner. When you go for the absolute cheapest option, a freelancer who vanishes mid-sprint or a project shop that rotates a new face onto your account every quarter, that knowledge never accumulates. I call this cheapshoring, optimizing for the lowest rate instead of the outcome, and it fails most reliably on maintenance, because maintenance is the work that most depends on knowing your system.

The people who built it are usually the people who can fix it fastest, so the worst thing you can do to your maintenance is keep churning the team.

There’s a security angle here too. A revolving cast of contractors touching your production code and your customer data is a continuity risk, not just a quality one. The people who stay know your systems, and the ones who leave walk out with the map in their heads.

Every piece of software you build is a bit like adopting a puppy. Bringing it home is the fun part, and then it needs care and feeding every single day for years, whether you feel like it or not, and you don’t get to just forget about it. I wrote a whole separate breakdown of software maintenance around that idea, including the well-documented rule of thumb that maintenance runs the majority of a product’s total lifetime spend. The short version: this is the expensive part, so staffing it with the cheapest available hands is exactly backward.

In-house, or an outside team that sticks around

So who should do this work? You have three honest options. Carry it on your existing engineers, hire a dedicated maintenance and support team, or bring in a partner who runs it as an extension of your staff.

Loading it onto your product engineers is the default, and it works until it doesn’t. The same people building your roadmap get pulled off to chase a production fire, the feature work slips, and on-call burns them out. On-call is nobody’s favorite part of the job, and a team that keeps getting woken up at 1 a.m. is a team that’s quietly heading for burnout.

There’s a second reason to pull this work off your core team, and it might be the bigger one. If you have people who are genuinely great at solving hard problems, the ones who can take a fuzzy idea and turn it into a working prototype, the worst thing you can do is bury them in bug fixes and version upgrades. That work has to get done, but it isn’t what they’re best at, and it isn’t what you’re paying a premium for. Your strongest builders should be on greenfield projects, prototypes, and minimum viable products (MVPs), the work that actually moves the business forward. Hand the maintenance to a separate team that’s set up to own it, and your best people stay pointed at the next big thing instead of last year’s.

This is where a follow-the-sun team changes the math. At Stackify we had users in 60 countries, which meant something was always happening on the platform while our Kansas City office slept. Once we had engineers working the opposite shift, the local team stopped arriving every morning to a stack of overnight tickets. They arrived to solutions. The problems had already been worked while they slept, and you cannot put a price on the engineering leader who finally gets to sleep through the night.

The part that makes this work, though, isn’t the time zone. It’s continuity. An outside team only beats your own people if it stays long enough to learn your system as well as you know it. That’s the whole game, and it’s why I care so much about keeping a team intact. At Full Scale our developer retention runs at 93 percent, in a region where call-center and outsourcing attrition is the highest of any industry in the country. The same engineers stay on your product year after year, building exactly the tribal knowledge that makes maintenance fast. A dedicated team or a staff augmentation model gives you that stability without the overhead of hiring it all in-house. This idea, that engineering value compounds when the people compound, is the spine of my book Product Driven and most of what I believe about building software that lasts.

How Full Scale handles application maintenance and support

We staff maintenance and support the same way we staff everything: with vetted developers and QA engineers who join your team, learn your platform, and stay on it. They aren’t a rotating pool of ticket-takers. They’re the same people month after month, which is the only way the tribal knowledge that makes maintenance fast ever gets built. It’s the same long-term model we run for clients like NavMD, where the team that builds the product is the team that keeps it healthy.

Because our teams are in the Philippines, you also get natural coverage while your in-house engineers are offline, so a problem reported overnight is often solved by morning instead of waiting in a queue. We pair that with serious quality assurance, since most maintenance fires are really the absence of someone watching closely. If you need to put experienced maintenance and support engineers on call for your product, that’s exactly what we do, whether you need to hire QA engineers or build a development team in the Philippines that owns the whole second life of your software.

Your application is never going to be finished. It’s just going to keep running, and running well is a choice you make every month after launch. The teams that treat maintenance and support as a real discipline, with monitoring, clear service levels, and people who actually know the system, are the ones whose software is still thriving years later. The ones who treat it as an afterthought are the ones explaining to customers why the site is down over an expired certificate.