Work
Weekly Plan
A shift-aware nutrition and training planner that rebuilds each day's meal and session timetable around the hours you are actually working, rather than around a fixed nine-to-five.
The problem
Mainstream nutrition and training apps quietly assume a fixed day: you wake at roughly the same hour, eat breakfast, lunch and dinner at stable clock times, and train in a predictable window. A rotating roster breaks every one of those assumptions at once. The same person may start at 6am one week, 2pm the next and 10pm the week after, so “breakfast” can fall at 7am or at 4pm, the only chance to eat mid-shift is a fixed meal break, and on a night shift the last meal before sleep lands inside the biological night, when eating measurably worsens glucose handling.
Wearables carry the same blind spot, recommending a bedtime from recent sleep history with no knowledge of what time tomorrow's shift starts. For people working rotating rosters the result is that a plan is either ignored or manually re-derived every single day, and the advice that does arrive is confidently timed for a life they are not living.
What was built
Weekly Plan takes a roster the user already has, sorts each day by when the shift actually falls, and parses the real start and finish times out of each entry into 24-hour form. Entries carrying no time at all are treated as a non-working day. From that it generates a per-day timetable of meals and training anchored to the actual shift window and to an estimated wake time, rather than to clock defaults.
Each shift category gets its own distinct meal schedule. A day shift places a pre-shift breakfast, a mid-shift meal break and a post-shift main. A night shift front-loads intake, moves the main meal to a pre-shift sitting and keeps the last feed small and lean ahead of a deliberately fasted overnight window, holding roughly 1–6am clear and citing the published research on eating across the biological night and on heavy pre-sleep meals delaying sleep onset.
Around that core sit food logging with barcode scanning and photo-based product comparison, a recipe cookbook with a step-by-step cook mode and generated shopping lists, a gym and run logger with a conversational strength-programming coach, body-trend charts, weekly check-ins and configurable push notifications. A bidirectional wearable integration pulls in sleep with its stage breakdown, daily expenditure, workouts, body composition, training status and heart-rate variability, and pushes structured workouts back out to the watch with real pace targets, scheduled on the right date.
It is a genuine multi-account application rather than a single-user tool. The first account created becomes the admin; every account after that is created through a one-time admin-issued invite link, with no open public signup and unused invites expiring after seven days. Each account carries its own credentials, optional two-factor authentication with one-time recovery codes, long-lived API tokens for non-interactive clients, its own sessions and its own separate data, with per-account device sign-out and admin tools to invite, revoke an unused invite, or remove an account. Even the wearable sync sidecars are provisioned per account, so the separation does not stop at the sign-in screen.
Platform
The build is deliberately plain. There is no bundler, no framework and no runtime package to keep patched. The parts that could have been rented from a registry were written instead, and the two places where that was not sensible are called out below rather than glossed over.
What it does now
It generates a shift-aware daily plan with meals and training placed against the real shift window, plus sleep and wind-down guidance that accounts for tomorrow's start time rather than just recent sleep history. Where a wearable recommends a bedtime from the last few nights alone, the app shows that recommendation alongside a plan that has already read the roster.
Macro targets are adaptive. Instead of estimating expenditure from a formula, the app solves realised energy expenditure from logged intake measured against the actual smoothed weight trend, falls back to the wearable's activity-based estimate when there is not yet enough logging history, and is explicit about which mode it used rather than presenting a fallback with the same confidence as a personalised figure. Part-logged days are excluded from that intake average so an incomplete log cannot bias the next target low, and the user is told how many days were left out. The lean fraction of weight change is tracked from muscle-mass history so muscle loss during a cut gets flagged.
Food logging covers barcode scanning, count-or-weight entry for count-type items, and photo-based comparison of products against remaining macros and training status. The cookbook adds a cook mode and deduplicated shopping lists, and weekly check-ins adjust targets on a set cadence.
The gym side logs sessions, resolves working loads from lift history through a clamped resolver, and pushes structured sessions out to the watch: running workouts with pace targets, or placeholder strength sessions for gym days, scheduled on the correct date. When no roster is available at all, the app degrades gracefully into a supported offline state where days default to a day off, rather than failing or falling back to somebody else's data.
Continued development
Weekly Plan is still actively developed. The in-app changelog records hundreds of distinct released versions since launch, with entries timestamped to the hour and multiple releases landing on a single day.
Release discipline is enforced mechanically rather than by convention. A validation script syntax-checks the server, the inline shell and every client module both individually and concatenated in real load order, runs the web-push cryptography self-test, and asserts that the top changelog entry's version matches the package version before anything can ship. The deploy script refuses to run from any branch but the main one, refuses any version that is not strictly greater than what is already live so a bad deploy cannot silently regress features, backs up all runtime data outside the app directory, restarts the process manager, and then polls the version endpoint until the new build is confirmed to be serving.
A written versioning policy lives in both the repository instructions and the deploy script header. It was added after a real incident in which five consecutive releases were bumped as minor versions when they should have been patches. They were caught, renumbered, and then documented so the rule is read before the next release instead of being rediscovered later.
Automated daily backups snapshot every runtime data file plus the host schedule to a location outside the project, with old snapshots pruned automatically. A separate staging mode runs a fully isolated second instance against copied, production-shaped data, so changes can be tested end-to-end without touching real records. None of that is visible in the product, which is rather the point: the interesting engineering in something released this often is the machinery that stops a fast release cadence from becoming a fragile one.
Weekly Plan is not linked from this page. There is no public signup (accounts exist only by admin-issued invite), so a public link would lead nowhere useful. It is a planning and logging tool, not a medical or diagnostic one, and it does not give medical advice.
Weekly Plan is an independent product built and owned by PiStack. It is not affiliated with, endorsed by, sponsored by, or contracted to any government organisation or agency.