Project 4
Replacing a spreadsheet that ran a business
Every business has one. Project 4's was a spreadsheet called `master_v7_FINAL`, forty thousand rows deep, with eight people editing it at once and a colour code only two of them fully understood.
It worked, until it did not. Two people overwriting each other's changes on a Friday afternoon was the incident that started this project.
TypeScript, Node.js, PostgreSQL, Docker
Understanding before building
The temptation was to look at the columns and build a database table. That would have produced something correct and useless.
So instead I sat with the operations team for a week and wrote down what they actually did, including the parts that were not in the spreadsheet at all. Some of the most important rules lived only in people's heads:
- An order highlighted amber meant something different in the first week of the month.
- Two of the columns were no longer used but could not be deleted, because a quarterly report read them by position.
- The order of rows carried meaning. Nobody had written that down anywhere.
The spreadsheet was not the process. It was a partial recording of the process, and the rest was institutional memory.
Building it
We shipped in three stages, each one useful on its own, so the team was never waiting on a big reveal:
First, a read-only view of the same data, so people could stop opening the spreadsheet to check things. Second, editing with proper record locking, which solved the original incident. Third, the workflow rules, including the amber one.
We kept a one-way export to the old spreadsheet running for four months. That single unglamorous feature is why the migration was calm: nobody had to trust the new system before they were ready.
Result
The spreadsheet was archived nine months after we started. Order processing time dropped by about 40%, and the Friday afternoon overwrite has not happened again.
The change the team mentions is smaller than either of those: they can now see who changed what, and when.