Every client I've worked with asks the same thing around launch week. "Once you hand it over — are we done?"
Almost. The building phase ends. Two other things begin. They're often bundled into a single vague line on a proposal, and that's where the confusion starts. They are not the same thing.
What support actually is
Support is what happens when someone on your team runs into a problem.
They can't log in. The monthly report isn't showing the right numbers. A new employee doesn't know how to process a return. Something breaks, or something confuses someone, and they need help. Support is reactive by definition — it shows up when it shows up. The only question is who handles it when it does.
What maintenance actually is
This is where most business owners' mental model breaks down — not because they're not paying attention, but because software looks finished when it ships.
It isn't.
When we deliver software, it runs in a specific environment: specific browser versions, specific operating systems, specific third-party services it connects to. That environment does not stay still. Browsers update. Security researchers discover vulnerabilities. The accounting system you integrate with changes how its connection works. The server needs patches. None of this happens on a schedule you control. None of it is anyone's fault.
Maintenance is the proactive, scheduled work of keeping the system current with the world around it. Checking for vulnerabilities. Running updates carefully. Verifying that integrations still work after the outside world changed something. Keeping backups healthy and tested.
Think of it like a building. Support is calling a plumber when the pipe bursts. Maintenance is the annual inspection so the pipe doesn't burst in the first place.
Why we separate them in every proposal
Most software proposals bundle both under "post-launch support." One line item, vague scope, unclear ownership. That's how mismatched expectations happen six months after delivery.
We separate them for two reasons.
First: the nature of the work is different. Support is unpredictable — questions arrive when they arrive, and you can't plan the volume or the timing. Maintenance is plannable. We know when updates roll out, we schedule checks in advance, and we run the work before something becomes an emergency.
Second: your team can probably handle one of them. Most businesses with a good internal point person can manage day-to-day support — someone who knows the system well enough to answer colleagues' questions and escalates only when something is genuinely broken. That's a sensible model for many teams.
Maintenance is a different conversation. Knowing which update is safe to apply, what to test afterward, and what might quietly break in the process — that requires knowing how the software was built. Handing maintenance to someone unfamiliar with the codebase is not necessarily wrong, but it carries real risk. They'll either touch nothing (which is its own kind of problem) or touch too much without understanding what breaks downstream.
This is why our proposals list them separately, with separate scopes and separate pricing. You might own one of them. We almost certainly need to own the other.
What happens when you skip one
Skip support: your team builds workarounds. Features they find confusing get quietly abandoned. New employees pick up bad habits from colleagues who also never got proper help. The software gets blamed when the real issue is the absence of guidance after handover.
Skip maintenance: everything is fine — until it isn't. A browser update changes how a form behaves. A security gap opens in a library the system depends on. An integration with your ERP breaks because the other service changed its rules. These aren't dramatic crashes with obvious causes. They're slow, invisible failures that surface as frustration, wrong data, or one day a breach nobody saw coming.
Software doesn't expire on a shelf. It runs in a world that keeps changing. Maintenance is how you keep up.
