Bagel Nosh

The problem

The client’s warehouse ordering process ran entirely on paper. Every week, store managers printed a PDF order sheet, filled in quantities by hand, and faxed or hand-delivered it to the central warehouse. A packer picked the order, scribbled notes about missing or substituted items, signed the sheet, and filed it in a binder.

• Illegible handwriting led to wrong items being picked and time wasted reconciling.
• No real-time status: store managers called or texted to ask "is my order ready?"
• No audit trail: disputes about what was requested versus what was delivered had no source of truth.
• No structured shortage tracking: when the warehouse ran short, the gap was a pen note, not data.
• Scattered communication: context about any given order lived in text-message threads.

Beyond ordering, the client had no digital inventory system at all: no live stock levels, no par-level alerts, no receiving records, no waste tracking, and no cost visibility.

The solution

We designed and built a warehouse order and inventory management platform, delivered as a web application that works on desktop for managers and on tablets for the warehouse floor. The first release faithfully replaced the paper form, using the same three-column category layout the staff already knew so training was near zero, and added everything paper could not do:

• Live order lifecycle: draft, submitted, picking, fulfilled, with every state change visible to the store in real time.
• Partial fulfillment as structured data: missing, short, and wrong items recorded per line item, not as margin notes.
• Append-only audit trail: who ordered what, when, who picked it, and what actually shipped.
• Per-order comment threads, so cross-location communication about an order finally has one home.
• In-app and email notifications with per-user preferences, role-based defaults, and quiet hours.

With ordering live, the platform grew into a complete inventory system: real-time stock levels per location backed by a single transactional ledger, receiving, transfers, and adjustments with server-enforced guard rails, recipes and production runs that deduct ingredients automatically, par levels and low-stock alerts, periodic stock counts that reconcile ledger drift, cost and valuation reports with CSV exports, and bulk catalog management with a safe product lifecycle.

A final phase added role-based access for six roles (admin, super user, store manager, retail employee, production, and warehouse) with location-scoped permissions enforced server-side, an approval workflow where retail employees build orders that park for store-manager approval, a global location switcher, draft orders with 48-hour sliding sessions so staff are not logged out mid-shift, and six admin-selectable theme families with light and dark modes, every combination contrast-checked for accessibility.

Architecture

• Frontend: Flutter Web (Riverpod, go_router) with an API client generated from the OpenAPI contract.
• Backend: Go (chi, pgx, sqlc), a single static binary serving REST and WebSocket.
• Database: PostgreSQL 16 with schema managed by versioned migrations.
• Realtime: Postgres LISTEN/NOTIFY fanned out over WebSockets, multi-pod safe with replay cursors.
• Auth: JWT with argon2id password hashing, refresh cookies, and role-based authorization.
• Packaging: multi-stage Docker builds, distroless for Go, nginx for the web app, non-root, pinned bases.
• Orchestration: Kubernetes (K3s) via a single Helm chart with ingress, TLS, autoscaling, network policies, and automated migration hooks.
• Observability: Prometheus metrics, structured logging, and health/readiness probes.

The contract-first approach, with a roughly 4,900-line OpenAPI specification driving both the Go handlers and the generated Dart client, kept frontend and backend in lockstep across 36 schema migrations and three major versions.

Delivery and operations

The platform runs across three cloud environments (test, staging, and production) on Rancher-managed K3s clusters, with a private container registry, environment-pinned deploy tooling that refuses to run against the wrong cluster, automated database migrations on every deploy, validated images promoted from staging to production by re-tagging rather than rebuilding, scheduled hourly and daily database backups, and TLS everywhere via cert-manager and Let’s Encrypt with Cloudflare in front of staging and production.

Security

Security was treated as a first-class deliverable, not an afterthought:

• Argon2id password hashing, token versioning for instant revocation, and forced password change on first login.
• Server-side enforcement of every role and location scope: the API is safe even against a hostile client.
• Optimistic concurrency on order writes, with audit events written in the same transaction as the change they record.
• A dedicated AI-assisted security audit of the full codebase before launch, which surfaced findings including an SSRF vector, CSV formula injection, and authorization-scope gaps, all remediated and regression-tested prior to production.
• Rate limiting with trusted-proxy-aware client IP handling.

By the numbers

• ~75,000 lines of production code (Go backend plus Flutter frontend), plus a ~5,000-line machine-readable API contract.
• 36 database migrations shipped with zero data-loss incidents.
• 6 user roles with location-scoped, server-enforced permissions.
• 3 cloud environments with one-command, guard-railed deploys.
• 8 security findings identified and fixed pre-launch through a dedicated audit.
• POC to production in about 4.5 months, then three major versions of client-driven enhancements.

Outcome

Every store order now flows through the platform. Warehouse staff pick from a live queue instead of deciphering handwriting, shortages are structured data instead of pen notes, managers watch fulfillment happen in real time, and the client has, for the first time, a complete queryable history of what every location orders and consumes, plus live inventory, costing, and production tracking on top of it.

The paper binder is retired.