What year two of a software product costs

Budget 15 to 25 percent of the build cost every year, starting the week you launch. Very little of that is new features. It is infrastructure that grows with usage, subscriptions that scale per seat or per call, framework and runtime upgrades that stop being optional on dates the vendors published before your project started, renewals with clocks attached, and somebody reachable the hour it breaks. That proportion is ours, a planning heuristic rather than a quote, and the rest of this is the derivation.

Year two is where software dies quietly. Not in a crisis, but in a budget drawn up to a launch date with nothing written under it, so the first upgrade slips, then the second, and eighteen months later the cheapest remaining option is to build the thing again.

We sell retainers, so take the number above as coming from an interested party and read the last two sections, which argue against buying one.

The five things that actually run up the bill

None is a surprise. All of them are missing from most budgets, which is a different problem.

1. Infrastructure that scales with what people do

The hosting bill on launch day is not the hosting bill, because on launch day almost nobody is using the product. Platform pricing has two terms and only the first is fixed: a seat charge, then metered consumption on top. Vercel’s published Pro pricing shows the shape, at $20 per month per developer seat with $20 of included usage credit and everything past it billed per unit. Add a contractor for a quarter and you have added a seat. Ship a feature that triples function invocations and you have moved the second term.

The database line only ever goes up, which is the part people underestimate. Nobody deletes rows: audit tables, webhook logs and soft-deleted records accumulate at whatever rate the product is used, and backups multiply that by the retention window. Whether the result arrives as a platform invoice or as a server you now patch yourself is the argument in Vercel, AWS or a VPS, and year two is when those two options stop costing the same.

2. Subscriptions with a growth term in them

Error tracking, transactional email, authentication, product analytics, uptime monitoring, log retention, a search index, CI minutes. Each is individually trivial, priced in the same tens of dollars a month as a streaming subscription, which is exactly why nobody counts them. On the systems we take over we usually count eight to twelve by year two.

What matters is which variable each vendor bills against. Per-seat pricing charges you for your own team growing. Monthly-active-user pricing charges you for the product succeeding. Per-call pricing charges you for a retry loop somebody wrote at 2am. Find the sentence in each pricing page that says what the meter counts, because that sentence is your second-year forecast. It is half of why build versus buy on authentication is a two-year decision, and the per-vendor version of the arithmetic is in why a quick integration is never quick.

3. Renewals that expire whether or not you are looking

Domains are the trivial case and still the most common outage of the type. Certificates are becoming interesting again. Under CA/Browser Forum ballot SC-081v3, the maximum lifetime of a public TLS certificate dropped to 200 days on 15 March 2026, falls to 100 days on 15 March 2027 and to 47 days on 15 March 2029. A yearly calendar reminder was a workable process in 2023. By 2027 it is eight renewals a year.

The safety net also went away. Let’s Encrypt stopped sending expiration notification emails on 4 June 2025, on the reasoning that renewal should be automated by now. They are right, and the consequence is that automation is the only remaining mechanism. Building it is a year-two line item for any system that did not get it on day one.

A mobile client starts two more clocks. The Apple Developer Program is $99 a year and your apps leave the store if it lapses. Google Play’s developer registration is a US$25 one-time fee, which is not the cost that matters there.

4. Support windows, which are calendar facts

People treat this category as a judgement call. It is not. The dates are published, and they were published before your build started.

• Next.js. The support policy gives a major Active LTS until the next major ships, then Maintenance LTS for two years from that major’s initial release. Version 14 and earlier are end of life today, and version 15 shipped on 21 October 2024, so its window closes next month.
• Node.js. An LTS major gets 30 months, 12 active and 18 in maintenance. Node 18 and Node 20 are both past that line.
• PostgreSQL. Five years from a major’s initial release, with minor releases at least quarterly that you are expected to apply.
• Ubuntu LTS. Five years of standard security maintenance, extendable with a paid Ubuntu Pro subscription, which is a line item rather than a way of not upgrading.
• Mobile platforms. Google Play requires existing apps to meet a target API level or stop being installable by new users on newer devices, and that bar moves every year. Apple’s App Store Improvements process flags apps not updated in three years that fall below a download threshold, then gives 90 days to ship an update before removal. So a mobile product has a minimum annual engineering spend even if you change nothing, a cost that belongs in the React Native versus native comparison and usually is not in it.

5. The hour it breaks

The last line item is availability rather than hours. Payments fail on a Friday evening, a provider changes a webhook signature, a certificate does not renew. What you buy is that somebody who can read your logs picks up, and the awkward part is that the cost is incurred whether or not anything happens: a product with no incidents this year still needed the person to exist. Whether that person can actually deploy your system is the drill in what happens if your agency disappears.

Why a deferred upgrade is not linear

This is the part that turns a manageable annual cost into a rewrite, so it is worth naming the mechanism rather than asserting that debt compounds.

One major behind is bounded work. The vendor wrote the migration guide, the breaking changes are enumerated, and there is usually a codemod for the mechanical half. Next.js 16 is the example to hand: the published upgrade guide drops Node 18 and moves the floor to Node 20.9, renames the middleware convention to proxy with the Edge runtime no longer supported there, removes next lint, removes serverRuntimeConfig and publicRuntimeConfig, adds a required second argument to revalidateTag, and fails the build on any parallel route slot missing an explicit default.js. A long list, but a finite one in which every item names its replacement, and a team that knows the codebase gets through it in days.

Two majors behind is a different kind of work, for four reasons that stack.

