I built an authenticated replenishment prototype with explainable forecasts and user review controls.
Authenticated Full-Stack Prototype
SmartGrocer
A mobile-first household replenishment and grocery-savings prototype that converts purchase history into explainable forecasts, keeps recommendations under user control, and protects household data through authenticated membership boundaries.
Project overview
View the representative interface and implementation evidence below; this public case needs no login.
Authenticated prototype with automated checks for membership, data isolation, and replenishment behavior.
Working behavior
From purchase history to a user-approved shopping plan.
SmartGrocer stores real purchase events, normalizes products into inspectable canonical keys, calculates replenishment dates from observed intervals, explains confidence, and proposes items for review. Users can approve, defer, remove, reset, or adjust recommendations before anything reaches the shopping list.
Implemented now
- Invitation-only registration, household creation, login, and logout
- Manual purchase entry and pasted receipt-text parsing
- Deterministic product normalization and explainable replenishment forecasts
- User-controlled approval, defer, remove, reset, and quantity adjustment
- Shopping-list grouping by the lower stored retailer price
- Automated backend, frontend, authentication, and household-isolation checks
Replenishment review
3 items may be needed soon
Whole Milk
Median interval: 7 days · 5 observations
Median interval: 7 days · 5 observations
Due Aug 8
High confidenceGreek Yogurt
Median interval: 10 days · 3 observations
Median interval: 10 days · 3 observations
Due Aug 10
ReviewCold Brew Coffee
Irregular purchase pattern · 2 observations
Irregular purchase pattern · 2 observations
Due Aug 12
Low confidenceProduct flow
A transparent forecasting baseline with human control.
Forecasts use observed purchase intervals and variation. Each recommendation shows the observations and confidence behind it.
Record
Capture a manual purchase or parse structured receipt text.
Normalize
Match the item to a deterministic canonical product key.
Forecast
Use observed purchase intervals and variation to estimate the next need date.
Review
Expose evidence and confidence so the user can approve, defer, edit, or remove.
Organize
Build a shopping list grouped by the lower stored retailer price.
Architecture and data boundary
The browser cannot choose which household it is allowed to access.
Protected requests derive household scope from the authenticated session and confirm that the user still has active household membership.
Authenticated request pathServer-derived household scope
React browserCredentialed requests and matching CSRF header
FastAPI auth boundarySigned session validation, issuer, audience, expiration, and revocation
Membership checkActive user-to-household membership confirmed on protected requests
MongoDB queryHousehold scope applied from verified server context
Session protection
Short-lived signed tokens are held in HttpOnly cookies and revoked server-side on logout.
CSRF binding
Cookie-authenticated mutations require a readable CSRF cookie, matching request header, and signed-token claim.
Isolation testing
Automated tests cover cross-household access denial and household-specific reset behavior.
Implementation evidence
What exists in the current prototype.
The repository is private during pilot hardening, so this public case study exposes the architecture, controls, test scope, and current boundaries without publishing secrets or live household data.
| Area | Implemented evidence | Why it matters |
|---|---|---|
| Authentication | Invitation-only registration, login, short-lived HttpOnly session, server-side logout revocation | Establishes a real authenticated pilot boundary rather than a purely visual prototype |
| Authorization | Household scope derived from verified authentication and active membership | Prevents the browser from selecting another household identifier |
| Forecasting | Median purchase interval, sample-size confidence, and pattern-consistency adjustment | Keeps recommendations understandable and challengeable |
| Input handling | Manual purchase records and receipt-text parsing with unparsed lines returned for review | Avoids silently discarding uncertain information |
| Testing | Backend tests, authenticated household scenarios, isolation checks, and frontend production build in GitHub Actions | Turns claims into repeatable checks |
| Decision authority | Approve, defer, remove, reset, and adjust proposed items | Recommendations remain proposals until the user acts |
Selected design decisions
Product usefulness and security were developed together.
- Explain before optimizing: show the observations, interval, confidence, and reason before asking the user to approve.
- Return uncertain input: receipt lines that cannot be parsed are surfaced for review rather than dropped.
- Scope on the server: household access comes from verified membership, not a client-supplied household ID.
- Keep actions reversible: users can defer, remove, reset, and edit proposals without placing an order.
- Test the boundary: cross-household access and reset isolation are automated acceptance conditions.
Project status
The authenticated boundary supports a small private engineering pilot, not a public production launch. Automated checks cover frontend, backend, authentication, and household isolation. The interface preview uses synthetic data; production operations and live retailer integrations are outside the pilot scope.
Follow one purchase through the system
A recorded purchase updates the household’s product history. The forecasting service uses the median interval between observed purchase dates, then returns the next need date, supporting observations, and a confidence indicator. The user reviews the proposal before adding an item to the shopping list.
What you can test here
This public browser prototype demonstrates forecasting and review using manual inputs. The private authenticated implementation, household isolation, retailer prices, and receipt parsing are separate.
Change the fictional inputs, run the scenario, inspect its exceptions and source references, and export a review record. Added October 14, 2026. This public demo is a separate artifact from any earlier private implementation or historical professional work.