sk around and the same story comes up: a studio delivers, gets paid, and the person who understood the codebase is suddenly two weeks behind on emails, then a month, then gone onto the next client entirely. Nothing about the contract was violated — "launch" was the deliverable, and launch happened. It's just that the moment a product actually meets real users is exactly when you need the people who built it the most, and that's precisely when a lot of studios stop being reachable.
Shippingwasnevertheexitforus.It'sclosertothepointwheretheactualfeedbackloopstarts.
That's not a support tier we upsell after the fact — it's the same relationship that built the thing, continuing. When something breaks under real traffic three weeks in, you're not opening a ticket into a queue and hoping it lands on someone who remembers this codebase. You're messaging the person who wrote the code that broke.
We could leave this implicit and let it show up in how we actually behave after a launch. We're saying it explicitly instead, because it's genuinely one of the differences between studios that's hard to evaluate before you've hired one — everyone's pitch deck says "ongoing support," and the only way to find out what that means is to already be a client when something goes wrong. Naming it specifically, with a timeline, is at least something you can hold us to before you've signed anything.
Support is easier to trust when the boundaries are written before launch. A defect in an agreed feature is different from a new feature request; an emergency response is different from routine maintenance. The contract should define those categories, the warranty period, response targets, supported hours, communication route, and what happens when work falls outside the included allowance.
- Launch monitoring for errors, failed forms, payment problems, analytics, and unexpected performance changes.
- A defect warranty tied to the agreed acceptance criteria rather than a vague promise to fix bugs.
- Security and dependency updates with a process for testing and deploying them safely.
- Backups and a recovery procedure appropriate to the value and sensitivity of the data.
- A clear route for enhancements, content changes, and urgent incidents after the warranty ends.
Ownership is the safety net beneath support. The client should control the repository, domain, hosting, analytics, data, and important third-party accounts even when the studio manages them day to day. If the relationship ends, another competent team should be able to take over without negotiating for access to the client’s own product.
- How long is the defect warranty, and what exactly counts as a defect?
- Who monitors the product after release and who receives alerts?
- What response is promised for a production outage compared with a normal request?
- Which maintenance tasks are included, optional, or the client’s responsibility?
- What documentation and account access will exist if another supplier takes over?