Architecture · FS-06
Multi-Location Franchise HQ
ARCHITECTURE · $15K–$30K PROJECT BANDNetwork-wide performance in one view: revenue against target per location, review and audit scores, staff turnover, royalty status, and a field-support visit that schedules itself the day a location trips a threshold rather than the month after.
Every figure in this console is sample data, shown to demonstrate the interface. It is not real client data and not a performance claim.
The problem this is shaped around
A franchisor finds out a location is in trouble when the royalty payment is late, which is usually two months after the trouble started. Every earlier signal — the audit score, the review trend, the turnover — exists, but it exists in a different place from every other signal.
How work moves through it
Stage 1
Location reports in
Point-of-sale, review platform and audit tool each write to the same location record, so the signals sit beside each other instead of in four dashboards.
Stage 2
Thresholds evaluated nightly
Revenue against target, audit score, turnover and royalty status are checked as a set. Any one tripping raises the location on the heatmap.
Stage 3
Field audit on a phone
Findings are captured on site with photo evidence and auto-ticketed. A finding closes only against a corrective photo, so 'resolved' means something.
Stage 4
Support visit scheduled
A tripped threshold books a field-support visit automatically rather than waiting for someone to notice the pattern in a monthly report.
Human step
Franchisor decides
The network view shows operations and development pipeline together, so a territory decision is made against how the existing locations are actually doing.
Gold marks a step a person takes. There is always at least one, on purpose: the system prepares and displays, a human confirms and executes. That is the rule for money movement and for anything a model extracted from a document, and it is not negotiable on a build.
Decisions taken at the schema, not retrofitted
A location is the unit, not a store number in a spreadsheet
Every signal — financial, operational, human — hangs off one location record. The alternative is four systems keyed differently, which is exactly the state this replaces.
Audit findings are records with a lifecycle
Open, ticketed, corrected, verified. A checklist that produces a score and nothing else tells a franchisor how bad things were, never whether they were fixed.
One database per client, not shared tables
Each build runs in its own container against its own database with its own credentials. Isolation by table prefix inside a shared database is the mistake this replaces: it works until one missing filter in one query shows a business its competitor's numbers, and by then the whole schema depends on it.
Every file is bound to the record it belongs to
A photo, receipt or signed document is stored with a pointer to the specific job, invoice or claim it belongs to, plus who uploaded it and when. The test is whether searching a transaction a year later surfaces its own proof automatically. A folder of unlinked images fails that test, and it is the state most businesses are in.
Where it breaks, and what it does about it
Anything can be made to work on a good day. This is the list that decides whether a system survives a bad one — and the honest cost of each answer, because none of them are free.
| When this happens | The system does this | What that costs to build |
|---|---|---|
| A location's point-of-sale feed goes quiet | Silence is treated as a signal, not as zero. The location is marked stale with a last-received timestamp, because a store showing no revenue and a store not reporting are very different problems and must never look the same on a heatmap. | Every metric needs a freshness timestamp carried alongside the value. |
| A royalty debit fails | Past-due status surfaces on the network dashboard the same day, alongside that location's operational signals — so the conversation is about the business, not just the payment. | Requires the billing feed to write into the same record as operations, which is usually a separate integration. |
| An auditor closes a finding without fixing it | They cannot close it without a corrective photo attached. Whether the photo shows the fix is a human judgement, but the absence of one is caught by the system. | Storage, and an upload step auditors resist until the first time it protects one of them. |
What this deliberately does not do
- It does not enforce the franchise agreement. It surfaces breaches; enforcement is a legal process between franchisor and franchisee.
- It does not debit royalties itself. It shows what is due and what failed; a person executes the collection.
- Non-owner roles cannot see network financials, and that is enforced field by field rather than by hiding whole pages — a page a manager can legitimately reach must not leak a figure they should not see.
Book an architecture scoping session
An hour on your actual operation — where the work currently queues, what gets re-keyed, which step everyone has quietly built a spreadsheet around. You leave with a diagram like the one above drawn for your stack, whether or not you build it here. Scope is written before any payment, always.
The linked walkthrough is an interactive demo, not a deployment: it runs entirely in your browser with sample data and resets when you refresh it. This page describes the architecture built when a business commissions the system — not a claim that this particular one is running anywhere. Systems are built on infrastructure we operate, and your data stays yours and is exportable on request at any time, including if you leave.
FS-06 · franchise-network