Who Looks After Your Software After Launch?

Consider a hypothetical service business whose new customer portal has just launched. A payment provider changes an account requirement, and some transactions begin failing. The site still loads. The hosting dashboard remains green. Customers contact the business because they cannot finish paying.

Who investigates? The developer may consider the build complete. The hosting supplier may see no infrastructure fault. The office team may have no access to the payment account. Until somebody owns the full customer journey, each party can be performing its narrow role while the product fails.

This is the gap between delivering software and operating it. A release creates a working system at a point in time. Operation keeps that system effective as users, dependencies, data and business requirements change.

The application remains a live promise after the project has been marked complete. Before launch, the business needs an agreement about who will monitor that promise and how failures will be handled.

A handover should therefore include people, permissions, response arrangements and recovery information. Source code and administrator credentials are necessary assets, but they do not by themselves form an operating model.

Infrastructure, application code and third-party services need technical owners. The business also needs someone responsible for outcomes such as completing a purchase, receiving an enquiry or issuing a customer document. That person can bring the relevant technical owners together when the journey breaks.

Define how staff report a problem and how its urgency is assessed. A spelling error and a failure preventing every booking should enter different response paths. The team needs criteria that reflect commercial impact, affected users and available workarounds.

Set expectations for coverage honestly. If the business operates across time zones but technical support is available only during specified hours, the arrangement should be understood before an incident. Decide how urgent issues outside those hours are detected and addressed, or adjust the service promise accordingly.

Ownership should survive absence. Record a backup contact and ensure that essential access does not depend on a single employee's personal account. A small team may combine responsibilities, but each responsibility should still have a named home.

This clarity also makes supplier relationships easier to manage. When a failure spans several services, the business can coordinate the investigation rather than waiting for vendors to agree whose component is responsible.

A running server does not establish that a customer can complete a task. The application may be available while an integration, email route or permission rule prevents work from finishing.

Choose a few critical journeys and identify evidence that they are functioning. A booking request should reach the operational queue. A payment result should update the right order. A submitted form should be retrievable by the team expected to act on it. Monitoring should reflect those relationships.

Technical signals help explain failures, but alerts need an owner and a response. An inbox full of repeated warnings is easy to ignore. Review whether each alert identifies something actionable, how quickly it needs attention and what the recipient can do.

Keep customer reporting straightforward as well. Users may discover conditions that automated checks do not cover. Their reports should connect to a traceable case, with relevant context and an appropriate route for sensitive information.

DORA's delivery performance guidance treats recovery and instability alongside delivery throughput. For an operating business, that supports asking how the team learns from production problems as well as how quickly it releases new features.

Backups, version history and supplier availability each contribute to recovery, but none is a complete plan. The business should know what can be restored, how long restoration may take and which information could be missing afterwards.

AWS's Startup Resiliency Baseline distinguishes the provider's infrastructure responsibilities from the customer's application responsibilities. Choosing a cloud service does not transfer ownership of the whole recovery process.

Run a controlled recovery exercise appropriate to the application. Restore a representative backup into a safe environment, verify the data and check whether connected functions work. Document the steps that required specialist knowledge or access that was difficult to obtain.

Consider dependencies beyond hosting. An expired domain, inaccessible payment account or lost integration credential can interrupt service even when the application is intact. Keep ownership and renewal information current.

Recovery also has a business side. Staff need to know which work can continue manually, what should be paused and how customers will receive accurate updates. A temporary workaround should preserve enough information for later reconciliation.

The objective is a credible path back to service, with responsibilities and limitations understood before the pressure of a live incident.

Some of the most important product work is difficult to display in a launch announcement. Dependencies need updates. Access needs review. Supplier changes require adjustments. Performance and storage demands evolve. The operating budget must allow for this work.

Treat maintenance as a continuing obligation with priorities, rather than an undefined allowance that disappears when feature requests arrive. Separate urgent security or reliability work from improvements that can be scheduled. Retain room for the unexpected without giving every issue the same urgency.

Access management deserves a routine process. Remove access when roles change, review privileged accounts and keep credentials in appropriate systems. The FTC's security guidance for businesses includes access control and ongoing security maintenance among its recommendations.

Review external services as part of the product. Know what the business pays, which features it depends on and how a supplier change would affect operations. A low subscription price may conceal a costly dependency if records are difficult to export or the integration is poorly understood.

The owner should be able to distinguish the cost of keeping the current promise from the cost of making a new one. That distinction makes roadmap and budget conversations more honest.

Include an exit route in supplier planning. Confirm that the organisation can retrieve its records in a usable form, understand the application's configuration and transfer administration if the relationship ends. Test a representative export before it becomes urgent. This is ordinary continuity planning for a business asset, especially where one supplier built the system and also controls the accounts that run it.

Review these arrangements when contracts renew or the product takes on a more important role in daily operations.

A support queue contains evidence about how the product works in practice. Repeated requests for the same explanation may indicate confusing language. Repeated manual corrections may reveal weak validation. A feature that generates frequent support may have a different operating cost from the one estimated during development.

Group recurring issues by cause and impact. Link them to the relevant journey and decide whether the best response is a product change, clearer guidance, staff training or a revised policy. Closing each ticket individually can conceal a larger pattern.

Give support staff visibility into known issues and recent releases. They should know when a workaround is safe, when a problem has been resolved and what they can accurately tell customers. This requires a regular connection between delivery and operations.

A software development partnership and a cloud engineering plan should make these responsibilities explicit in their scope. Avoid assuming that development, hosting, support and incident response are interchangeable services.

Launch is a commercial milestone, but the operating arrangement determines whether the product remains dependable. The business should leave the project with more than functioning software: it should have the means to keep delivering the service that software represents.