Before You Sunset a Product, Price the Upkeep It Carries Whether or Not Anyone Uses It

A product nobody opened last month still sent a bill. Not the hosting invoice, which does scale with demand and at low demand rounds to almost nothing. The bill is a set of obligations that arrive on a calendar you do not control. A dependency picks up a published advisory. A certificate approaches expiry. A browser release changes how a layout resolves. A platform deprecates the API you built against and gives you a window. None of those events consult your usage graph before they happen.

The distinction worth holding onto is between cost that tracks demand and cost that tracks existence. Variable cost follows the audience, rises when the audience rises and falls when it falls. Fixed upkeep follows the artefact. The moment something is shipped and reachable it acquires a standing obligation set, and that set is close to identical for a thing with a large audience and a thing with almost none. Both need patching. Both need the certificate renewed. Both need somebody to read the message when a user writes in. The difference in usage changes the consequence of neglect, not the amount of work required to avoid it.

The bill for a shipped thing arrives on the calendar, not on the usage graph.

This is what the software maintenance burden actually consists of, and it is routinely mistaken for something else. People price maintenance as the cost of continuing to improve a thing: the next feature, the next refinement, the queue of requests. That is discretionary. You can stop improving a product on any Monday and nothing breaks. What you cannot stop is the floor underneath, the work required simply for the thing to keep existing in a functioning, honest, legally sound state. Discretionary work can be paused. The floor cannot, and the floor is what determines how many things one company can carry.

The honest counter is that fixed upkeep is not equal across artefacts either. A static page with no dependencies, no accounts and no inbound mail is far cheaper to hold than a multi-tenant application that stores customer data. That is true, and it is the useful version of the argument rather than a refutation of it. The claim is not that every shipped thing costs the same. The claim is that for any given thing, the cost of holding it steady is set by its construction and its promises, not by how many people used it this month. Reducing usage to zero does not reduce upkeep to zero. It only removes the audience who would have told you something was broken.

Which is the second-order effect, and the more dangerous one. A low-usage product is not merely as expensive to maintain as a busy one; it is harder to maintain well, because the feedback loop that normally reports failures has gone quiet. Nobody writes in to say the sign-in page has been erroring for three weeks. You find out when you look, and looking is itself part of the standing cost.

What follows is the inventory in full, stated at the level of the artefact rather than the person. It is deliberately written per shipped thing, because that is the unit that accrues the obligation. Each item below is owed by anything you have published, regardless of how it is staffed, and each one recurs.

Dependencies, patches and uptime

Every dependency you take is a subscription to somebody else's release schedule. Advisories appear when they appear. A patch that is trivial to apply in the month it lands becomes a migration when you skip four minor versions and the sixth one removes an interface you use. The cost of staying current is small and continuous; the cost of catching up is large and lumpy, and the second is what people mean when they say a codebase became unmaintainable. It rarely became anything. It simply stopped being maintained while the world around it kept moving.

Runtime obligations sit alongside. Certificates renew on a fixed cycle, and automated renewal is itself a mechanism that can silently fail. Language runtimes reach end of support and stop receiving security fixes. Hosting platforms change defaults, retire regions and alter build images. Domain registrations lapse if the payment method on file expires, and a lapsed domain for a live product is a category of failure that no amount of good engineering elsewhere compensates for. Uptime is not a thing you have. It is a thing you keep having, and keeping it requires that somebody would notice its absence.

• Dependency advisories and version drift, on the upstream schedule rather than yours.
• Runtime and language end-of-support dates, which are published years ahead and still arrive as surprises.
• Certificates, domains and payment methods, each with its own expiry and its own silent-failure mode.
• Platform deprecations, where the window to act is set by the platform and is not negotiable.
• Backups that exist, and restores that have actually been attempted, which are two separate obligations.

An inbox somebody has to answer

Publishing an address is a promise to read it. This is the least technical item on the list and the one most often left out of the estimate, because it appears in no repository. A shipped product attracts messages: a question that is really a support request, a bug report with no reproduction steps, a security researcher who has found something and wants an acknowledgement, a request to delete an account, a supplier query, an invoice dispute, and a steady sediment of unsolicited sales mail that has to be sorted through to find the three items that matter.

