Operator-built data warehouse — enterprise intelligence at small business scale
Small business — operator-owned and run, not PE-backed, not venture-funded
Function
Context
Engagement
OngoingThe challenge
The franchise system provided off-the-shelf reporting. It was not enough. Daily and weekly visibility into pacing and labor existed in scattered places, each with its own version of the truth. Portfolio-level pacing across stores was spreadsheet stitching that nobody trusted by the time the meeting started. Membership revenue was running through the same calculation logic as general revenue, which meant the pacing math was wrong in ways that were easy to miss and hard to catch after the fact. The stores were running on franchise-system data that was never designed to answer an operator's actual operating questions.
Architecture
Source
POS system
Source
Membership platform
Source
Payroll system
Data warehouse
SQL materialized views
Membership revenue calculated correctly before it reaches the report
Morning Snapshot
Same number on every desk, every day — no manual step
Store Budget Pace
Portfolio-level pacing that holds at the operator level
The approach
Most small business operators accept the reporting the franchise system gives them because building something better feels out of reach. The data exists — it is sitting in the POS, in the membership platform, in the payroll system. What is missing is the infrastructure to pull it together into a single, trustworthy, daily operating view.
The architecture started with the question operators actually need to answer every morning: are we pacing to budget, and what is labor doing relative to revenue? Everything else is downstream of that. The data warehouse was designed around those questions, not around what was easy to export.
Membership revenue is the core complexity. In a membership-based business, the pacing math breaks the moment membership revenue is treated the same as transaction revenue. The fix was moving the calculation logic from JavaScript running in the reporting layer — where it was fragile and easily corrupted — into SQL materialized views that run on the data before the report ever loads. Clean data in, clean numbers out.
The Daily Review interface was the output that mattered most to the team. One interface, one cadence, one number per metric. Managers across the portfolio start each day from the same Morning Snapshot rather than from their own version of the truth. The Store Budget Pace Table runs at the portfolio level alongside it. The system does not require Finance to produce it — it runs overnight and is ready before anyone walks in.
A small business operator should not have to run on worse data than a PE-backed platform. The data exists. The question is whether to build the infrastructure to use it.
The outcome
A purpose-designed data warehouse sits underneath the business as its operating spine. A Daily Review interface delivers a Morning Snapshot — the same number on every desk in the network, at the start of every day, without a single manual step. A Store Budget Pace Table gives portfolio-level pacing that holds. Calculation logic moved from fragile JavaScript into SQL materialized views, removing the corruption risk that comes from membership revenue contaminating pacing math. The infrastructure is what a PE-backed operator would expect. It runs in a business a fraction of that size.
Infrastructure
Purpose-built warehouse
Designed around operator questions, not around what was easy to export from the franchise system
Cadence
Daily — automated
Morning Snapshot runs overnight, same number on every desk before the day starts
Accuracy
Clean pacing math
Membership revenue isolated in SQL materialized views — corruption risk removed at the data layer
Working on something similar?
Get in touch