GastroOps
A solo-built offline-first Nuxt 4 PWA — product design, architecture, implementation, testing, and delivery by a single developer — that replaces paper HACCP logs with digital temperature monitoring, task management, and audit trails for small hospitality businesses.
Project facts
- Role
- I defined the operational workflows and independently built the product, offline architecture, integrations, tests, and demo environment.
- Timeline
- July 2026 · Independent product prototype
- Team
- Solo project · 1 developer
The Challenge
Small food businesses like ice cream stands, cafes, and food trucks need HACCP compliance but paper logs are error-prone and easily lost. Any digital solution must survive unreliable internet in seasonal or mobile locations.
Key decision
Queue every mutation locally and synchronise idempotently after reconnection so core HACCP work never depends on a live network.
Approach
Built as a Nuxt 4 PWA with a typed domain model and repository boundary. Mutations carry UUID idempotency keys and the sync endpoint accepts bounded batches after reconnection. The server evaluates temperature ranges and checklist values, opens non-conformities, and enforces corrective-action, retest, and closure gates. Demo mode uses an in-memory repository; server adapters cover Baserow write-through and a SQLite-backed SaaS path.
Key Highlights
- Offline queue with UUID idempotency for control records, daily reports, and deliveries
- Range, checklist, and yes/no evaluation with compliant, warning, critical, and non-conformity states
- Corrective-action lifecycle that requires a retest before closure
- Role and location-scoped permissions plus QR device lookup isolation
- Delivery and product-batch traceability with safety checks
- Sanitary-inspection exports containing records, registers, audit logs, and a scope disclaimer
Architecture
- Nuxt 4 with Vue 3 and TypeScript strict
- Nuxt UI 4 and Tailwind CSS for interface components
- Pinia for offline queue management only
- Vite PWA plugin for service worker and caching
- Nitro API behind repository interfaces for in-memory demo, Baserow, and SQLite-backed SaaS modes
- Zod validation across all data boundaries
- Vitest unit tests and Playwright end-to-end tests
Verification
- Repository contract tests cover idempotency, QR isolation, corrections, dashboard metrics, template approval, and deliveries
- Playwright exercises an out-of-range temperature through non-conformity, corrective action, retest, and closure
- Zod schemas validate API inputs and cross-field rules at server boundaries
Current limitations
- The default public demo keeps state in process memory unless an optional snapshot is configured
- The Baserow adapter is write-through and does not yet provide complete read caching
- R2/S3 signed uploads and the prepared Postgres path are not complete production features
Outcome
A source-complete operational prototype with a deterministic demo, tested HACCP workflows, and documented self-hosting paths. Persistent multi-tenant deployment still requires selecting and configuring a production repository mode.
Inside the product