The cost is not the reply. The cost is the triage that must happen before you know whether a reply is needed, and triage is uncompressible: somebody reads everything, or the promise is not being kept. Automated deflection changes the shape of this cost but not its floor, because the messages that survive deflection are by definition the ones that need judgement. A product with almost no users still receives mail, and the mail it receives skews towards exactly the categories you cannot ignore, because the casual questions are the ones that stop arriving first.

There is a legal edge to this. If a product collects personal data, requests about that data arrive through whatever channel is published, and they carry response expectations that are not set by you. An inbox attached to a live product is therefore not a courtesy. It is part of the operating surface, and it is owed in the months when nothing else about the product is happening.

Documentation that stays true is a recurring cost

Documentation is written once and wrong continuously. The moment a screen changes, a field is renamed or a flow gains a step, every page describing the old behaviour is making a false statement to the reader, and false statements in documentation are worse than absent ones because they are trusted. The cost of maintaining a feature includes the cost of the paragraphs that describe it, and that cost recurs on every change rather than on every release.

The trap is that documentation decay is invisible from inside. Nobody who already knows how the product works reads the page explaining how the product works, so the drift accumulates unobserved until a new reader hits it. The mitigation is unglamorous: treat the documentation change as part of the change rather than as a follow-up ticket, and accept that this makes every change slightly more expensive rather than pretending it is free. A shipped thing with documentation is a shipped thing with a second artefact attached, and the second artefact carries its own dependencies, its own publishing route and its own accessibility surface.

Where content is version-controlled the drift at least becomes legible: a change to a page is a commit, a review is a diff, and the question of whether the documentation moved with the product has an answer you can look up rather than guess at. That is a property of the approach rather than a claim about any particular tool. Zealsync develops Acrosite, a git-backed content publishing product, so this is a question the company has a view on; the argument stands independently of it.

A name defended, a mark maintained and a site kept current

A shipped thing usually has a name, and a name is an asset with its own upkeep. Registrations renew. Where a mark is registered, the registration is jurisdictional, has a renewal date, and can be weakened by non-use. Confusable names appear over time and somebody has to be watching for them, because the practical value of a name is the ability to say this one is ours and mean something by it. None of this is engineering work and all of it is standing obligation.

Then there is the site the name points at. Every product with a public page inherits the full obligation set of a website: accurate copy, working links, a contact route, terms and a privacy notice that reflect what the product actually does rather than what it did at launch. Legal pages are the sharpest case, because they are the one part of the surface where being out of date is not merely untidy. If the privacy notice describes data handling that no longer matches reality, the page is wrong in a way that matters, and it has been wrong since the day the behaviour changed rather than since the day somebody noticed.

Accessibility is usually budgeted as a project. It is not one. WCAG 2.2 is a set of testable success criteria, and conformance is a property of a page in its current state rather than a certificate earned once. Every subsequent change is capable of breaking it, and the ways it breaks are ordinary rather than exotic: a new colour pairing that fails contrast, a control added without an accessible name, a dialog that traps focus, a form error surfaced by colour alone, a hover-only affordance with no keyboard equivalent, a target that shrinks below the minimum size at the narrow breakpoint.

Because the criteria are testable, the obligation is at least legible. You can enumerate what has to hold and check it. But checking is the recurring part. A page that conformed at launch and has had eleven changes since has either been re-tested against those criteria eleven times or has an unknown conformance state, and an unknown state is functionally a failed one for anyone relying on it. WCAG 2.2 also added criteria that catch regressions introduced by common interaction patterns, which is a reminder that the standard itself moves, and that a page conforming to an earlier version is not automatically conforming to the current one.

The cost therefore has two components. The first is the per-change check, which is small where the design system already encodes the requirements and large where every screen is bespoke. The second is the periodic re-baseline against the current version of the standard, which recurs on the standard's schedule rather than yours. Multiply both by the number of distinct interfaces you maintain and the reason a portfolio becomes expensive turns into arithmetic rather than opinion.

It is worth being precise about what this obligation is not. It is not a promise that every page is perfect, which no honest party can make. It is a commitment to a known state: you know which criteria you meet, you know where you fall short, and the gap is recorded rather than discovered by the person it excludes. Holding that known state across several products is the part that consumes capacity, and it is one of the first things to lapse quietly when capacity runs short.

