One staff order, through to close

A diagram of the bounded Solid Coffee workflow accepted in the September 8 record and retained by the September 10 launch review. It is not a fresh production recording.

  1. Counter → kitchen

    An authorized staff member creates a location-scoped order. The matching kitchen/bar handoff records completion.

  2. Payment → stock

    The order links to a recorded cash or manual-Kaspi tender and recipe-linked inventory effects. Recording a tender is not bank settlement.

  3. Daily close

    The same loop reaches Daily Close for its configured scope. Invoice approval and provider/fiscal reconciliation remain separate.

Production identifiers stay private. Repeat-period, exception recovery, and ordinary full-day acceptance are still needed before making broader operating claims.

Operating problem

Independent local businesses often split customer journeys, orders, staffing, stock, and daily controls across disconnected tools. That fragmentation makes each handoff harder to operate and verify.

What changed

Kuan built Perko as one multi-tenant operating record connecting the customer marketplace, venue experience, staff workflows, owner controls, and production infrastructure.

System scope

  • Customer discovery, menus, ordering, and rewards foundations; guest ordering remains deferred
  • Counter, kitchen, inventory, workforce, and owner controls
  • Multi-tenant API, PostgreSQL records, authorization, and audit history
  • Kazakhstan deployment, encrypted backups, recovery, and monitoring

Technical constraints

  • Keep customer, staff, and owner views consistent while each tenant and location retains explicit authority over its records.
  • Connect orders, stock, staffing, payments, and rewards without merging financial or operational truth across businesses.
  • Deploy and migrate the system without weakening audit history, backup recovery, or the single-writer production boundary.

Evidence

Pilot evidence
The September 10, 2026 launch record retains one accepted staff operating loop at Solid Coffee, not a claim that every module is live.
Dated database baseline
The September 1, 2026 deployment record preserves 7 tenants, 15 locations, and 818 order records. These are database counts, not active customers, operating locations, or paid-demand evidence.
Limits
Repeated full-day operation, provider acquiring, fiscalization, and independent customer demand are not established by this case. Guest ordering is repository-ready but deferred.

Technical foundation

Applications
React and TypeScript across responsive web and PWA surfaces, with Capacitor shells for iOS and Android.
API and data
A Fastify API over PostgreSQL 17, with append-only events and ledgers preserving operational history.
Architecture
A first-party modular monolith: one tenancy, identity, authorization, audit, and module kernel serving customer, staff, owner, and operator channels.
Production runtime
Docker Compose behind Caddy, with isolated web, API, and PostgreSQL services, encrypted backups, restore checks, and one API writer.

Key decisions

Configure one platform instead of forking it per business
One release and schema serve multiple tenants and locations. Modules, business blueprints, and country packs change the operating composition without creating tenant-specific codebases.
Keep business truth on the server
PostgreSQL owns orders, stock, money, workforce, and permissions. Client state and provider systems remain projections or adapters; they cannot silently replace authoritative records.
Preserve provenance rather than overwrite history
Consequential mutations retain tenant, location, actor, device, timestamps, idempotency, and retry lineage. Corrections append compensating facts instead of editing protected history.
Separate identity, membership, and financial responsibility
Authentication identity, customer membership, and staff assignment remain distinct. Orders and reward liabilities keep their source business and location instead of being merged across the network.
Fail closed when operational truth is uncertain
Module access requires separate entitlement, activation, readiness, rollout, and permission checks. Unsupported offline payments and unresolved financial or sync states stay blocked and visible.

Need a delivery partner for your software project?

Share the market, constraint, current state, and budget reality in writing. If it looks like a fit, you will get a human response with the next step.

Start a project
Next case study Focus Pattern A visual breathing and focus tool for short, deliberate resets.