The launch demo went great. Two weeks later your support inbox is a mess: a payment edge case nobody caught, a flaky integration, and three "is this a bug or a feature?" threads with no owner. Your team is already on the next roadmap item, and nobody can say who is accountable for fixing what.
This is the most common failure mode we see after go-live, and it is almost never a code problem. It is a custom software post-launch support problem: no defined tiers, no response commitments, no clear line between warranty work and new work. The result is slow fixes, finger-pointing, and a product that quietly rots while everyone assumes someone else is watching.
The fix is a support model you design before launch, not after the first incident. Here is the framework we use with clients, including how to decide between a retainer and hourly billing, how long a hypercare period should run, and what to put in writing so nothing falls through the cracks.
Key takeaways
- Split support into three tiers: incident response, maintenance, and enhancement, because mixing them is why nobody can prioritize or price the work.
- Run a defined hypercare period after go-live with elevated responsiveness, then step down to steady-state SLAs once volume stabilizes.
- Choose retainer vs hourly based on predictability, not price: steady recurring work favors a retainer; sporadic, low-volume work favors hourly with a cap.
- Put severity definitions and response targets in writing so "urgent" means the same thing to your team and your vendor.
- Track a small set of metrics: reopen rate, time to resolve, and backlog age, to know whether the model is actually working.
Why post-launch support breaks (and what it costs you)
Most custom software is built by a project team with a deadline and a scope. Support, by contrast, has no deadline and no fixed scope. That mismatch is the root cause of nearly every post-launch breakdown.
Three things typically go wrong. First, ownership is ambiguous: the original developers have moved on, and nobody formally inherited the pager. Second, warranty and maintenance blur together: a defect fix and a small enhancement get treated identically, so real bugs queue behind feature requests. Third, there is no severity language, so a cosmetic glitch and a checkout outage both arrive as "urgent."
The cost is not just slow fixes. It is compounding technical debt, a support backlog that never shrinks, and a team that starts avoiding the product because every touch feels like firefighting. A written support model removes the ambiguity before it becomes expensive.
The three support tiers every custom product needs
Before you pick billing or SLAs, separate the work into tiers. Each tier has different urgency, different skills, and a different commercial model.
Tier 1: Incident response
This is break-fix work on something that is live and broken: an outage, a failed payment flow, a security issue, data corruption. It needs a defined severity ladder and a response-time commitment, not a best-effort queue. Tier 1 should be the smallest volume and the highest priority.
Tier 2: Maintenance and hygiene
Dependency upgrades, certificate renewals, minor bug fixes, monitoring alerts, small performance tuning. This work is predictable and recurring, which makes it a natural fit for a monthly allocation rather than per-ticket billing. It is also where most long-term product health is won or lost.
Tier 3: Enhancements and new work
New features, UX changes, and integrations. Treat this as project work with its own scoping and estimates, do not let it consume your incident budget, and do not let it hide inside a maintenance retainer without visibility.
If you are evaluating whether your current partner can carry all three tiers, look at how they handled the build itself. The same discipline that shows up in projects we have shipped: clear scope, honest tradeoffs, is what you want in support.
Designing your hypercare period after go-live
A hypercare period after go-live is a short, defined window where the team stays unusually close to the product: faster response, daily triage, active monitoring, and rapid patching. It exists because launch is when real usage exposes assumptions that testing never could.
What a good hypercare window includes:
- A fixed duration agreed in advance, with an explicit exit date and exit criteria.
- Elevated response targets: tighter than your steady-state SLAs, and staffed by people who know the codebase.
- A daily or near-daily triage ritual to sort incoming issues into Tier 1, Tier 2, and Tier 3.
- A burn-down list of launch defects, reviewed until it is empty or consciously deferred.
- A step-down plan describing what changes when hypercare ends, so the transition is not a surprise.
The most common mistake is an open-ended hypercare that never ends. It feels safe, but it quietly becomes an expensive, undefined retainer with no exit. Put the end date in the contract.
Setting SLAs that mean something
An SLA is only useful if severity is defined precisely. Vague language like "critical issues are addressed promptly" guarantees arguments later.
Write severity definitions around business impact, not technical symptoms:
- Severity 1: the product is unusable or revenue/data is at risk. Response is immediate; work continues until mitigated.
- Severity 2: a major function is impaired but a workaround exists. Respond within the same business day.
- Severity 3: minor or cosmetic issues, no meaningful business impact. Handled in the normal maintenance queue.
- Severity 4: questions, requests, and observations. Answered in batch, not treated as incidents.
Then define two separate numbers for each severity: response time (when a human acknowledges and starts) and resolution target (when it is fixed or mitigated). Conflating them is how vendors promise things they cannot deliver. Also decide your support hours and channel, business hours plus an escalation path is a perfectly reasonable model for most products.
Retainer vs hourly billing: how to choose
The software maintenance retainer vs hourly decision is really a question about predictability. Ask yourself how much support work you expect per month and how variable it is.
- Choose a retainer when you have steady recurring work: monitoring, dependency updates, a known backlog, and a partner who needs to stay familiar with the system. You get priority access and a predictable cost, and the vendor can plan capacity.
- Choose hourly when volume is low or genuinely sporadic, and you are comfortable with variable invoices. Insist on a rate card, a monthly cap, and a minimum notice before work starts.
- Consider a hybrid: a small baseline retainer covering Tier 1 and Tier 2, plus hourly or fixed-bid pricing for Tier 3 enhancements. This is the model most teams land on, because it prices urgency separately from new work.
Two guardrails apply either way. First, require time tracking with descriptions so you can see where hours go. Second, agree on unused-allocation rules: does it roll over, expire, or convert to credit? Get that in writing before you sign.
Who fixes bugs after software launch?
The honest answer is: whoever you name in the contract, with a defined warranty boundary. New custom software typically carries a warranty period where defects, behavior that does not match the agreed specification, are fixed at no additional cost. After that window, defect fixes move into your support tier.
What matters is the boundary. Decide and document:
- What counts as a defect (does not meet spec) versus a change request (new or altered behavior).
- How long the warranty runs and what it covers.
- Who owns third-party failures, a payment provider outage, a cloud region issue, a vendor API change.
- Who holds the credentials, repositories, and infrastructure access if you change vendors.
That last point is not paranoia. A support plan without clean handover terms is a support plan you cannot exit. Make sure you own your code and your access.
A post-launch support plan you can actually run
Pull it together into a one-page operating document. A workable post launch support plan for custom software covers:
- Tiers and scope: what is in each tier, and what is explicitly out.
- Severity definitions with response and resolution targets for each level.
- Support hours and channels, including the escalation path for Severity 1.
- Hypercare window with a start date, end date, and exit criteria.
- Commercial model: retainer, hourly, or hybrid, with caps and rollover rules.
- Warranty boundary and the defect-versus-change-request test.
- Reporting cadence: what you receive monthly and who reviews it.
- Review checkpoint: a scheduled look at volumes and costs, with the option to re-tier.
Review it quarterly. Support models drift: a quiet quarter means you may be over-paying for a retainer, a loud one means your SLAs are too loose. If you would rather have this designed alongside the build than bolted on afterward, that is exactly the kind of engagement our software development services cover, and if you want to pressure-test your current setup, you can talk to our team about it.
Metrics that tell you the model is working
You do not need a dashboard with fifty charts. Track five numbers and review them monthly:
- Time to first response by severity, are you actually meeting the SLA?
- Time to resolve by severity, where do fixes stall?
- Reopen rate: fixes that did not hold are a quality signal, not a volume problem.
- Backlog age: how old is the oldest open item, and is it growing?
- Defect versus enhancement mix: a rising enhancement share usually means the product is healthy and evolving, not failing.
If time to first response is slipping, your severity definitions are probably too broad. If reopen rate is climbing, the issue is engineering quality, not staffing. If backlog age grows every month, your retainer is undersized for the work or Tier 3 is eating Tier 1 capacity.
Frequently Asked Questions
How long should a hypercare period after go-live last?
Long enough to cover the first full cycle of real usage, typically until new defect reports drop to a trickle and your daily triage calls stop finding surprises. The exact length matters less than having a fixed end date and written exit criteria, so hypercare steps down into steady-state support instead of quietly becoming permanent.
Should I choose a software maintenance retainer or hourly billing?
Use a retainer when support work is steady and recurring, such as monitoring, dependency updates, and a known backlog, because you get priority access and predictable cost. Use hourly when volume is low or sporadic, with a rate card and a monthly cap. Many teams combine both: a small baseline retainer for incidents and maintenance, plus hourly or fixed-bid pricing for enhancements.
Who fixes bugs after software launch?
Whoever you name in the support agreement, within a defined warranty boundary. New custom software usually includes a warranty period where defects are fixed at no extra cost because the behavior does not match the agreed specification. After that, defect fixes move into your support tier. Anything that changes or adds behavior is a change request, not a defect.
What SLAs should a post-launch support plan include?
At minimum, severity definitions based on business impact, a response-time target and a separate resolution target for each severity, your support hours and channels, and an escalation path for Severity 1 incidents. Keep the tiers small and specific so urgent means the same thing to everyone.
Can we change our support model later?
Yes, and you should. Review volumes, response times, and costs quarterly and re-tier when the pattern changes. A quiet period may mean you are over-paying for a retainer, while a busy one usually means your SLAs are too loose or your maintenance allocation is too small.
Cover: Photo by Tima Miroshnichenko on Pexels