Redi-View came to us as a useful but limited tool: a way to look at concrete data, one account at a time, with little structure around who could see what. The product had real traction with the people who used it, but its architecture quietly decided how far it could go. The opportunity was bigger than the original build assumed — so we treated this as a platform project, not a feature request.
This is a pattern we see constantly in industrial and field-service software: a tool earns its keep by solving one concrete problem, then hits a ceiling the moment a second customer — or a second crew — needs in. The work that follows isn't about adding screens. It's about giving the product somewhere to grow.
Where the original app fell short
The first version solved the obvious problem — show the data — but stopped there. There was no real notion of organizations, no permissioning beyond a single shared login, and reporting meant exporting and rebuilding spreadsheets by hand. Those gaps capped how many customers it could serve at once, and they made every new request more expensive than the last.
- Single-tenant assumptions baked into the data model
- No role-based access for crews, managers, and admins
- Analytics that lived in exports instead of the product
- Reporting that couldn't scale past a handful of sites
What we built
We re-architected Redi-View into a multi-tenant platform: organizations, users, and roles as first-class concepts, with permissions enforced on the server rather than hidden in the UI. On top of that foundation we layered analytics and reporting directly into the product, so the people running concrete operations could answer their own questions without waiting on a data export or a spreadsheet wrangler.
Multi-tenancy without the rewrite tax
The hard part of multi-tenancy isn't adding an 'organization' table — it's making sure one tenant can never see another's data, even as the product grows new features. We pushed that boundary down into the data layer and the API, so every query is scoped by default and access is a decision the server makes, not the front end. That keeps future features cheap: a new report inherits the same guarantees as the old ones.
Reporting people actually open
Operations teams don't want a dashboard for its own sake — they want the two or three numbers that change a decision today. We built reporting around the questions crews and managers were already asking in exported spreadsheets, then made those answers live, filterable, and shareable inside the product.
The lesson
When a tool is genuinely useful but boxed in by its original architecture, the fastest path forward usually isn't another feature — it's fixing the foundation so every future feature has somewhere to stand. We'd rather spend a sprint on the data model than ship ten features that each have to fight the schema. It's the difference between a product that accrues value and one that accrues maintenance.