Commercial · July–August 2026 · in production
Be&Track
A launched subscription product delivered in one month, then refined through testing and client feedback.
The brief
- Goal in, numbers and a training plan out.
- History and charts, or the data is dead.
- The fridge: enter what is already home, get the day laid out in grams.
Shape
Three clients, one place where anything is calculated — otherwise the bot and the app eventually disagree about your calories.
Mini App ─┐
Browser ─┼─→ FastAPI · shared application API
Bot ─┘ │
↓
auth/ · HMAC-SHA256, no fallback
│
↓
services/ · shared business rules
│ │ │
PostgreSQL Gemini Tribute
product data │ subscriptions
↓
ai_usage_log
feature · model · tokens · price
Three decisions
The model names the food, the code weighs it. The model reads the photo and returns dish names and a rough portion size; the grams come from a lookup table, so every number on screen is one I can trace.
The model reads, the code counts. TDEE, macro splits, gram selection and the "does this add up?" check are ordinary functions with tests, so the numbers are the same every time and I can explain any of them.
A greedy algorithm was enough. Protein first, then fat, then carbs, then a cap so nobody is told to eat 800 g of quark. It gets close enough that a proper optimiser was not worth the time, and it sits behind an interface I can swap later.
Delivery with the client
The first brief was a starting point rather than a frozen specification. Testing exposed gaps, the client brought new ideas as working screens became available, and I turned that feedback into revised flows and shipped features throughout the month.
Safety
initDataUnsafeis never trusted; the signature is verified server-side and expires.- No no-auth fallback. No token means 401, including in development.
- Payment webhooks are idempotent by external ID; a bad signature is stored flagged, not dropped.
- Every model call is metered — without that there is no honest subscription price.