Multi-location System Design
Multi-location System Design
Multi-location System Design
ROLE
Lead Product Designer
DURATION
4 Weeks
SCOPE
System Architecture · Permissions · Multi-Location Systems
AI Agent · Review Management ·Manager App Redesign
Growth is gradual.
But early system decisions are hard to undo.
This project focuses on designing a multi-location system for small restaurant groups (1–10 locations), at the moment when expansion begins to lock in long-term structure.
The goal was to enable fast growth today—without creating structural debt that becomes painful to unwind later.
Context: Growth Is Gradual, Not Enterprise Overnight
Most of our customers didn’t start as chains. They comfortably operated one to three locations using a flat, location-by-location setup.
The need for multi-location support consistently surfaced when our user opening the fourth store—especially when expansion crossed state lines.
At that point:
Owners logged into multiple accounts to review performance
Menus and employees were manually recreated per location
Brand consistency conflicted with local tax, wage, and pricing realities
Our user didn’t want enterprise software. They just wanted their next store to work—without breaking what already worked.
Most of our customers didn’t start as chains. They comfortably operated one to three locations using a flat, location-by-location setup.
The need for multi-location support consistently surfaced when our user opening the fourth store—especially when expansion crossed state lines.
At that point:
Owners logged into multiple accounts to review performance
Menus and employees were manually recreated per location
Brand consistency conflicted with local tax, wage, and pricing realities
Our user didn’t want enterprise software. They just wanted their next store to work—without breaking what already worked.
Most of our customers didn’t start as chains. They comfortably operated one to three locations using a flat, location-by-location setup.
The need for multi-location support consistently surfaced when our user opening the fourth store—especially when expansion crossed state lines.
At that point:
Owners logged into multiple accounts to review performance
Menus and employees were manually recreated per location
Brand consistency conflicted with local tax, wage, and pricing realities
Our user didn’t want enterprise software. They just wanted their next store to work—without breaking what already worked.
design goal: move fast without creating structural debt.
This work started with a very practical need:
helping the sales team onboard new customers and support deals without friction.
The immediate goal was to support sales by getting new locations live quickly and keeping changes low-cost.
At the same time, decisions were made through a system lens, so the product could scale without hidden issues.
This work started with a very practical need:
helping the sales team onboard new customers and support deals without friction.
The immediate goal was to support sales by getting new locations live quickly and keeping changes low-cost.
At the same time, decisions were made through a system lens, so the product could scale without hidden issues.
This work started with a very practical need:
helping the sales team onboard new customers and support deals without friction.
The immediate goal was to support sales by getting new locations live quickly and keeping changes low-cost.
At the same time, decisions were made through a system lens, so the product could scale without hidden issues.
core architectural decision: two Levels, explicit scope.
We intentionally adopted a two-level architecture:
Company-level
Location-level
Rather than introducing deeper hierarchies early, we focused on clear responsibility boundaries with explicit scope control.
Company-level users access aggregated data and centralized configuration
Location-level users operate in a single-store context, focused on execution
Capabilities (what you can do) are separated from scope (where you can do it).
This prevents accidental overreach — while allowing intentional delegation.
We intentionally adopted a two-level architecture:
Company-level
Location-level
Rather than introducing deeper hierarchies early, we focused on clear responsibility boundaries with explicit scope control.
Company-level users access aggregated data and centralized configuration
Location-level users operate in a single-store context, focused on execution
Capabilities (what you can do) are separated from scope (where you can do it).
This prevents accidental overreach — while allowing intentional delegation.
We intentionally adopted a two-level architecture:
Company-level
Location-level
Rather than introducing deeper hierarchies early, we focused on clear responsibility boundaries with explicit scope control.
Company-level users access aggregated data and centralized configuration
Location-level users operate in a single-store context, focused on execution
Capabilities (what you can do) are separated from scope (where you can do it).
This prevents accidental overreach — while allowing intentional delegation.
scaling without disrupting daily work.
key system areas.
Permissions — Preventing Accidental Overreach
Permissions are applied with explicit location scope by default.
For example, a regional manager may be allowed to edit menus,
but only within a predefined set of locations rather than globally.
This ensures delegation is intentional.
Global impact never happens implicitly, and high-risk actions are structurally constrained instead of relying on warnings or user caution.
Permissions — Preventing Accidental Overreach
Permissions are applied with explicit location scope by default.
For example, a regional manager may be allowed to edit menus, but only within a predefined set of locations rather than globally.
This ensures delegation is intentional.
Global impact never happens implicitly, and high-risk actions are structurally constrained instead of relying on warnings or user caution.
Menus — Designing for Precedence, Not Just Reuse
Menus are shared by default, but conflicts are resolved through explicit precedence rules.
For example, when a location overrides a price due to local tax or labor conditions, subsequent company-level price updates do not overwrite that value automatically.
Overrides persist unless explicitly reset, preventing silent drift and preserving trust in global changes.
Menus — Designing for Precedence, Not Just Reuse
Menus are shared by default, but conflicts are resolved through explicit precedence rules.
For instance, when a location overrides a price due to local tax or labor conditions, subsequent company-level price updates do not overwrite that value automatically.
Overrides persist unless explicitly reset, preventing silent drift and preserving trust in global changes.
Marketing & Reporting — One Structure, Two Decision Contexts
Marketing and reporting operate on a single shared data structure,
but decisions are made at different levels.
Company-level users compare performance and define campaigns across locations.
Location-level users focus on execution and local results.
This avoids parallel systems and keeps cross-location insights consistent without interfering with day-to-day operations.
Marketing & Reporting — One Structure, Two Decision Contexts
Marketing and reporting operate on a single shared data structure, but decisions are made at different levels.
Company-level users compare performance and define campaigns across locations.
Location-level users focus on execution and local results.
This avoids parallel systems and keeps cross-location insights consistent without interfering with day-to-day operations.
trade-offs.
We deliberately avoided over-designing:
No early group or regional hierarchies
No free-form permission combinations
No optimization for hypothetical enterprise scale
Complexity was constrained by design—not postponed.
Designing for growth isn’t about predicting the future.
It’s about removing the structural traps that make growth painful.
By choosing a simple two-level architecture with explicit scope control, this system supports immediate expansion while remaining structurally sound as organizations evolve.
