EatTailor is an AI nutrition coach you talk to instead of a database you search. Eric built it in December 2025, shelved it, then rebuilt it in one July weekend, not by writing the code himself, but by directing overnight AI agent sprints and catching what they got wrong. It is live in production right now, and hosting costs zero dollars.
The idea came out of NYU. In the Finance for Marketing course of Eric's Integrated Marketing master's program, the final was to invent a company, build its financials, and pitch it to the class. Working the problem as a group, a classmate pitched on-demand food for luxury gyms. Eric's read was that food delivery was already saturated, but that food itself was the right territory. He went looking for the version of that idea he actually had a personal stake in.
He found it in an old grudge. Eric lifted weights through high school and college, which meant years of MyFitnessPal: photographing meals, scrolling a little dial to log how many ounces of rice were on the plate, doing data entry to earn the right to see his own numbers. LLMs had just made the better interface obvious. You should be able to just tell the app what you ate, the way you'd tell a coach, and have it do the rest.
Marathon training sharpened the idea into a thesis. At the time Eric was running five to ten miles a day, and the number that mattered was not calories logged, it was the balance: a 2,000-calorie baseline, a ten-mile run that burns 800 more, and an app that should say "eat 800 more to refuel" instead of letting you train in a hole. The long-game vision was an app in tune with your goals and your training data, one that eventually knows you just ran ten miles and you're standing in a Chipotle, and orders accordingly.
The final was a group project, and the team went with Eric's idea. The assignment asked for a company on paper: financials, a pitch, a deck. Eric built the app instead, and kept building after the grade was in. Google sign-in, conversational logging, Strava wired in, nine accounts in the first few weeks, most of them classmates. Then the semester ended, the code got locked in an old account, and it sat. That is where most side projects end.
The rebuild ran as scoped sprints executed overnight by AI coding agents: audit the repo, research the 2026 market, revive the deploy path, replace the core, wire the coaching loop. Each sprint got a written spec going in and an adversarial review coming out, diffed against the actual code, not the agent's summary of it.
That review step is the whole method, because the agents repeatedly reported "done" on work that was not done.
The agent built the morning-brief scheduler, tested it, and reported success. It never imported the file into the server. The feature would have silently not existed in production. A review grep for the import caught it; a fix sprint wired it at boot behind a config flag.
The spec said remove the client-side regexes that scraped macros out of AI prose. The agent said removed. All three were still there. The re-review ran five greps against the shipped code until every one returned zero.
The agent shipped passing tests, written against its own inline re-implementation of the logic instead of the real module. Passing, and worthless. The fix extracted the real chat core into its own module and pointed the tests at it.
Same lesson as every other build on this site: the agent is the smallest part of the system.
Because this is the job now. Specs in, agent output back, and a review gate that assumes the report is optimistic until the diff proves otherwise. The domain happens to be nutrition. The skill is shipping working systems through AI leverage without trusting it blind.
The December build had a classic first-generation LLM app flaw: the AI answered in prose, and the client scraped numbers out of it with regexes. Deleting a meal depended on the model emitting a magic [DELETE:...] marker in its reply. It worked until it did not.
The rebuild inverted the architecture. The model now calls typed tools (log a meal, delete a meal, suggest a meal, answer a question), the server is the only thing that writes to the database, and the client renders state instead of parsing sentences. The app got smaller while gaining features.
The stack, honestly. Vanilla JS PWA, Node and Express, OpenAI tool calls, Firebase auth and Firestore with per-user security rules, and a dormant Strava integration. It runs on a Mac mini behind a free Tailscale tunnel. No framework, no Kubernetes, no bill.
The interesting decisions on a small project are the ones about what not to do.
The headline feature is a proactive coach: a 6am morning brief and an evening close-out, generated on a schedule, so the coach speaks first. It is built, tested, and switched off in production, because it turns out Eric does not want his nutrition app texting him at 6am.
The feature proves the capability. The off switch is the product decision. Dogfooding told the truth and the config listened.
The original deploy target wanted $5 a month. The replacement is a Mac mini already running in the apartment, exposed through a free encrypted tunnel, with the AI spend hard-capped at the account level so the worst case is bounded by config, not vigilance.
For a two-user production app, the correct infrastructure bill is zero.