for a while my approach to scope creep was pretty binary: milestone approved = locked, anything after = billable. that killed most of the "i never said it was final" arguments.
but it created a new problem. treating every tiny request the same way as a big one started annoying clients. a client asking to change a button color got the same "that's a change request" response as someone asking to rework the auth flow, and that felt disproportionate, even to me.
talked this through with someone in the comments on my last post, and they framed it in a way that stuck with me: the threshold isn't size or hours, it's blast radius.
a two minute database change can carry more risk than a two hour UI tweak. cosmetic stuff (copy, colors, spacing) can just get logged and batched. anything touching data models, auth, integrations, or something already inside an approved milestone needs an actual impact pass, regardless of how small it looks on the surface.
they also mentioned keeping a small "change budget" for minor stuff, once that's used up, the next request automatically becomes a formal change order instead of a favor.
i haven't fully implemented this yet, still mostly running on the old binary version, but it's making me rethink where i draw the line.
how do you all decide what's worth the formal process and what isn't? going by hours, going by what the change touches, or something else entirely?
Top comments (0)