Local-first by design
The application runs on a Windows counter computer. Its Express API binds to loopback, while SQLite persists operational data outside the repository. Everyday workflows do not depend on a cloud service.
Quick Foods Store Operations.
A local-first operations application for a single retail store, built around daily workflows, manual data exports, and business rules that cannot be guessed.
Ongoing development. The repository contains implemented modules and tests; newer Smart Ordering features and full operational workflows still require acceptance verification.
// THE PROBLEM
One store. Many moving parts.
Staff schedules, time punches, payroll review, purchasing, supplier invoices, lottery reconciliation, and reporting each have their own rules. The people running the store need those workflows in one coherent application.
This is not a replacement POS. It operates alongside an existing POS whose reports must be exported manually. That constraint shapes how product identity, inventory, and replenishment data are handled.
// SYSTEM BOUNDARIES
Keep responsibilities visible.
React + TypeScriptStore interface
Express REST APIRoles / validation / business rules
SQLiteLocal persisted state
Manual POS CSV exports enter through import and review workflows, not a live POS integration. This diagram simplifies the repository architecture.
// ENGINEERING DECISIONS
The tradeoffs are the work.
Make business rules explicit
Employee and purchasing weeks have different boundaries. Lottery ticket ranges depend on denomination. Those rules are handled by dedicated code and persistent records rather than assumptions in the interface.
Treat POS exports carefully
The existing POS offers no available API. Sales, inventory, and product lists arrive as manual exports. UPC/SKU conflicts and ambiguous product matches require review rather than silent merging.
Keep ordering explainable
Cigarette demand and inventory are measured in packs, but orders are placed in cartons. Planning helpers account for protection dates, safety stock, and carton rounding; a manager reviews the resulting draft.
// EVIDENCE & LIMITS
What the code supports.
The inspected repository contains separate client and server workspaces, routes for scheduling, punches, payroll, purchasing, lottery, and permissions, versioned SQLite migrations, and server/client test files. The Smart Ordering audit identifies calculation helpers, product matching, and draft management.
Still in progress: durable catalog matching across POS exports, receiving discrepancies, supplier constraints, and complete end-to-end acceptance. These are not presented as shipped outcomes or measured business improvements.
Based on the local repository and its November 12, 2026 Smart Ordering audit. No private store data or live database screenshots are published.
// SELECTED WORK
Engineering that respects the operation.
Making operational rules visible, testable, and maintainable while keeping the application usable for the people who depend on it.
← Back to selected work