Kitchen POS multi-location PRD: why v1 is deliberately narrow

Kitchen POS multi-location PRD: why v1 is deliberately narrow

By Idalia Ward

We've been clear about Kitchen POS from the beginning: this is a simple point-of-sale system for restaurants who need more than paper but less than enterprise complexity. Our version one deliberately supports only single-location deployments. Here's why and what multi-location means for v2.

The Version One Scope

Kitchen POS v1 is designed for single-location restaurants. That's the core specification: one physical address, one inventory, one staff team, one set of daily operations. This maps to the vast majority of restaurants we work with — a single restaurant with dine-in and delivery, no franchise ambitions, no complex organizational structure.

This narrow scope reflects deliberate design decisions. We didn't try to build the complete restaurant management system in version one. We built the minimum viable POS that handles receipts, inventory tracking, and basic reporting. Everything else — multi-location, franchise management, complex analytics — is explicitly deferred to future versions.

Here's what v1 includes:

  • Order processing: Cash, card, and Digitalwallet transactions through Square integration
    • Menu and item management: Items with variants, modifiers, and categorization
    • Basic inventory tracking: Stock levels decrement on orders with manual adjustments
    • Receipt generation: Printed receipts, email receipts, no-receipt transactions
    • Staff accounts: Basic roles (cashier, manager, admin) with activity tracking
    • Daily reporting: Sales summaries, popular items, labor cost estimates

Here's what's not in v1: multi-location management, franchise or brand-level analytics, employee scheduling beyond basic time tracking, detailed cost analytics, or supply chain management.

The line between what's included and what's deferred isn't accidental. We're deliberately narrowing the focus to ship quickly and validate market response.

Why Single Location First

The decision to restrict v1 to single locations came from several considerations:

Complexity management: Multi-location POS introduces exponential complexity. Each location has separate inventory, separate staff, separate daily operations, separate finances, and often separate legal entities. Managing that at launch would have doubled our development timeline and introduced failure modes we couldn't predict.

Market validation: We need to validate that our approach works at all. Running a single location is the simplest test case — if our POS loses money at one restaurant, adding more locations won't fix it. Validate at one before scaling.

Operational simplicity: Our target customers (small, independent restaurants) typically operate one location. They don't need multi-location features. They're confused by systems that force complexity they don't have.

Clear migration path: Single-location v1 builds the foundation for multi-location v2. The data model and patterns we use at one location should extend cleanly. We learn from v1 deployments before designing v2.

V1 is our "walk before we can run" approach. We're proving the concept before expanding scope.

What Multi-Location Actually Means

Multi-location isn't just "more than one location" — it's a fundamentally different operational model. Here's what's required:

Inventory Management at Scale

Each location needs independent inventory tracking. Stock purchased at one location isn't automatically available at another. Transfer between locations happens but requires explicit actions. Each location has different suppliers, different delivery schedules, different par levels.

The data model changes:

  • Items: location-specific stock levels, location-specific pricing (sometimes)
    • Ordering: per-location purchasing workflows
    • Reporting: rollup at brand level, drill-down at location level

Staff Across Locations

The same employee might work at multiple locations. Staff accounts need cross-location visibility: what hours did they work across all locations? How do managers supervise employees at locations they don't physically visit?

Authentication becomes more complex: employees are hired by brand but assigned to specific locations.

Financial Handling

Every location has independent cash management. Each day involves cash reconciliation at every location. Reporting must present consolidated brand-level financials while showing location-by-location breakdown. Tax reporting potentially multi-state/jurisdiction complexity.

This is where multi-location becomes genuinely complex: financial reporting across legal entities with different tax implications.

Integration Complexity

Third-party integrations multiply: each location's Square account, separate payment processing, separate delivery platform integrations. The operational load increases superlinearly.

Multi-Location v2 Requirements

Based on our analysis of what multi-location requires, here's the PRD outline for v2:

Core Features

  • Location entity management (add, edit, deactivate locations)
    • Location-specific inventory with transfer workflows
    • Location-specific staff assignments and permissions
    • Cross-location staff views and consolidated time tracking
    • Location-level and brand-level reporting
    • Consolidated payment processing with location-specific accounts

Data Model Expansion

  • Locations table with address, timezone, settings
    • Inventory location mappings
    • Staff-location intersection table
    • Transfer workflow tables

API Additions

  • /locations - CRUD for location management
    • /locations/{id}/inventory - specific location inventory
    • /locations/{id}/transfer - inventory transfers
    • /inventory/transfer - transfer workflow
    • /staff/{id}/across-locations - cross-location view
    • /reports/brand - consolidated reporting

Integration Requirements

  • Multiple Square accounts (one per location)
    • Separate payment processing per location
    • Location-specific delivery platform configurations

Deployment Changes

  • Database migrations for new tables
    • Tenant isolation at application layer
    • Configuration for per-location settings

This is substantially more than v1. That's why v2 is deliberately deferred.

Roadmap: Our Staged Plan

Given complexity and our deliberate approach, here's the staged roadmap:

V1.0 (Current)

Single-location deployment, live as of April 2026.

V1.x Maintenance

We'll keep v1 running while gathering requirements from actual deployments. Bug fixes, performance improvements, minor enhancements. No multi-location work.

V2.0 (Q3-Q4 2026 Target)

Multi-location features: location management, transfer workflows, consolidated reporting. This requires significant database migration, API additions, and testing.

V2.x (Beyond)

Features beyond multi-location based on customer demand: franchise management, advanced analytics, supply chain integration.

Each stage gets validated before we build the next. This is how we avoid the common trap of building features nobody wants.

Lessons from Other POS Systems

We've watched other POS vendors attempt everything at once. They built multi-location features before establishing single-location-market fit. Many failed because they couldn't deliver reliability at one location before promising the world.

We're not repeating those mistakes. We focus on serving one location exceptionally well before expanding. Once we've proven the model, we expand deliberately.

Conclusion

Kitchen POS v1 is deliberately narrow because that's the right way to build a product that solves real problems. We're proving the concept at one location, learning from deployment, then expanding. Multi-location is a genuine future requirement, but building it before we understand v1 deployment would be premature.

v1 stays single-location on purpose. If multi-location menu and POS alignment is the decision you are weighing, tell us your timeline.