Written by: Luke Sobieraj, Founder & COO, Digital Colliers
The spreadsheet starts as the obviously correct choice. You need to track twenty prospects, or reconcile ten invoices a week, or model three pricing scenarios. Building something custom would be absurd. Excel is right there, everyone knows how to use it, and you can start today.
The problem is that almost nobody marks the calendar for when to revisit that choice.
The first year looks fine
In year one the spreadsheet does exactly what you need. You have one or two people who understand the logic. The formulas are simple enough to fix when they break. The edge cases are rare enough to handle manually. You are still figuring out what the process even is, so locking it into code would be premature.
This is the spreadsheet at its best. It is fast, flexible, and cheap. The people who say you should have built a custom platform from day one are wrong.
Year two is where the costs start hiding
By year two the spreadsheet has accumulated weight. You now have five people using it, and two of them have added their own tabs. Someone built a macro that only works on their machine. The original author left six months ago and her replacement is afraid to touch the formulas in columns M through R.
You start seeing manual workarounds. One person exports to CSV, cleans it in Python, then pastes it back. Another keeps a separate Google Sheet to track the things that do not fit the model. The errors are not frequent enough to justify a rebuild, but they are common enough that everyone has a story.
The bus factor is now one. Maybe two if you are lucky.
The crossing point sits in year three
The crossover happens when the accumulated cost of maintaining the spreadsheet exceeds what it would have cost to build a purpose-built system. The calculation is harder than it looks because most of the costs are hidden.
Time spent fixing broken formulas. Time spent explaining the workarounds to new team members. Time spent manually checking outputs because nobody trusts the sheet anymore. Revenue delayed because the bottleneck is one person who knows how to export the report. Risk sitting in the fact that if that person leaves, the process stops.
Most teams miss the crossing point by a year. They finally decide to build something when the pain is unbearable, not when the math says to move.
When you finally build, the next risk appears
The danger at this stage is overcorrection. You have been limping along with the spreadsheet for three years, so the instinct is to build everything at once. Big scope, long timeline, comprehensive feature list.
The data on custom platform projects is not encouraging. Large minorities of these initiatives get abandoned before they reach production. The pattern I keep seeing is teams who wait too long, then try to build too much, then get stuck in a pilot that never ships.
The operators who get this right treat the first version like a better spreadsheet. They rebuild the core workflow in code, ship it to three users, and iterate from there. They resist the temptation to solve every edge case up front. They keep the scope tight enough that the project finishes in weeks, not quarters.
What to watch for
You know you are past the crossover point when you hear these phrases more than once a quarter. Someone says they need to check with the person who owns the sheet before they can answer a question. Someone describes a manual step as temporary even though it has been running for eight months. Someone suggests building a second spreadsheet because the first one is too fragile to modify.
The right move is not to panic and start a six month platform build. The right move is to carve out the single most painful workflow, build a minimal version in code, and ship it to a small group. If that works, do the next one. If it does not, the cost of finding out was small.
The spreadsheet is almost always the right starting point. The mistake is treating it as the permanent solution when the signal says otherwise.