Most software is built on an assumption that rarely holds in real businesses: the data already exists, it just needs organising.
In a business that has been running for over a decade, that is nowhere near reality.
Where the Data Actually Lives
On paper, my business looks digitised. Accounting data lives in Zoho Books — invoices, payments, expenses. That part is dependable.
The problem starts everywhere else. Payroll data, contracts, approvals, and decisions are scattered across a digital slum. The legacy payroll system stores names and salaries as text, but not signed contracts or KYC documents. Google Drive stores images and proofs the payroll system could not handle. WhatsApp stores daily site visit logs, buried inside groups with 1,000-plus messages. Airtable stores some operational logs. Excel stores the rest.
Each system works in isolation. Together, they form a maze.
The Archaeology Problem
Employee data is the worst offender.
The truth of any one employee is fragmented. Bank details sit in payroll. ID proofs sit in Drive. Attendance is logged in the payroll system, and approved sheets are uploaded as attachments to the relevant invoice in Zoho Books.
During everyday operations, this works. A year later, when a dispute arises or a compliance audit hits, verification turns into an archaeology dig.
What Happens When Something Goes Wrong
When a client complains or a guard raises a dispute, the process is always the same: regular operations pause.
Two to three hours go into the hunt. Someone scrolls WhatsApp media galleries looking for a site photo from three months ago. Someone else opens multiple Drive folders to find the signed contract. A third person cross-checks Excel rosters against Zoho invoice attachments. The field officer is asked to send it again because no one is certain what is correct.
This is not because people are careless. It is because no single system owns the truth end to end.
The cost is not just the hours lost. It is the hesitation. The delay in every decision because the team is never fully sure they are looking at the right file.
The Real Problem Is Transfer, Not Storage
One of the core reasons O9X exists is to turn this chaos into a linked, searchable source of truth. But there is an uncomfortable reality most builders skip past: getting data into the system is harder than building the system.
Every migration confirms this. The payroll migration took two months and only finished after I enforced a hard deadline that threatened salary delays. The Zoho Books migration followed the same pattern — data cleaning took longer than setup.
Now the problem is bigger. O9X runs alongside live operations. I cannot pause the business and ask teams to hunt, clean, and upload ten years of history. That would break the company.
The Constraint That Changed the Approach
The biggest bottleneck in building O9X is not development speed. AI has already cut that down sharply.
The bottleneck is data ingestion under live fire: finding the data, validating it, moving it without stopping work.
That means O9X cannot depend on a clean migration. It has to tolerate partial truth.
The Decision: Stop the Bleeding
Because I cannot pause operations to clean the past, I made a hard call. O9X does not start by fixing history. It starts by changing how new data is captured so the mess stops growing today.
New attendance goes into O9X. New incidents go into O9X. New onboardings go into O9X. History will be reconciled slowly, case by case.
The engineer’s instinct is a clean database from day one. The operator’s reality is that demand would kill the project. You do not clean legacy data once. You negotiate with it over time.
O9X is being built to make the future usable, not to make the past perfect.