Can Cal AI be vibe coded?
Point your phone at a plate of food and get a calorie and macro estimate logged to a daily total.
The core trick, send a food photo to a multimodal model and ask for calories and macros as JSON, is a one-evening build and works surprisingly well. Where it stops being easy is everything around it: a native app that opens fast, a camera flow you actually use three times a day, barcode lookups against a real food database, HealthKit or Google Fit sync, and streaks that keep you logging past day four. Accuracy is also less about your prompt and more about calibration, portion-size guessing is where these apps live or die and you have no correction data. A local PWA is a genuinely useful personal replacement if you are the kind of person who will tolerate a browser bookmark instead of an app icon. You are also renting the vision model, so this is not fully self-contained.
Jump to the build brief ↓Legacy-calibrated assessment
Checked Aug 2026
What you pay today, before any DIY hosting
medium editorial confidence
Tracked separately from the pricing check
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- Snap or upload a food photo, a vision model returns dish name, portion guess and macros as structured JSON, and it gets appended to a local daily log with running totals.
- Log workouts and nutrition, track trends, and keep personal health data exportable.
- A responsive interface with real empty, loading, success, and error states.
The parts a prompt cannot buy
- A native app with widgets, notifications and instant cold start
- Barcode scanning against a maintained packaged-food database
- HealthKit / Google Fit / Apple Watch sync
- Streaks, coaching copy and the habit scaffolding that makes tracking stick
- The last 20 percent is sync, migration fidelity, speed, and edge cases.
- Trust, audits, and counterparties matter more than feature parity.
Build, switch, or keep paying
Narrower, with trade-offs
Snap or upload a food photo, a vision model returns dish name, portion guess and macros as structured JSON, and it gets appended to a local daily log with running totals.
Use the build brief ↓No checked option yet
Compare the prior art below or build only the workflow you need.
$9.99/mo
Because calorie tracking only works if the friction is near zero, and a subscription buys an app icon, a camera that opens in half a second, a food database, and a nag notification at 8pm. A self-hosted web version costs you nothing per month but adds three seconds and a mental hurdle to every meal, which is exactly the amount of friction that ends a tracking habit. People are not paying for the vision call, they are paying for the thing that makes them do it on day thirty.
Visit Cal AI ↗Why people still pay
Because calorie tracking only works if the friction is near zero, and a subscription buys an app icon, a camera that opens in half a second, a food database, and a nag notification at 8pm. A self-hosted web version costs you nothing per month but adds three seconds and a mental hurdle to every meal, which is exactly the amount of friction that ends a tracking habit. People are not paying for the vision call, they are paying for the thing that makes them do it on day thirty.
The last 20 percent is sync, migration fidelity, speed, and edge cases.
Trust, audits, and counterparties matter more than feature parity.
The useful dataset is owned, accumulated, or expensive to reproduce.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Cal AI
Context
Cal AI — Point your phone at a plate of food and get a calorie and macro estimate logged to a daily total. It currently costs $9.99/mo.
The core trick, send a food photo to a multimodal model and ask for calories and macros as JSON, is a one-evening build and works surprisingly well. Where it stops being easy is everything around it: a native app that opens fast, a camera flow you actually use three times a day, barcode lookups against a real food database, HealthKit or Google Fit sync, and streaks that keep you logging past day four. Accuracy is also less about your prompt and more about calibration, portion-size guessing is where these apps live or die and you have no correction data. A local PWA is a genuinely useful personal replacement if you are the kind of person who will tolerate a browser bookmark instead of an app icon. You are also renting the vision model, so this is not fully self-contained.
This brief describes a focused, single-operator replacement for the part of Cal AI that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.
What you are building
Snap or upload a food photo, a vision model returns dish name, portion guess and macros as structured JSON, and it gets appended to a local daily log with running totals.
Log workouts and nutrition, track trends, and keep personal health data exportable.
A responsive interface with real empty, loading, success, and error states.
Requirements
Functional
Node 20 and a machine or cheap VPS to run it.
A phone browser, added to home screen, for the camera flow.
Acceptance that portion estimates will be wrong by 20 percent sometimes.
Data and integrations
An API key for a multimodal model that accepts images.
Each of these needs a real account, credential, or quota. Set them up before writing feature code.
Non-functional
Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
Security: server-side secrets, validated input, and no credentials in the client bundle.
Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
Portability: the operator can export their data and leave without losing it.
Implementation brief
Build a self-hosted photo calorie logger as a mobile-first PWA. No accounts, no cloud, no telemetry, single user.
Stack, no substitutions:
Next.js 15 App Router, TypeScript, Tailwind. Server actions and route handlers only, no separate API service.
SQLite via better-sqlite3, file at ./data/food.db, schema created on boot if missing.
OpenAI-compatible chat completions with image input for the estimate. Read OPENAI_API_KEY and MODEL from .env. Commit a .env.example, never a real key.
Core loop:
1. Home screen shows today: total kcal, protein, carbs, fat, plus a list of logged entries with thumbnails and a delete button on each.
2. A big camera button uses an input type="file" with accept="image/*" and capture="environment". Resize client side to max 1024px on the long edge, JPEG quality 0.8, before upload.
3. Server action stores the image under ./data/uploads, then sends it to the model with a strict instruction: identify each distinct food item, estimate portion in grams, return JSON only matching { items: [{ name, grams, kcal, protein_g, carbs_g, fat_g, confidence }], notes }. Use JSON response format and validate with zod. On parse failure, retry once, then surface an error, do not fake numbers.
4. Show a confirmation screen listing detected items with editable grams. Editing grams rescales that item's macros linearly. Save writes one row per item plus a parent meal row.
5. Manual entry form as a fallback: name, grams, kcal, macros. No barcode scanning, no external food database.
Also include:
A daily kcal and protein target stored in a settings table, shown as progress bars.
A /history page: last 30 days, one row per day with totals, and a tiny inline bar chart drawn with divs, no chart library.
Export button that dumps all entries as CSV.
PWA manifest and an icon so it can be added to a phone home screen. Offline is out of scope, say so in the README.
Explicitly out of scope: auth, multi-user, HealthKit or Google Fit sync, push notifications, streaks, recipes, native apps.
Deliver a README with setup, .env vars, how to run on a LAN so the phone can reach it, and one blunt paragraph noting that portion estimates from a photo are rough and the edit-grams step is not optional if you care about the numbers.
Delivery standard
Inspect the repository first, then write a short implementation plan before writing code.
Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
Add structured logs around every external call and return actionable errors without leaking sensitive details.
Write unit tests for the core logic and one automated test of the main user journey.
Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.
Acceptance criteria
A clean install starts the app using only the README and .env.example.
The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
Tests, type checking, linting, and a production build all pass with no ignored failures.
No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.
Non-goals
Do not build these, and do not claim to have replaced them:
A native app with widgets, notifications and instant cold start.
Barcode scanning against a maintained packaged-food database.
HealthKit / Google Fit / Apple Watch sync.
Streaks, coaching copy and the habit scaffolding that makes tracking stick.
Whatever portion-size calibration they have learned from millions of corrected logs.
What you still own after launch
Secure credentials, rotate secrets, and handle provider rate limits.
Run migrations, backups, restores, and dependency updates.
Test the critical journey after every model, API, or hosting change.
Monitor failures and fix the edge cases a first prompt will miss.
Risk
Operational risk. The code is achievable; dependable data, integrations, and ongoing operations are the real cost.
Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.
Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/cal-ai
You still own the product
- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
Projects built from this idea
No reviewed implementation has been linked for Cal AI yet. A submission is evidence for review, not automatic proof that the whole product was replaced.
Built a version of Cal AI?Submit the project as evidence for this report.
Before you start
Can Cal AI be vibe coded?
Partly, if you narrow it. The core trick, send a food photo to a multimodal model and ask for calories and macros as JSON, is a one-evening build and works surprisingly well. Where it stops being easy is everything around it: a native app that opens fast, a camera flow you actually use three times a day, barcode lookups against a real food database, HealthKit or Google Fit sync, and streaks that keep you logging past day four. Accuracy is also less about your prompt and more about calibration, portion-size guessing is where these apps live or die and you have no correction data. A local PWA is a genuinely useful personal replacement if you are the kind of person who will tolerate a browser bookmark instead of an app icon. You are also renting the vision model, so this is not fully self-contained.
What can an AI coding agent reproduce from Cal AI?
Snap or upload a food photo, a vision model returns dish name, portion guess and macros as structured JSON, and it gets appended to a local daily log with running totals. Log workouts and nutrition, track trends, and keep personal health data exportable. A responsive interface with real empty, loading, success, and error states.
What will a DIY Cal AI replacement still be missing?
A native app with widgets, notifications and instant cold start; Barcode scanning against a maintained packaged-food database; HealthKit / Google Fit / Apple Watch sync; Streaks, coaching copy and the habit scaffolding that makes tracking stick; The last 20 percent is sync, migration fidelity, speed, and edge cases.; Trust, audits, and counterparties matter more than feature parity.
What do I still own after building a Cal AI alternative?
Secure credentials, rotate secrets, and handle provider rate limits. Run migrations, backups, restores, and dependency updates. Test the critical journey after every model, API, or hosting change. Monitor failures and fix the edge cases a first prompt will miss.