- A product can serve customers every day and still have started to hold the business back.
- Five questions bring the signs into view: the pace of change, platform support, who holds the knowledge, how releases feel, and what the product cannot do.
- There is no score. Your answers are the start of a decision that stays yours.
A product does not announce that it has become a brake. Customers still sign in and orders still go through. What changes is quieter: the roadmap slips, the same name comes up whenever something hard needs doing, and requests from sales and legal land in a column marked “later”.
This checklist does not ask whether you should rebuild. It asks whether the signs are there that you should be asking. Take each question in turn and write the answer down as a sentence, not a tick. A sentence keeps the detail a tick throws away.
Do changes take longer each quarter?
The first sign shows up in the calendar, not in the code.
Pick a few changes from the last year of roughly the same size: a new field on a form, a new pricing rule, a new report. Did the same kind of change take longer as the year went on? Ask the people who made them where the time went. “Writing it” is a healthy answer. “Finding out what else it would break” is a sign. One slow change proves nothing. A trend across quarters does.
Is the platform past its support end date?
This question has a date for an answer, published by the platform’s makers: the day they stop releasing fixes for a version, security fixes included. The Node.js release schedule, for example, puts Node.js 22 in maintenance and gives 30 April 2027 as its end-of-life date. Our framework end-of-life calendar gathers more of these dates, each linked to its source.
List what your product runs on, find each date on its official page, and mark any that have passed or fall within your current roadmap.
Does one person hold knowledge nobody else has?
Ask a plain question in your next planning meeting: if this person were away for a month, which changes would stop?
Some knowledge lives only in someone’s head: why the invoice job runs twice, which customer has the special export, what must not be touched before a release. As long as that person answers every question, nobody else learns the answer. Write down the areas where only one name comes up.
Does the team fear release day?
Listen to how the team talks about putting changes live.
A team that trusts its product ships when the work is ready. A team that has been burned by it gathers changes into large, rare releases, puts them live late in the evening, and keeps someone on call “just in case”. That is not a failing of the team. It is the team protecting customers from a product it no longer trusts. Ask them what they are afraid of, and write down what they say.
Is there a requirement the product cannot meet?
The last sign comes from outside: something a customer, the business or the law asks for that the product cannot give.
It may be a large customer who wants single sign-on, a market that expects a second language, or a law with a date on it. We cover two such laws in our essays on the European Accessibility Act and the Cyber Resilience Act, each with its legal source linked. For each requirement, note whether the product could meet it with work in a few places, or whether nobody can say where the work would start.
What to do with your answers
Read the five sentences together. They are not a score, and no number of yes answers means “rebuild”. One strong sign can matter more than three faint ones.
If the answers are calm, you have a list to watch. If several point the same way, ask the next question: change the product where it stands, or build it again. That question has its own guide, Rebuild or refactor? A decision guide, and we will not repeat it here. Neither path makes the signs go away by itself.
Where we come in
If your answers lead you towards a fresh start, Rebuild a legacy web application without losing what works describes what we can take on. If the trouble sits mostly in an ageing platform, Move off an ageing framework without stopping the product describes that path.
Your product keeps moving forward, week after week. The work lands in your own code repository. You decide what ships. Nothing reaches your users without your approval.
It starts with a conversation, with no obligation.