Every product is a model: a set of nouns, a set of rules about how they relate, a vocabulary, a set of edge cases, and a set of decisions made for reasons that are no longer written down anywhere. Carrying a product means being able to reconstruct that model on demand, because you cannot answer a support question, evaluate a change or judge a risk without it.

This is the cost of maintaining multiple products that never appears in a budget line, and it does not divide neatly. Two products are not twice as much model as one, because the models interfere with each other. The same word means slightly different things in each. A pattern that is correct in one is wrong in the other. The expense is in the switching: the reload of context before any judgement can be made, and the errors that occur when the reload is incomplete and a rule from the wrong model is applied confidently.

Two models are not twice one model. The expensive part is the switch, and the switch is invisible until a confident answer turns out to be about the wrong product.

The tell is a specific kind of hesitation. Somebody is asked a direct question about behaviour and cannot answer without going to look, not because the answer is obscure but because they are no longer sure which product they are thinking of. When that hesitation becomes routine rather than occasional, the portfolio has exceeded the model capacity available to it, and the failure mode is not slowness. It is misplaced confidence, which produces answers that are wrong in ways nobody catches, because they were delivered without doubt.

The counter-argument is that documentation and shared conventions absorb this, and to a real degree they do. A model that is written down can be reloaded rather than remembered. But the writing down is itself upkeep, subject to the same decay described above, and the reload is never free. What good documentation buys is a lower cost per switch, not the elimination of the switch. If the case against this section is that the problem is solvable by writing more things down, the reply is that writing things down is one of the standing costs being counted, not an escape from the count.

The inventory above is the same list at any scale. What changes is the weight of each item, and the weight is what should inform the decision about what something ought to be in the first place. That decision belongs to a separate argument, laid out in product, service or feature. What follows is the standing cost each verdict commits you to, which is the part that decision hands over.

A feature carried inside something you already ship

A feature inherits its host's obligations rather than creating new ones. It shares the dependency tree, the deployment route, the certificate, the domain, the inbox and the legal pages. Nothing new expires. The marginal upkeep is genuinely marginal: some documentation, some accessibility surface, some additional model complexity, and a permanent widening of the regression surface, because every future change to the host must now also be safe for this.

That last item is where the real cost hides. A feature does not add a maintenance line. It adds a condition to every existing line. If the feature is switched on for some users and not others, every change is now evaluated against both states, and the number of states compounds with each conditional feature added. The cheapest possible upkeep is therefore not zero, and it grows in a way that is hard to see precisely because it never appears as its own entry anywhere.

A standalone product

A standalone product takes the full list at full weight, and takes it permanently from the day it is reachable. Its own dependency tree, its own runtime, its own certificate, its own domain, its own release cadence, its own documentation set, its own accessibility conformance, its own terms and privacy notice, its own inbox, its own name. Nothing is inherited. Every item is duplicated rather than shared unless it is deliberately shared, and deliberate sharing is itself a design decision with a cost attached.

This is the step change people underestimate, because the incremental engineering effort of pulling something out into its own product often looks modest, and it frequently is modest. The engineering is a one-off. The obligation set is annual, and it is owed in a year when the product earns nothing and in a year when nobody has time for it. Judging a separation decision on build effort alone systematically underprices it.

A brand

A brand adds a further layer on top of whichever of the above it names. It carries a position that has to stay coherent, a visual system that has to stay applied, a voice that has to stay consistent across every surface anyone encounters, and a name with its own registration and defence obligations. Whether that layer is worth taking on is argued separately in brand architecture for a small company. The point here is only that saying yes to it commits you to maintaining a system rather than to producing an asset.

The structural question underneath is whether the brand is a separate legal entity or a name belonging to an existing one, because that determines how much of the list duplicates. Intense Path is a brand of Zealsync Private Limited rather than a subsidiary or a separate company, and that fact is what keeps the registration, filing and legal-page line short rather than doubled. A brand constituted as its own entity takes on a second set of statutory obligations that have nothing to do with software, run on a government calendar, and do not pause when the brand is quiet.

Three obligations deserve separating out, because they behave differently from the rest and because they are the ones a classification decision most directly determines.

Pricing surface is the first. Anything presented as a standalone purchasable product needs a public answer to what it costs, and that answer becomes a durable commitment the moment it is published. It has to be explained, defended, applied consistently and kept in step with what the product actually does. A feature inside a larger product usually has no separate pricing surface at all, which removes an entire category of standing work. Once a separate surface exists, changing it is expensive in a way that has nothing to do with engineering, because published prices set expectations that outlive them and every revision has to be reconciled with what earlier readers were told.

