MacroCart

Inspiration

My brother is in university right now, trying to bulk, and I watched him deal with this problem firsthand. He'd get a macro target from whatever plan he was following, then just guess his way through the grocery store every week, either overspending or falling short on protein by Thursday. Nutrition apps told him what to eat like his budget didn't exist.

I ran into a version of the same problem myself. I understood macros well enough, and I understood budgeting well enough, but I'd never found anything that treated both as real constraints at the same time. It was always one or the other: an app that optimized for nutrition and ignored cost, or a budgeting tool that had no idea what a gram of protein was worth. MacroCart came out of wanting to actually fix that gap, not just for my brother, but for anyone trying to eat with intention on a real budget.

What it does

MacroCart turns a macro target and a weekly grocery budget into an actual meal plan and a shoppable grocery list. You set a goal (cut, bulk, or maintain), a weekly budget, and any dietary restrictions. From there it generates a full week of meals chosen specifically because they hit your macros without going over budget, with a swap option any time a meal is pushing the week over. The last step turns that plan into a grocery list organized by aisle, with a running total checked against your budget automatically, so there's no manual cross-referencing left for the user to do.

How I built it

I'm building this solo, so the process ran on two tracks at once: figuring out the idea itself, and figuring out how to present it clearly under a hard deadline.

I spent time on my own working through the actual problem: who it affects, why existing apps miss it, and what a solution would need to do differently. From there, I worked with Claude over several sessions to turn that thinking into the actual deliverables: the project plan, the business model, the technical architecture, the wireframes, and the pitch script.

The core of the app's design is a planning engine that treats macro targets and budget as constraints on the same problem, rather than two things to check separately. Loosely, for a set of candidate meals, the planner is solving something like: $$ \max \sum_i x_i \qquad \text{subject to} \qquad \sum_i x_i \, p_i \ge P_{\text{target}}, \qquad \sum_i x_i \, d_i \le B $$

where $ x_i \in \{0,1\} $ indicates whether meal $ i $ is included in the week, $ p_i $ is its protein content, and $ d_i $ is its cost.

is its cost. It's closer to a knapsack problem than a simple filter, which is part of why nobody's really solved it well: optimizing for one constraint is easy, optimizing for two at once is a different problem entirely.

Challenges I ran into

The biggest challenge was building the mockups for the pitch video. I don't have a working app yet, so there was nothing to record a screen capture of. I had to design what the app would look like from scratch: three full screens showing the actual flow (setting a goal and budget, seeing the week's plan, and shopping the list) detailed enough to feel real on camera, without an actual product behind them yet. Getting the visual details right (the macro breakdowns, the swap suggestions, the running budget total) so the concept would read clearly in a five-minute video took more iteration than I expected going in.

Accomplishments that I'm proud of

I'm proud that MacroCart isn't just a feature idea, it's a fully scoped product, with a real business model, a specific target audience, and an honest technical plan behind it. I'm also proud of being upfront about the hardest part of the build (grocery pricing data) rather than glossing over it. And I'm proud of how the mockups turned out given I had no working app to film: they're detailed enough to carry the entire pitch on their own.

What I learned

I came out of this with a much clearer sense of why this problem hasn't been solved already. It's not that nutrition and budgeting are individually hard, it's that grocery pricing is genuinely messy data (it varies by store, region, and week), and stitching that to a macro-accurate plan is real engineering work, not a weekend feature. Scoping that honestly, admitting in my own plan that pricing is the hard part, was more useful than pretending I had it fully solved.

I also learned a lot about translating a personal, specific frustration (watching my brother struggle with this) into something structured enough to pitch as an actual product, with a real business model and a realistic technical plan behind it, rather than just a feature idea.

What's next for MacroCart

The next real milestone is grocery pricing that doesn't depend on entering it by hand, either a data partnership with a grocery chain or aggregator, or a crowdsourced model where users confirm prices as they shop. Right behind that is expanding the recipe library past what's feasible to build solo in three weeks, and adding one-tap ordering through a grocery delivery partner. After that, I want to build a coach-facing dashboard for trainers and nutrition coaches managing multiple clients, and eventually support other currencies and regional grocery data, since ReverieHacks itself is open worldwide.