How We Handle Post-Launch Support: The SLA and Process Behind the Software

Every software project ends at go-live. The software relationship — if the project was built well and if the client relationship is healthy — continues for years afterward. How that continuation is structured determines whether clients have confidence in their software investment or live with the anxiety that the next critical failure will leave them without support.

This article describes our post-launch support framework: how we classify incidents, what our response commitments are at each severity level, how we handle the boundary between support and new development, and what the long-term client relationship looks like at Ekfix.

The Gap Between Go-Live and Stability

Production environments reveal things that development and staging environments do not. Real user behaviour under real load against real data produces scenarios that no test suite fully anticipates. This is not a failure of development practice — it is an empirical reality of complex systems.

Most production issues emerge in the first 30–90 days after go-live: edge cases that were not in the test data, integration behaviours that only manifest at production transaction volumes, performance characteristics that are different under real user patterns than under synthetic load. After 90 days, a well-built system typically reaches a stability baseline, and incidents become infrequent.

This post-launch period requires active support engagement. A development firm that delivers code and withdraws on go-live date leaves the client in the highest-risk window without a knowledgeable partner. Our engagement structure explicitly provides for intensive support in this period.

Support Tiers and SLA

We define four severity levels for production incidents:

Severity 1 (Critical): The system is unavailable or a core business workflow is completely broken, with direct financial or operational impact. A payment processing failure, an inability for users to log in, a data calculation error producing incorrect financial reports.

Response time: 1 hour (initial contact and acknowledgement)
Resolution target: 4 hours (workaround or fix deployed)
Escalation: Named senior engineer assigned immediately; client CEO/CTO contacted
Coverage: 24/7 for Severity 1

Severity 2 (High): Significant functionality is impaired and there is no workaround, or a workaround exists but is significantly burdensome. Multiple users affected.

Response time: 4 hours (business hours); 2 hours if flagged as needing out-of-hours attention
Resolution target: 1 business day
Coverage: Business hours + on-call for declared high-urgency

Severity 3 (Medium): Non-critical functionality is impaired; workaround available; limited user impact.

Response time: 1 business day
Resolution target: 3–5 business days
Coverage: Business hours

Severity 4 (Low): Minor issues, cosmetic defects, usability improvements, questions about functionality.

Response time: 2 business days
Resolution target: Next maintenance cycle or scheduled release
Coverage: Business hours

What SLA Response Time Means

Response time is acknowledgement: an engineer is assigned and investigation is in progress. It is not resolution. Resolution targets are our goals, not absolute guarantees for complex issues — some problems require investigation time that cannot be compressed without creating new problems. What we commit to unambiguously is transparency: if a resolution will take longer than estimated, we tell you before the estimate expires, not after.

The Support vs. New Development Boundary

This is the most common source of friction in post-launch client relationships, and it deserves clear upfront treatment.

Support covers:

Defects: The system behaves differently from its specified behaviour (bugs)
Performance problems related to the delivered system
Security patches for vulnerabilities in components we delivered
Infrastructure maintenance within the agreed hosting scope
Clarifications and guidance on using delivered functionality

Support does not cover:

New features or functionality not in the original scope
Changes to existing functionality beyond defect correction
New integrations
Capacity upgrades driven by usage growth beyond designed parameters
Third-party platform changes that require application updates (these are handled as change requests, typically at reduced rate)

New development is handled through a separate development retainer or as individual change requests, priced per the standard development rate rather than included in the support agreement.

The boundary is intentional. Support should be unlimited within its scope — if a bug exists, we fix it, period. Treating feature requests as support items would make pricing a support agreement impossible. Treating bugs as development items would create adversarial dynamics around classification and would leave clients uncertain whether bugs will be fixed.

The Post-Launch 30-Day Intensive Period

For all delivered systems, we include a 30-day post-launch intensive support period where:

Response times are reduced by 50% (Severity 1: 30-minute response)
Daily check-ins for the first week
Performance and error log monitoring shared with the client weekly
Bug fixes deployed within 24 hours rather than waiting for a release cycle
An engineer familiar with the system's implementation maintains continuous accessibility rather than standard rotation

This period is explicitly included in project scope and pricing. It is the period where the production environment stabilises and where client team confidence in the system is established or not. Running it well is one of the things that differentiates whether a client becomes a long-term partner.

Proactive Maintenance

Good post-launch support is not only reactive. Proactive maintenance prevents the incidents that reactive support resolves:

Dependency updates: Libraries, frameworks, and runtime environments receive security updates and deprecation notices continuously. We maintain a dependency update schedule — security-critical updates are applied immediately; minor version updates are batched monthly; major version migrations are planned as discrete projects.

Infrastructure reviews: Quarterly review of hosting infrastructure: cost optimisation as usage patterns change, capacity planning ahead of anticipated growth events (major marketing campaigns, new client onboarding), review of infrastructure for deprecated services.

Performance monitoring reviews: Monthly review of application performance metrics — request latency trends, database query performance, error rate trends — identifying degradation before it reaches user-impacting levels.

Security scanning: Automated dependency vulnerability scanning in CI, and periodic manual security review for new attack surface introduced by application changes.

Handover: If the Relationship Ends

Some client relationships conclude — the business changes direction, they build an internal team, they take the system in a different direction. We support this:

Complete documentation: The system should have documentation that enables a competent developer who has never seen it to understand its architecture, configuration, deployment process, and maintenance procedures. We produce this documentation as part of the post-launch engagement and keep it current.

Code ownership: Client-funded work belongs to the client. If the relationship ends, the full codebase, deployment configurations, and credentials are transferred on request.

Transition support: We provide a paid transition support period where we assist an incoming team or internal developers in familiarising themselves with the system. Typically 2–4 weeks of overlapping engagement.

No lock-in: We do not implement proprietary infrastructure dependencies, use closed technology stacks, or structure systems to make them difficult to maintain without us. This is not altruism — it is the position that earns client trust. A client who knows they can leave if the relationship is not working is more confident staying.

What Long-Term Relationships Look Like

The clients with whom we have the most productive long-term relationships are the ones where the post-launch support relationship transitioned over 12–18 months into an ongoing product development partnership.

The pattern: initial project delivers the core system. Post-launch support stabilises it. Over the following year, the client identifies enhancements, new features, and integrations that the business needs. A development retainer replaces the support-heavy early engagement, and we become the technical partner for the system's ongoing evolution — building new features, managing infrastructure evolution, and providing technical strategy input as the business grows.

This is the most valuable relationship structure for both sides. The client benefits from a team that already knows their system deeply and can build new capabilities faster and with less onboarding overhead than a new vendor. We benefit from the stability of a long-term relationship and the opportunity to build increasingly sophisticated systems as the client's business grows.

The foundation of that long-term relationship is established in the first 90 days after go-live. Getting post-launch support right is not a delivery detail — it is the opening chapter of what we hope becomes a long book.

Deployment Pipelines: Ship Software with Confidence — Automated release processes
Uptime SLAs: What Hosting Providers Promise vs Deliver — Understanding infrastructure reliability
Staff Augmentation vs Full Project Outsourcing — Engagement models for ongoing support