Documentation is the second, and it scales with the number of distinct mental models rather than the number of pages. A feature adds a section to an existing set and inherits its structure, navigation, search and publishing route. A standalone product needs its own set, with its own information architecture and its own front door, and that set has to be discoverable, which drags in the whole apparatus of a site that expects to be found. Google Search Central documents what makes a page eligible to be crawled, indexed and represented well in results. That is another published standard which moves on its own schedule, and against which every published set has to be periodically re-checked rather than checked once.

Release cadence is the third, and it is the one that most reliably turns into an implicit promise. A product that has shipped visible changes on a regular rhythm has taught its readers to expect that rhythm, and a silence is read as abandonment long before it is one. A feature can go untouched for a year inside an actively developed product without signalling anything, because the host's cadence covers it. Once something is standalone, its cadence is its own signal, and maintaining that signal becomes a standing obligation independent of whether there is anything worth releasing. That is a genuinely perverse incentive, and the only honest way out of it is to state the state explicitly rather than to manufacture releases, which is what the later section on states is for.

Everything above suggests that a portfolio's upkeep grows faster than linearly, and left alone it does. The mechanism that slows the growth is sharing: one design system rather than several, one accessibility baseline, one deployment approach, one release convention, one publishing route, one legal-page structure with the specifics substituted. When those are genuinely shared, a fix applied once is applied everywhere, and the marginal cost per product drops meaningfully. Zealsync develops four products and operates one agency brand, listed on the portfolio, which makes this a practical question here rather than a theoretical one.

Divergence is what undoes it, and divergence is rarely decided. It accumulates one reasonable exception at a time. This product needed a slightly different form pattern. That one is on an older version of the framework because upgrading it was never urgent. A third has its own copy of the header because a variation was wanted once and copying was faster than parameterising. Each decision is defensible in isolation. Together they mean a fix now has to be applied three times, tested three times, and remembered in three places, at which point the flattening effect is gone and nobody can point to the moment it went.

Sharing is not a state you reach. It is a state you keep choosing, against a steady supply of good reasons to make an exception.

There is a real limit to how far this argument goes, and it is worth stating plainly. Shared standards flatten the fixed technical floor. They do very little for the obligations that are inherently per-product: the inbox, the name, the pricing surface, the cadence signal, the model somebody has to hold in mind. A company with excellent shared infrastructure can still be over-extended, and when it is, it will be over-extended in the human obligations rather than the technical ones. If you are counting only the parts a design system can absorb, you will conclude you have more capacity than you do. The way that error surfaces is described on the company side of the argument as a question of what a company is willing to be responsible for, which is the same question in different words.

Most portfolios have exactly one declared state, which is active, and one undeclared state, which is neglected. The undeclared one does the damage, because it looks identical from the outside to the declared one right up until somebody discovers it is not. Three honest states are enough, and the value of naming them is that each carries an explicit obligation set rather than an implied promise.

Active means the thing is being developed. New capability lands, the cadence is real, requests are triaged into a plan, and the full inventory is owed at full weight. This is the expensive state and it should be the deliberate one. Nothing should be active by default merely because it was active last year, and the review that confirms it is a scheduled event rather than a reaction to something going wrong.

Maintained means the thing works and is kept working, and that is the whole commitment. Security patches are applied. Runtimes stay supported. Certificates and domains renew. The inbox is read and answered, if more slowly. Documentation stays true to current behaviour, which is easy when behaviour is not changing. Accessibility conformance is held rather than extended. What is not owed is new capability, and saying so explicitly is the entire point of the label: a maintained product that is honestly described disappoints nobody, whereas an active-looking product with no releases disappoints everybody who was waiting.

Frozen means no changes are being made at all, and it is the state most often confused with free. It is not free. A frozen thing still owes the security floor, or it must come off the public network, and those are the only two options available. It still owes truthful legal pages if it holds anyone's data. It still owes a route by which a person can reach somebody, even if that route promises only acknowledgement. And it owes a stated position, because a frozen product without a stated position is indistinguishable from an abandoned one, and a reader who cannot tell the difference will assume the worse of the two.

