· Niklas Nilsson, CEO
The code was fine. The ground it stood on had rotted.
A platform in food and health — an admin, a backend and a mobile app — stopped being worked on. Not all at once, and not by anyone's decision recorded in the history. The commits simply stop.
Three repositories, one silence
- Admin — 2,476 days of calendar, 112 of them with a commit. 87% of the span sits inside a stretch of 30 days or more with nothing at all. Longest single silence: 928 days.
- Backend — 2,480 days, 262 with a commit, 67% dormant. Longest silence: 290 days.
- App — 2,465 days, 250 with a commit, 72% dormant. Longest silence: 561 days.
Then, over four weeks in spring 2023, all three woke up: the backend on 14 April, the admin on 21 April, the app on 11 May. Three repositories do not restart within a month of each other by accident. Somebody decided.
Both ends of that silence have an ordinary business explanation, and neither is neglect. The product never got its customers going, so the work stopped — the correct decision when there is nothing to build towards. Years later a new CEO arrived and wanted to test selling it again.
That is the part worth sitting with. The sales attempt could not begin until the system ran. Before anyone could show the product to a prospect, three repositories dark for between nine months and two and a half years had to be brought back.
Waking the admin cost 24 lines
The first commit back on the admin is titled Bring project into the 2020's (made it work with node 18). It changed 11 files: 7,446 lines added, 8,940 removed.
Of that, 7,383 added and 8,882 removed were the lockfile. Three source files changed, by 24 lines in total.
The dependency count did not move: 27 before, 27 after. Nothing new was needed. Everything was simply dragged forward — React 16.13.1 to 18.2.0, two major versions.
The Dockerfiles are the clearest witness to what had happened underneath. The admin was pinned to node:erbium — Node 12. The backend was on node:12.18.4, and one of its cron containers was still on node:8.11.3.
Node 8 left support in December 2019, ten months before the admin's last commit. Node 12 followed in April 2022, in the middle of the silence. By the time anyone opened the repository again, the runtime the product was built against had been unsupported for a year, and one of its containers for more than three. Nobody did anything wrong to arrive there. The dates simply passed.
Of the 17,379 lines alive in the admin today, 24.2% were written in the first two years and have not been touched since. From 2021 and 2022 there is not one surviving line — not because the code was replaced, but because in those two calendar years nobody wrote any.
Waking the app cost 346 files
The same product, the same silence, a different bill. Measured across the app's restart diff:
- 346 source files — 6,293 lines added, 10,723 removed
- 37 native shell files under
ios/andandroid/— 792 added, 1,127 removed - 3 lockfiles — 4,034 added, 9,721 removed
- 3 manifests — 133 added, 113 removed
The commit titles are the honest version of what that week was: Minimum updates to get app running on iOS, then Starts on ios, then Starts on both android and ios. Four days to make it launch at all, before a single feature was touched.
This is the part worth taking away. Dormancy does not cost a fixed amount. It costs in proportion to how much platform sits underneath you, and how much of that platform moves without asking. A web application has one runtime and a browser that is aggressive about not breaking the past. A mobile application has two operating system vendors, two toolchains, two native build systems and store minimums that advance on a schedule set by somebody else. Leave both alone for eighteen months and only one of them is still where you left it.
What all of it came to
Bringing all three back cost roughly three person-months, spread across several people rather than one.
That figure is our own estimate and we label it as one. Nothing in a repository records effort, and anybody quoting an exact number out of a git history is reading something that is not there. What the repositories do show is the calendar around it: between April and December 2023 there were 79 distinct days on which somebody committed to one of the three. Part-time work, stretched across eight months, adding up to about a quarter of a person-year.
Set that against the admin's 24 changed lines of source and the shape of the problem is clear enough. Almost none of the three months went into writing the product. It went into runtimes, toolchains, native build systems, and finding out what departed colleagues had known.
The part that is not in any diff
Fifteen people had touched this system before it went quiet. Nine touched it after the restart. Four were present on both sides.
The app is the sharpest case: fourteen people built it, and two of them were still there when it was woken up.
Eleven people who knew why a decision had been made were gone. Nothing in the repository records what any of them knew. No amount of reading the diff recovers it, and every estimate written without it is a guess.
That is the real bill for a dormant codebase, and it does not appear in a single line of the changes above.
Getting it to build is not the same as getting it back
The admin's April commit made it compile. Then the repository went quiet again for 137 days, and real feature work only resumed on 5 September.
Nothing was wrong. We had done our half — the thing ran — and the commercial half it was waiting on had not arrived yet. A codebase can be technically alive and still have nothing to do.
This is worth separating out, because the two are usually quoted as one job. Making a dormant system build again is a bounded, estimable piece of work. Putting it back into production is a different project with a different owner, and it is often not the one holding the repository. If you are being sold a single number that covers both, one of the two halves is being guessed at.
Four things to measure before you ask anyone for a quote
Run these on your own repository tonight. They take a minute, they are the first four numbers we look at, and every one of them is checkable.
How many days did anyone actually work on it? Compare the answer with the calendar span. The admin above: 112 days out of 2,476.
git log --format=%ad --date=short | sort -u | wc -lHow long is the longest silence? Sort those dates and diff the neighbours. Past a year, your first problem is the runtime, not the code.
How much of the original survives? Blame every file at HEAD and count the lines by year. If most of it predates your last major upgrade, the upgrade went around it.
How many of the original authors are still reachable? Compare the author list either side of your longest gap. Four out of fifteen, above. This is the number that decides the estimate, and it is the one nobody looks at.
The bill does not arrive when the work stops
None of this was anybody's mistake. A product without customers should stop being built. A new CEO who wants to test selling it is exactly the right person to restart it. Both decisions are sound, and the sales work that followed is moving.
But they were separated by two and a half years, and everything underneath the code moved in between. Node went out of support, React crossed two majors, and on mobile both operating system vendors advanced on a schedule nobody here set. So the cost of the silence did not land in 2021 when the work stopped. It landed in April 2023, on the critical path of a commercial decision that had nothing to do with engineering.
Dormancy is free right up until the day someone decides to move, and that day is not chosen by the person holding the repository. The technical work is not the risk. The risk is that it has to happen first, at a moment picked by the business, with a team that has lost eleven of the fifteen people who knew why anything was built the way it was.
Run the four measurements above on your own repository while nobody is waiting for the answer. They are much cheaper to look at now than in the week somebody asks whether you can be ready to sell next month.