How We Decide What Goes Into a Post-Launch Support Plan

A project launching is a milestone, not an ending - nearly everything we build needs some form of ongoing support afterward. What varies significantly is what "support" actually means for a given project, and getting that scope wrong in either direction causes real problems: too little, and small issues turn into client frustration; too much bundled in by default, and pricing becomes unsustainable for work that wasn't actually needed.

What's Included by Default, No Exceptions

Every project we ship includes a baseline support period covering bug fixes for issues that existed at launch but weren't caught before it, critical security patches, and basic monitoring to catch outages or major failures. This isn't negotiable or scoped separately, because it reflects our own responsibility for what we built - a client shouldn't have to separately purchase a fix for something that was our error to begin with.

What Gets Scoped as a Separate Conversation

New feature development, even small additions, gets scoped and estimated separately rather than folded into general support - otherwise "support" quietly becomes an open-ended development contract with no clear boundary. Performance optimization beyond what was originally specified, changes driven by evolving business requirements rather than defects, and third-party integration changes triggered by an external provider's own updates all fall into this category too, since they're new work rather than upkeep on what was already agreed and built.

How We Decide the Line, Project by Project

The deciding question we ask isn't "is this urgent" - it's "is this fixing something that doesn't match what was built, or is this changing what was built." A bug is the system not doing what it was supposed to do. A feature request is the system doing exactly what it was supposed to do, and the client wanting it to do something different or additional now. That distinction, more than urgency or size, determines which side of the support boundary something falls on.

Why We Set This Explicitly, Not Implicitly

Vague support arrangements - "we'll take care of you after launch" without specifics - tend to create real friction later, because the client's assumption and our actual scope drift apart over time, usually without either side noticing until a disagreement surfaces. We put support scope in writing at project completion, specific enough that both sides can point to it later without relitigating what "included" was ever supposed to mean.

What Changes as a Relationship Matures

For clients we've worked with over multiple projects, support conversations get easier, not because the boundary itself changes, but because there's enough shared context and trust that scoping a new request takes less back-and-forth. The underlying distinction - fixing versus changing - stays the same. What improves is how quickly we can apply it together.

Why This Approach Serves the Client, Not Just Us

A support model with no boundaries eventually has to be priced defensively, because unlimited scope creep under the label of "support" isn't sustainable for anyone providing it. A clearly scoped model lets us price baseline support fairly, because it's actually bounded, and lets clients budget accurately for the ongoing evolution of their product as separate, plannable work - rather than an unpredictable cost that shows up disguised as routine maintenance.