Product stewardship: the part where we don't disappear.

The month after launch is the easy one. Everything is fresh, everyone remembers how it works, and the people who built it are still reachable. The trouble starts later, and it's undramatic enough that nobody escalates it until it's expensive. Here are the five ways it usually arrives — and they're the five things product stewardship exists to catch before you do.

A dependency you've never heard of gets a security advisory. Custom software sits on dozens of open-source libraries maintained by other people. One publishes a vulnerability, and the fix is straightforward for about six weeks. After that it's a version jump, and version jumps break things.

Something underneath the software changes. A payment provider deprecates an endpoint, a browser tightens a rule, a platform updates. Your software didn't change, but the environment it operates within did. If nobody's watching, you find out when a user does.

Small shortcuts compound. Every build makes trade-offs under launch pressure that are meant to be revisited. Revisiting them is ordinary product stewardship work; left alone, they become the reason a two-day change takes two weeks.

A request sits for four months. Not because it's hard, but because you're finding someone who can read the codebase — and then paying them to read it before they touch anything.

Nobody remembers why. The data model looks odd because of a constraint someone solved in week nine. Two years on, that reasoning lives in nobody's head, and the next developer works around it or breaks something.

None of this is dramatic, which is exactly why it's expensive. There's no incident to escalate — just a system that gets gradually more costly to change until changing it stops feeling worth it. Product stewardship is the arrangement that keeps month eighteen from arriving.

Most firms won't publish what's inside a retainer, let alone how fast they'll respond when you report something. Here's what's inside all three product stewardship tiers, and what we commit to on response. You categorize each ticket High, Medium, or Low when you file it, we confirm on triage, and the times below are business-hours commitments rather than aspirations.

We publish response times and not resolution times, deliberately. How quickly we get to you is something we control, so we'll put a number on it and be held to it. How long a fix takes depends on what the fix turns out to be, and committing to a number we'd sometimes miss is worth less to you than a number we always make.

Most clients move between tiers, and that's the expected path rather than an upsell. The quarterly health report is worth calling out for one reason: it's the artifact you take to a board or a funder when someone asks what the money bought. "Nothing broke" is hard to defend without documentation and easy with it.

It's a real limit on who can buy product stewardship, and we'd rather lead with it than bury it in the fine print. If you have a system from another team and you need someone to take it over, we're not the right call, and we'll say so in the first email rather than after a discovery process.

The reason is the response commitment itself. Two business hours on a high-severity issue is only possible because nobody has to go read the code first. On a codebase we've never seen, that promise means one of two things: we pad the price to cover the unknown, or we quote the number and miss it. Neither is a good deal for you, and the second is how firms lose a client and a reputation in the same quarter.

If that's your situation, the honest suggestion is one of two things. Find the original team — they're worth more than they charge. Or, if the system genuinely can't be extended anymore, treat it as a rebuild rather than a rescue, which is the custom software development engagement that comes first.

Product stewardship is a monthly retainer set by tier, and the tier gets chosen with you rather than assigned — usually in one conversation, once we know what shipped and who's using it. Beyond tier, what drives the number is how complex the system is, how many integrations it has to keep working, and how much of it is customer-facing. The commitment is three months minimum. After that, it's month to month and continuing is your decision.

Three months isn't a lock-in tactic. It's roughly how long it takes for the monitoring and the update rhythm to be worth anything, and below that we'd mostly be charging you for setup. For budgeting: keeping custom software current typically runs 15–20% of build cost annually. That's a rule of thumb from doing this work rather than a published study, and it's the number worth putting in front of your board early — alongside the build figure, which gets set in the way described on our custom software development cost page.

Worth asking your funders about, too. Grants can cover a portion of this and sometimes all of it, particularly capacity-building and technology grants — and organizations rule the work out on cost far more often than they check whether the cost has to come from the operating budget. We'll help you document it for an application or a funder report.

The alternative isn't zero. It's emergency work on an unfamiliar codebase, which is the most expensive development money buys.