The data already exists. We just need to organize it.
However in my business that’s been operating for over a decade, that is far from reality
Where the Data Actually Lives
On paper, my business looks digitized, as my accounting data lives in Zoho Books—invoices, payments, expenses. That part is robust, linked, and dependable.
The problem starts everywhere else. Payroll data, contracts, approvals, and decisions are scattered across a digital slum:
- Legacy Payroll: Stores names and salaries as text, but not signed contracts or KYC documents.
- Google Drive: Stores images and proofs the payroll system couldn’t handle.
- WhatsApp: Stores daily site visit logs, buried inside groups with 1,000+ 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 an employee is fragmented. Bank details sit in payroll. ID proofs sit in Drive. Attendance is logged in Payroll system and approved sheets are uploaded as attachment to relevant invoice in Zoho Books.
This works great during everyday operations. A year later, when a dispute arises or a compliance audit hits, verification turns into a 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 Pauses.
Two to three hours go into the hunt:
- Scrolling WhatsApp media galleries to find a site photo from three months ago.
- Opening multiple Drive folders to locate the signed contract.
- Cross-checking Excel rosters against Zoho invoice attachments.
- Asking the field officer to “send it again” because no one is certain what’s correct.
This isn’t because people are careless. It’s because no single system owns the truth end-to-end.
The cost isn’t just the hours lost. It’s the cognitive load. The hesitation. The delay in every decision because we’re never fully sure we’re looking at the right file.
The Real Problem Isn’t Storage. It’s Transfer.
One of the core reasons O9X exists is to turn this chaos into a linked, searchable source of truth.
But there’s an uncomfortable reality most builders gloss over:
Getting data into the system is harder than building the system.
Every migration I’ve done confirms this.
- Payroll migration: Took two months. It only finished after I enforced a hard deadline that threatened salary delays.
- Zoho Books migration: Same story. Data cleaning took longer than setup.
Now the problem is bigger.
O9X runs alongside live operations. I can’t pause the business and ask teams to hunt, clean, and upload ten years of history. That would break the company.
The Constraint That Changed My Approach
The biggest bottleneck in building O9X is not development speed. AI has already helped there.
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 Strategy: Stop the Bleeding
Because I can’t pause operations to clean the past, I made a hard decision:
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 in me wants a pristine database from day one. The operator in me knows that demand would kill the project.
You don’t 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.