How we built a freight operations platform where the warehouse floor, the back office, and the customer's phone all read and write the same records.
by FIWB Solutions
Most operations software problems aren't feature problems. They're reconciliation problems: the warehouse has one version of the truth, the billing spreadsheet has another, and the customer calling to ask where their shipment is gets a third. Every sync step between systems is a place where the versions drift apart — and someone's job quietly becomes putting them back together.
When we built ITA's operations platform, the design decision that mattered most wasn't any single feature. It was refusing to have more than one source of truth.
The desktop platform is the system of record. Staff run intake, warehousing, manifesting, billing, and collection through it, under role-based permissions — a warehouse operator, a billing clerk, and an administrator each see the controls their job actually needs, and nothing else.
The customer mobile app is not a separate system that gets updates pushed to it. It reads and writes the same records. When a status changes on the warehouse floor, the customer sees it immediately — not after a nightly sync, not after someone re-keys it. There is no second database to reconcile, because there is no second database.
That single decision eliminated an entire category of work before it could exist: no import jobs, no "which system is right?" meetings, no support tickets that begin with "the app says something different."
"43 modules" sounds like a feature list, but the number isn't the point — the coverage is. The platform handles the full operational loop:
Because every module works against the same records, adding the 43rd module cost far less than the 3rd did. That's the compounding return of getting the foundation right: each new capability inherits the data model, the permissions, and the audit trail instead of reinventing them.
Nobody buys operations software for its audit log — until the first billing dispute, the first inventory discrepancy, the first "who authorized this?" Then the audit log is the product.
We treat permissions, attribution, and billing controls as first-class features, not compliance chores bolted on at the end. In practice that means role-based access is enforced at the system level rather than hidden buttons in the UI, and financial records are generated from operational events rather than typed in beside them.
If your team is juggling a desktop tool, a spreadsheet, and a customer portal that don't agree with each other, the fix usually isn't another integration. Integrations multiply the number of places truth can diverge. The fix is deciding — deliberately — what the system of record is, and making everything else a view of it.
That's a design question before it's a development question, and it's worth answering before any code gets written. It scales down, too: on a body shop's website the record is a single estimate request, and the win came from the same refusal to let it be re-keyed on its way to someone who can answer it. It's also exactly the kind of question we like to be asked.