• Active: full inventory, real cadence, new capability, forward commitments.
• Maintained: security, uptime, truthful documentation, held conformance, an answered inbox, and no new capability.
• Frozen: the security floor or removal from the network, truthful legal pages, a reachable route, and an explicit statement of the state.
• Neglected: the state you are in when you have not chosen one of the three above.

The discipline is to make the state explicit per artefact and to revisit it on a fixed schedule rather than when something breaks. A state that is never reviewed drifts back into the undeclared one, and the drift is silent by construction, because nothing about a neglected product announces itself until the day it fails.

The question of when to sunset a product is usually asked too late, at the point where the answer is obvious and the cost of having waited has already been paid. The useful signals are earlier, and they concern the state of the obligations rather than the state of the revenue. Revenue is a lagging measure of a decision that was made some time before.

The first is patch lag. If the gap between an advisory being published and it being addressed is measured in weeks for one product and months for another, the second product is already past capacity, whatever anyone says about it. Patch lag is the cleanest indicator available because it is objective, it is measured per artefact, and it cannot be talked around.

The second is the result of a documentation spot-check. Open the page describing a core flow and walk the flow. If the page is wrong, ask when it went wrong. If nobody can say, the documentation is not being maintained, which means the change process has been shedding obligations quietly for some time and this is simply the first one you happened to test.

The third is inbox latency, and specifically its variance. A consistently slow response is a policy, and a policy can be stated. An erratic response, fast for some products and silent for others, is capacity, and the silent ones are being subsidised by hope.

The fourth is the hesitation described earlier: somebody unable to answer a direct question about behaviour without first checking which product is meant. The fifth is the appearance of unowned exceptions, where a divergence exists and nobody can say who decided it or why. The sixth, and the most telling, is a change that is straightforwardly correct being deferred anyway, not because it is contentious but because applying it everywhere it needs to go is more work than anyone has. When correct changes start losing to their own application cost, the portfolio rather than the change is the problem.

None of these is decisive alone, and each has an innocent explanation available. The reason to track them together is that the innocent explanations stop being plausible in combination. If patch lag is growing, documentation is drifting, the inbox is erratic and correct changes are being deferred, the shortage is capacity, and the remedy is to carry fewer things rather than to try harder at carrying all of them.

The decision to stop is separate from the communication of it, and the communication has requirements worth stating as a specification rather than as a template. A note that cannot make all of the following statements is not ready to be published, and the inability to make one of them is usually a sign that the decision itself is incomplete rather than that the writing needs another pass.

It must state an effective date in absolute terms rather than relative ones. A date a reader can put in a calendar is a commitment. A phrase such as in the coming months is not, and it transfers the uncertainty from the party who created it to the party who has to plan around it.

It must state precisely what stops on that date. Whether the interface remains reachable. Whether existing accounts continue to function. Whether anything scheduled will still run. Whether anything integrated against it will begin to fail, and in what manner. The reader should not have to infer the scope from what the note omits, because omission reads as evasion even when it is only oversight.

It must state what continues and for how long, with dates of its own. Data access is the item that matters most, because the practical question every reader has is whether what they put in can be got out, and by when. Where an export exists, the note must say what it contains and what format it takes, so the reader can judge whether it is sufficient before the window closes rather than afterwards, when the judgement is useless.

It must state what the reader has to do, in the imperative, ordered, with a deadline attached to each step. A note that describes a change without naming the actions it requires leaves every reader to derive a plan of their own, and most will derive it late. If the answer is that no action is required, that must be said explicitly, because silence on the point reads as an omission rather than as reassurance.

It must say where to ask, and the route it names has to be one that is genuinely answered for as long as the note remains relevant. A discontinuation note pointing at an unattended address is worse than one pointing nowhere, because it makes a promise that is then broken at the exact moment the reader is already inconvenienced and least inclined to be generous about it.

And it must remain findable after the fact, at a stable location, well past the effective date. People arrive at the question long after the announcement, usually from an old link or an old reference. A note that is published, circulated and then quietly removed leaves the reader with the worst available outcome: a thing that no longer works and no explanation of why it stopped.

Written to that specification, such a note is an unremarkable document. The difficulty is never the writing. It is that each requirement forces a decision which may not have been made, and the note is simply where the absence of those decisions becomes visible to somebody outside. If drafting one is hard, the drafting is not the problem.