Overview
Turn a recurring household task into one shared workflow
Meals started as a practical tool for my wife and me: plan dinners for the week, turn that plan into a shopping list, and reduce the time and friction involved in grocery shopping.
It was another AI-assisted build, but the product pushed into a new kind of engineering problem. Two people needed to see and change the same state while moving through a store, and each update needed to feel immediate.
Problem
Planning, remembering, and shopping were disconnected
Weekly meal planning involves several related questions: what should we make, what ingredients does it require, what have we eaten recently, and what has already gone into the cart? Keeping those answers in separate notes makes the routine slower and easier to duplicate.
The product needed to connect recipes, a weekly plan, meal history, and shopping progress without turning a family utility into a complicated planning system.
Constraints
Useful at the table, in the store, and on paper
Shared state
Both shoppers needed to see an item disappear or become checked when the other person picked it up.
Recurring weeks
The application needed a predictable reset without losing recipe information or useful meal history.
Recipe structure
Recipe data had to remain useful for planning while still producing actionable shopping-list items.
Digital and printable
The weekly plan needed to work interactively and produce a clean printout for offline reference.
Architecture
One shared source of truth across multiple clients
The application used Next.js and React for the product interface and PocketBase for recipes, plans, shopping data, and realtime subscriptions. It intentionally had no authentication because it was a private tool for one household rather than a public multi-user product.
It followed the containerized delivery path established with Nades: GitLab CI/CD published the Docker artifact to the registry, self-hosted runners deployed it to personal infrastructure, and Nginx plus Certbot handled the public edge and TLS.
01
Next.js clients
Phones, browsers, and the print view present the shared planning and shopping workflow.
02
PocketBase
Stores recipes, meal history, weekly plans, and shopping-list state without an authentication layer.
03
Realtime subscriptions
PocketBase changes are delivered to other connected clients so shoppers share the same current list.
04
Self-hosted delivery
GitLab and Docker deploy the application behind Nginx, with Certbot managing certificates.
Technical decisions
Let the real household workflow shape the model
Structure recipes for reuse
Store recipes as durable planning data rather than treating each weekly selection as a one-off entry.
Track when meals were last used
Keep recent meal history visible so planning can introduce variety without relying on memory.
Accept useful scope growth
Realtime synchronization was not part of the smallest initial plan, but it directly improved the in-store experience enough to justify the added complexity.
Support a printable plan
Treat print output as a real presentation target rather than an accidental browser rendering.
Keep access private
Avoid building authentication while the application served only the household it was designed for.
Reuse the deployment system
Carry forward the proven Docker and GitLab workflow instead of inventing a different operational path for each application.
Implementation
Connect planning decisions to the shopping trip
Recipe-backed planning
Reusable recipe records feed the weekly plan and provide the information needed to assemble shopping items.
Meal history
Persist when a meal was last selected so recent choices can inform the next week's plan.
Shared shopping state
Publish checked-item changes through PocketBase so another connected client sees the list update while moving through the store.
Print-specific presentation
Transform the interactive weekly plan into a layout designed to remain useful on paper.
Challenges
Time and coordination made simple features stateful
Realtime client updates
Synchronizing checked items meant handling updates initiated by another client rather than relying only on local interactions.
Weekly reset behavior
A recurring reset needed to clear the right working state while preserving recipes and the history used for future decisions.
Meal recency
Tracking the last time a meal was used required history that remained accurate as plans changed.
Printable output
The interactive interface and a useful paper layout had different constraints and both needed deliberate design.
Results
The workflow worked—and made planning easier
Faster shared shopping
Realtime list updates worked across clients, allowing two people to shop from the same changing list.
Better weekly variety
Seeing when meals were last used made it easier to avoid repeating the same choices too frequently.
Useful print output
The weekly plan could be printed and used away from the application.
A real family tool
The application moved beyond a demo and supported the recurring planning routine it was designed around.
Current status
A data deletion exposed an unresolved failure
The deployment is currently unavailable after deleted data began triggering an internal error. The application logs are only available from the home environment, so the root cause has not yet been confirmed and should not be guessed at.
That gap is a useful operational lesson: external health checks, centralized logs, and a small incident workflow would make the failure visible and diagnosable without waiting for physical access to the server.
Lessons learned
Small shared tools still need production thinking
Realtime behavior was scope growth, but it earned its place by serving a concrete user need. The important distinction was not whether it existed in the first plan; it was whether the value justified the state and failure modes it introduced.
The current outage also reinforces that backups, deletion behavior, observability, and recovery are product features when an application holds data people depend on.
What's next
Recover first, then make the application safer to share
Diagnose the current failure
Inspect the server logs, identify which deleted record or relationship causes the error, and restore safe behavior.
Improve recovery
Add appropriate validation, backup, and recovery paths around important family data.
Add authentication
Introduce an authentication flow and data boundaries so households beyond the original two users can use the application safely.
Add external visibility
Connect the deployment to the planned status and incident system so failures are detected and diagnosable remotely.