The Post-Launch Playbook: Keeping Custom Software Healthy

The Launch Day Myths

Launch day is surrounded by myths that make the post-launch period harder than it needs to be. The most damaging: that launch is an ending. Launch day is not the end of the project — it is the first day of a different kind of work. Before launch, the primary activity is building. After launch, the primary activity is understanding how real users interact with what was built, and responding to what that interaction reveals.

The second myth is that a successful launch means the hard work is over. In reality, usability research consistently shows that the most valuable insights about a product come from observing actual use, not from testing during development. The first month after launch generates more actionable learning than the entire development period — but only if your team is watching.

The First 30 Days: What to Monitor

The metrics that matter in the first 30 days are different from the metrics that matter at month twelve. In the first 30 days, the priority is:

• Error rate by endpoint or user flow. Where are users hitting errors? Which operations are failing more than expected? Errors in the first 30 days often reveal edge cases that testing did not surface.
• User journey completion rate. What percentage of users who start a key flow complete it? Drop-off points are the fastest way to find friction that was invisible during development.
• Support requests by category. What are users asking for help with? The first month of support requests is a prioritised list of things that are confusing or broken.
• Performance under real load. Development environments almost never replicate production load accurately. The first 30 days often reveal performance issues that only materialise at scale.

The Feedback Loop You Cannot Skip

The fastest way to make good post-launch decisions is a weekly ritual: review the previous week's errors, support requests, and usage data as a team, and produce one to three prioritised actions for the following week. This sounds simple. Most teams skip it because they are busy shipping the next feature. The teams that maintain this ritual consistently outperform the ones that do not — because they are responding to evidence rather than assumption.

Feedback loops require feedback channels. If your users cannot easily report problems or suggestions, they will not — they will simply stop using the product. In-app feedback mechanisms, monitored support channels, and periodic user interviews are all worth the investment in the first year of a product's life. The same discipline that makes Discovery Sessions valuable applies here: structured inquiry produces better results than informal impression-gathering.

Scheduled Maintenance vs. Reactive Fixes

Most software maintenance is reactive: something breaks, you fix it. This is inevitable and appropriate for genuine emergencies. But reactive-only maintenance is expensive — the cost per issue is higher because the work is unplanned, the urgency is higher, and the fix is more likely to introduce new problems because it was done under pressure.

Scheduled maintenance — allocating regular time for dependency updates, security patches, performance optimisation, and technical debt reduction — is less urgent but more economical. We recommend a cadence of roughly 20% of engineering capacity allocated to scheduled maintenance in the first year after launch. This is the number most clients resist until they have experienced a preventable outage caused by an outdated dependency.

When to Add Features vs. When to Stabilise

The tension between adding features and stabilising the existing product is real, and there is no formula that resolves it in every case. The signal to prioritise stability is: when your error rate is climbing, when your performance is degrading under load, or when your team is spending more than 30% of their time on reactive fixes. At that point, shipping new features on an unstable foundation is not acceleration — it is compounding risk.

Handing Off to an Internal Team

If the plan includes transitioning maintenance from an external development partner to an internal team, that transition requires explicit planning — not an assumption that documentation alone is sufficient. The internal team needs time working alongside the original developers, not just access to the codebase and the docs. When we plan handoffs for Exclolab clients, we typically include a minimum six-week overlap period before full ownership transfers.