• Codemods are written major to major. You run them in sequence, passing through an intermediate state nobody ever shipped. If the middle step breaks, there is no reference build to compare against.
• The transitive set moves with you. Your ORM, auth library, test runner and component library each have their own peer ranges. Two framework majors usually forces a major on several of them, and each of those guides assumed you were doing one thing at a time.
• The runtime floor moved underneath. A Next.js 14 app is also a Node upgrade, because the versions it ran on are end of life, and a Node major means rebuilding native modules, which is where the genuinely unpleasant surprises live.
• You lost the oracle. On a one-major jump a failing test points at a small diff. On a two-major jump everything moved at once, so attributing a regression means redoing the upgrade in stages, which is exactly the work that got skipped.

Our own working figures, offered as ours: one major behind is days. Two is weeks. Three, on a codebase with a thin test suite, is most of a quarter, and at that point somebody says the word rewrite and is not obviously wrong.

Where a rewrite genuinely becomes cheaper

Rarely, and later than the person proposing it thinks. Four conditions make the comparison live rather than emotional. The upgrade path requires replacing a dependency with no maintained successor, so the work is a port rather than a bump. Or there is no test suite, so the upgrade must be verified by a human opening every screen, and a rewrite at least produces the tests you would then own. Or the business changed enough that a third of the code serves a model you no longer operate. Or the estimate crosses a line: ours, stated as ours, is an upgrade quoted above about 40 percent of the original build cost that produces the same product with no new capability.

The honest caution is that rewrites are the most reliably underestimated work in this industry, and the worst version is the one where the old system stays in production and keeps being maintained while the new one is built, so you pay for both longer than planned. Rewrite versus refactor takes that decision apart properly.

Defending the 15 to 25 percent

Every result on this search recycles a maintenance percentage with no derivation attached, which is why those numbers are worth nothing. Here is ours, built from weeks of work.

Take a web platform that took roughly twelve weeks to build. Under light change, year two needs one framework major done on schedule, which is several days to a week. One runtime or database major on the thirty-month and five-year clocks above, a few days, and not every year. Dependency patching, roughly an afternoon a month, much more the week an advisory lands that you have to act on the same day. Then a reserve for incidents, which is a reserve and not a forecast.

That totals two to three weeks of engineering against a twelve-week build, so 17 to 25 percent before a single infrastructure invoice. Add hosting, the database and the subscriptions, and 20 percent is a sane first pass for a planning document.

Widen it above 25 percent when any of these apply. A real-time or high-volume system, where infrastructure stops being the small term. A regulated sector with an annual audit. A mobile client, because two platform vendors each ship an OS a year with their own deadlines. A wide integration surface, because every partner’s deprecation calendar is now yours. Or an AI feature, where the model you launched on gets deprecated on a schedule you do not control and the inference bill itself moves per user.

Narrow it well below 15 percent for a marketing site. Our published band for one is $7,500 to $15,000, and its second year really is a domain renewal, a certificate that renews itself and a framework upgrade you schedule for a quiet week. Not every product carries the same tail, and pretending otherwise is how agencies sell retainers nobody needs. That band is one of ours, and our bands are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

Plainly, then: this is a heuristic for a budget line, so the second-year row in a board paper holds a number instead of a blank. It is not a quote, and nobody can quote your system without reading it. The same caveat applies to the build figure it is a proportion of, per what building an MVP actually costs.

What this costs to buy from us

Our published bands, for the version of year two where somebody else holds the pager. A support retainer starts at $2,500 a month: patches, upgrades on schedule, incident response, and the small changes that arrive whether or not anyone planned for them. Ongoing product work runs $3,500 to $6,000 a month, the tier where year two also ships features, which is a different purchase in similar clothing. If the code is somebody else’s and nobody knows what the upgrade costs, a scoping sprint is $3,500 for a week, credited in full against a build that starts within thirty days. Our build minimum, rewrites included, is $7,500. Those figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

What a retainer at the floor does not buy, stated before you ask: an overnight rota. We are a small studio, and $2,500 a month buys responsiveness in working hours with best effort outside them. If an hour of Saturday downtime costs real money, the correct purchase is a provider who staffs nights, and it is cheaper to know now than in month seven. That floor and the bands above it are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

When you should not buy this from anyone

Three cases, and together they cover more products than the industry likes to admit.

The product is finished and usage is flat. Then a retainer is a subscription you renew out of habit. Put the support dates in a shared calendar, buy each upgrade as a discrete piece of work when its date arrives, and keep a named person you can call. You will spend less and you will not resent the invoice.

You already employ an engineer. This work should be theirs. The version calendar is four dates a year and the patching is an afternoon a month, and handing it outside creates two parties who each think the other is watching. The threshold for that hire is in when to hire your first in-house engineer.

The product should be turned off. Nobody sells this option, so it is worth naming. If an internal tool has fourteen users and its year-two cost is a framework upgrade, moving them back to a spreadsheet is cheaper and sometimes correct. The reverse decision, the point at which a spreadsheet has outgrown itself, is in moving a spreadsheet to a web app. A system you keep alive out of sunk cost is the most expensive thing on this page.

The compressed version

Put 20 percent of the build cost in the second-year row and adjust with the widening conditions above. Write the support dates for your framework, runtime, database and operating system into a calendar during the build, while somebody still remembers why each version was chosen. Take each major upgrade in the year it is offered, because one behind is days and two behind is weeks. Automate certificate renewal now, not in 2027. Count the subscriptions, and for each find the sentence saying what the meter counts. And keep turning the thing off on the table, because a budget that assumes perpetual life is the one that runs out.

If you inherited a system and cannot tell which of those clocks has run down, send us the repository and the hosting bill. The first thing we read is the lockfile and the support dates, which is cheaper than guessing.