Expect the first 90 days after launch to be busier than the build. Weeks one and two bring bug fixes and confused users; weeks three to six are about adoption and retiring old workarounds; the final stretch is for measuring results and deciding what version two should include. Launch day is the start of the work, not the finish.
Why are the first 90 days so important?
Because this is when real users meet real data, and every assumption made during the build gets tested at once. Problems that never appeared in testing show up within days, and staff decide quickly whether the new system is a help or a hassle.
Habits formed in the first month tend to stick. If people learn to work around the system now, those side spreadsheets will still be running a year later. A planned 90-day period protects the investment you've just made.
What does the 90-day plan look like at a glance?
Think of it as three phases with different goals and different owners.
| Phase | Days | Main goal | Who leads | Signs it's going well |
|---|---|---|---|---|
| Hypercare | 1–14 | Fix urgent issues fast; keep the business running | Development team, with your project owner | Critical bugs fixed within agreed times; no data loss |
| Stabilise and adopt | 15–45 | Get everyone using the system; retire old tools | Your internal champion | Old spreadsheets and inboxes go quiet |
| Measure and plan | 46–90 | Compare results with the business case; prioritise version two | Business owner and product lead | A short, evidence-based list of next improvements |
What happens in the first two weeks?
The first fortnight is "hypercare": a period of heightened support where the development team watches the system closely and responds to problems quickly. Agree how this works before launch, not on the day.
What to expect:
- A spike of small issues. Mislabelled buttons, a report that sums the wrong column, an email template with a typo. These are normal and should be fixed in days.
- A few real bugs. Edge cases that testing didn't cover, often triggered by messy imported data or unusual customer behaviour.
- Lots of "how do I…?" questions. Many of these are training gaps rather than bugs, and they tell you where the interface needs to be clearer.
- Performance surprises. Real data volumes can slow pages that were quick on test data.
How to run it well:
- Use one channel for reporting issues, such as a shared form or tracker, not scattered WhatsApp messages.
- Classify every report: critical (business can't operate), major (painful workaround exists), minor (cosmetic).
- Hold a short daily check-in for the first week, then move to twice weekly.
- Keep the old system read-only, not deleted, so you can check historic data if something looks wrong.
Severity rules matter more than speed. A team fixing cosmetic issues while a payment bug waits is a sign the triage process needs attention.
What changes between days 15 and 45?
The focus moves from fixing to adopting. By now the urgent issues should be under control, and the real risk becomes people quietly drifting back to old habits.
Practical steps:
- Switch off the old way. Set a date after which the old spreadsheet or tool is no longer updated. Parallel running beyond a few weeks breeds confusion about which version is true.
- Appoint an internal champion. One person who knows the system well, collects feedback and helps colleagues. This role matters more than any training session.
- Run short, task-based training. "How to create a quote" beats a two-hour tour of every screen.
- Watch for workarounds. If someone keeps an extra spreadsheet, ask why. It usually points to a missing field, report or permission.
- Collect feedback in one backlog, ranked by how often the issue comes up and what it costs.
Our guide to getting your team to actually adopt new software goes deeper on the people side, which is where most launches succeed or stall.
What should happen between days 46 and 90?
This phase is about evidence. Compare what the system is doing with the goals you set before the build, then decide what to improve next.
Go back to your original business case and check each assumption:
| What to measure | How to measure it | What it tells you |
|---|---|---|
| Time saved on key processes | Repeat the before-launch time audit for the same tasks | Whether the efficiency case holds up |
| Error rate | Count corrections, refunds or rework compared with before | Whether quality has improved |
| Adoption | Active users per week; share of work done in the system | Whether people rely on it or work around it |
| Speed of response to customers | Time from enquiry or request to first reply | Whether customers feel the difference |
| Support load | Number and type of issues reported per week | Whether the system is settling down |
| Running costs | Hosting, third-party services, support hours | Whether costs match the budget |
Our article on how to measure the ROI of a custom software project explains how to turn those measurements into a return figure.
By day 90 you should be able to write a one-page summary: what worked, what didn't, and the three to five changes that would add the most value. That page becomes the brief for version two.
What surprises come up after launch?
Even well-tested software has things that only surface in production. Knowing the common ones keeps them from feeling like a crisis.
- Data quality problems. Imported records with duplicates, missing fields or inconsistent formats. Clean-up often takes longer than expected.
- Integration hiccups. A connected tool changes its behaviour, rate-limits requests or sends data in a slightly different format.
- Security findings. Real-world traffic exposes weaknesses that design reviews missed. On GRWW's own systems, for example, we found and fixed a login rate-limit bypass caused by trusting a spoofable IP header, and removed
unsafe-evalfrom the site's Content Security Policy. Neither was dramatic, but both are the kind of issue a post-launch review should catch. - Performance tuning. Pages and reports that need optimising once data grows. On our own website we load analytics after the page so it doesn't slow the first paint, a small change of the kind that comes from watching real usage.
- Scope creep disguised as bugs. "It should also do X" is a feature request, not a defect. Keep the two lists separate.
What should you budget for after launch?
Budget for ongoing maintenance from day one. GRWW's rule of thumb, consistent with typical market ranges, is roughly 15–25% of the build cost per year for maintenance, security updates, hosting management and small improvements.
That figure typically covers:
- Bug fixes beyond any warranty or defect-fix period in your contract.
- Security patches and dependency updates.
- Monitoring, backups and hosting management.
- Small enhancements and adjustments from user feedback.
Version two features are usually quoted separately; our services page shows how build and support fit together. Check now what your contract says about defect fixes after launch and how long that cover lasts, because terms differ between suppliers. Our guide to budgeting for software maintenance and support after launch breaks the numbers down further.
The full lifecycle, from discovery through build to launch, is covered in our complete guide to custom software development.
Frequently asked questions
How many bugs are normal after launching custom software?
There's no fixed number, but a burst of small issues in the first two weeks is normal for any new system. What matters is the trend: the number and severity of reports should fall steadily. If critical issues are still appearing after a month, ask for a root-cause review.
Should we run the old and new systems in parallel?
Briefly, yes, ideally for a few weeks at most. Parallel running gives you a safety net, but stretched too long it doubles the workload and creates arguments over which data is correct. Set a firm cut-over date and keep the old system read-only afterwards.
When should we start planning version two?
Start collecting ideas from day one, but don't commit to new features until around days 60 to 90. By then you'll have usage data showing what people actually need, rather than what seemed important during the build.
What if staff refuse to use the new system?
Find out why before pushing harder. Resistance usually points to a real gap: a missing feature, a slower process or poor training. Fix the gap, involve the most sceptical users in testing the fix, and set a clear date when the old method stops.
Who should own the software internally after launch?
Name a product owner inside your business, even if part-time. They prioritise feedback, approve changes and are the main contact for your development partner. Without one, requests arrive from everyone and nothing gets prioritised.
Planning a launch?
If your software is about to go live, or already has and the first weeks feel chaotic, a structured 90-day plan makes a big difference. Talk to us about launch support and ongoing maintenance.