Technical due diligence: the buyer takes on your problems too
Two sale processes, each requiring a month of preparation: the key people, licences, contracts and risks to document for the buyer’s review.
Gridky manages over 40,000 real estate properties across 12 tax regimes, with banking-grade security requirements. When I arrived, the rush to market had left significant technical debt.
Every morning, I watched hundreds of exceptions pour into Slack. The same fault appeared in several messages; I grouped them by hand. Nobody else read the channel any more. About 10 production bugs a week, stressful twice-weekly releases: to me, we had reached technical bankruptcy.
The product needed to evolve: financial simulator, advanced search engine, OpenAPI standardization. But none of that was possible until the foundations were solid.
The reduction of around 80% is a retrospective estimate. Reported frequencies — about 10 bugs per week, then 1 to 2 per month after six months — are separate approximate figures, not the series used to calculate that percentage. The six-month period includes work after stabilisation; it is not the feature pause, which lasted a month and a half.
What needed to change
About 10 production bugs per week. Slack alerts had become background noise. Bi-weekly deployments were stressful events.
The team was chasing bugs instead of building the product. Tech debt accumulated during the rush to market was blocking all progress.