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.
The work at a glance
Inspect the representative interface and implementation evidence below; this public case needs no login.
The application is a private-pilot foundation, not a public production service. The interface preview uses synthetic data.
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.
The forecasting method is intentionally inspectable. It is a statistical baseline, not an unsupported machine-learning claim.
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.
Current maturity and limits
The authenticated boundary supports a small private engineering pilot, not a public production launch. Image and PDF OCR, live retailer pricing, payments, push notifications, shared-household invitations, verified email, password recovery, account export and deletion, production monitoring, rate limiting, secret-rotation procedures, and independent security review remain future work. SmartGrocer does not place orders, and stored price comparisons are not verified realized savings.