We estimate build time on every ticket, and always have. What we started doing this month is estimating a second number alongside it: a rough, honest guess at the ongoing support cost the feature will create once it exists — support tickets it will generate, alerts it will fire, questions it will prompt from other engineers reading the code later.
Why build time alone was misleading
A feature that takes two days to build and then generates a support ticket every fortnight for two years is, on any honest accounting, a much bigger commitment than a feature that takes two weeks to build and then runs unattended. Nothing about our estimation process had ever surfaced that difference, because we only ever estimated the first number.
What the second estimate looks like
Not a precise figure — a rough banding, decided in the same conversation as the build estimate: negligible, occasional, or ongoing. Occasional means we expect it to need attention a few times a year. Ongoing means it needs a named owner, because it will need decisions made about it regularly, not just bugs fixed.
What it changed in practice
- A few "quick win" tickets got reprioritised down, once it became clear the twenty-minute build carried an ongoing support tag — usually because it touched a fragile third-party integration or introduced a new configuration surface.
- A couple of larger tickets got reprioritised up, because although the build was substantial, the support estimate was negligible: once built and tested, the feature would essentially run itself.
- "Ongoing" features now get named owners at build time, not whenever the first support ticket lands and someone has to be found in a hurry.
The two-day feature and the two-week feature are not the fast option and the slow option. They're two different shapes of long-term commitment, and only one of the two numbers involved shows up if you only measure build time.
The conversation this enabled
Clients respond well to this, more than we expected. Framing a request as "quick to build, but here's what it will cost you in attention every month" gives them a real decision to make, rather than a request that gets built because it looked cheap on the only number anyone showed them.
What we are still working out
How to make the support estimate more than an educated guess. Right now it comes from experience with similar features on similar projects, which is reasonably reliable but not something we can point to a number for yet. We are starting to track actual support load against the original estimate, project by project, and expect to have something more rigorous to report by the middle of the year.