We think about launch as the start of a different phase of a project, not the end of it. Here's how we actually structure the support period that follows, and why we build it into project scoping rather than treating it as an afterthought.
A defined handover, not a vague promise
At launch, you get full source code and hosting access — no vendor lock-in, regardless of whether you continue with us for ongoing support. What "ongoing support" specifically includes (response times, what's covered, what counts as a new feature request vs a fix) is agreed upfront, not left ambiguous.
Monitoring, not just waiting for a complaint
For sites and apps under an active support plan, we monitor for uptime and security issues rather than waiting for a client to notice something's broken and report it. Catching an issue before it becomes visible to your customers is the actual point of a maintenance plan.
Bug fixes vs new features: a clear line
Something not working as originally specified is a bug, and gets fixed under support. Something new that wasn't part of the original scope is a feature request, and gets its own conversation about time and cost. Being clear about this distinction upfront avoids disagreements about what should be "free" later.
Why we think this matters more than the initial build
A website or app that isn't maintained degrades — security patches lapse, dependencies become outdated, and eventually something breaks in a way that's harder to fix than if it had been caught early. The initial build gets a project live; ongoing support is what keeps it actually working.