Many SMEs spend months carefully negotiating the build phase of a custom software or web application project, only to treat post-launch support as a single throwaway line at the bottom of the quotation. Then, two months after launch, an external API changes or a staff member requests a new report column—and a dispute breaks out over whether the request is a “free bug fix” or a “billable change request”.
Once your software passes User Acceptance Testing (UAT) and data migration cutover, govern the post-launch lifecycle with these eight SLA, bug triage, and roadmap rules.
1. Distinguish the “Post-Launch Defect Warranty” from “New Feature Enhancements”
Why it matters: A defect (bug) is when the system fails to perform a function explicitly signed off in the agreed specification (e.g., an approved discount formula calculates incorrectly). An enhancement is when staff start using the live system and say, “Actually, could we also add a new export format for a third-party vendor?”
What to put in writing: Define a clear 30-to-90-day post-launch warranty covering reproducible specification defects at zero cost, while routing new workflow requests into a transparent Phase-2 backlog.
2. Four-tier Severity Matrix (`P1 Critical` to `P4 Minor`) with guaranteed response SLAs
Why it matters: A typo on an internal settings tooltip (`P4`) does not require waking an engineer at midnight, whereas a checkout or login outage (`P1`) requires immediate intervention.
What to put in writing: Agree on concrete acknowledgement and resolution target windows for each severity tier during Singapore business hours (and 24/7 for P1 production outages).
3. Automated uptime, error-rate (`Sentry`/logs) and database disk monitoring
Why it matters: Your engineering partner should never find out that your client portal or wholesale ordering portal is down because an angry customer called your receptionist.
What to put in writing: Require automated 1-minute uptime health checks, SSL expiry alerts, server disk-usage thresholds (alerting at 75% capacity), and application exception logging.
4. Scheduled OS, framework, security patch and third-party API maintenance
Why it matters: Even if you never add a single new feature to your software, external dependencies change: Stripe, Xero, WhatsApp Cloud API, and iOS/Android browsers deprecate old API versions every 12 to 18 months.
What to put in writing: Include regular dependency patching, security updates, and third-party API version compatibility inside your monthly maintenance retainer.
5. Automated daily encrypted database backups + quarterly restore drills
Why it matters: Automated backups that have never been tested for restoration can fail silently when a storage token expires.
What to put in writing: Enforce daily off-site encrypted database snapshots with a quarterly test restore into staging—mirroring our staging and rollback standards.
6. Named support intake channel (ticketing portal vs scattered WhatsApp chats)
Why it matters: Allowing 15 different staff members to message developers directly in a casual WhatsApp group results in lost bug reports, unapproved scope changes, and zero audit trail.
What to put in writing: Designate 1–2 internal Product Owners at your SME who submit and approve tickets through a structured support tracker, complete with screenshot/video reproduction steps.
7. Monthly “Enhancement Hours Bucket” for continuous Phase-2 improvements
Why it matters: Issuing a formal legal quotation and purchase order for every 3-hour report tweak slows down continuous improvement.
What to put in writing: Pair your baseline hosting/SLA retainer with an optional pre-agreed monthly engineering bucket (e.g., 8 to 20 hours/month) that your Product Owner can allocate to priority Phase-2 enhancements each month.
8. Living technical documentation, Git repository ownership and exit portability
Why it matters: Just as your marketing contracts must guarantee ad account ownership, your software agreement must ensure your company owns its source code, database schema, and deployment documentation upon full milestone payment (per our Terms & Conditions).
What to put in writing: Require updated README/architecture docs, environment variable templates, and Git repository access at every major release.
Custom Software Post-Launch SLA & Severity Triage Matrix
Include this severity table in your software maintenance Service Level Agreement:
| Severity Level | Operational Definition | Target Initial Response | Target Resolution / Workaround |
|---|---|---|---|
| P1 — Critical Outage | System down, login blocked, or core billing/order flow broken for all users | ≤ 30–60 minutes | Immediate hotfix / rollback within 2–4 hours |
| P2 — High Impact | Major module impaired (e.g., specific report or API sync failing) with no easy workaround | ≤ 2–4 business hours | Fix deployed within 1 business day |
| P3 — Medium / Standard Bug | Non-critical feature defect with an available operational workaround | ≤ 1 business day | Included in next weekly/bi-weekly release |
| P4 — Minor UI / Enhancement | Cosmetic alignment tweak or new Phase-2 feature request | ≤ 2 business days | Scheduled in monthly enhancement sprint |
Partner with a Singapore software engineering team built for the long term
At W Creates Digital, we do not just hand over code and disappear—we engineer and maintain mission-critical business software (including our own SumBook, PeopleBook, StockBook, and LeadPlus platforms) with clear SLAs, proactive monitoring, and structured Phase-2 roadmaps. Contact our Singapore team to discuss your software build or maintenance needs.