Go Macro.
Eat without the spiral.
A mobile app for young adults who hit menu anxiety and decision fatigue. Instead of tracking calories, Go Macro asks how much energy you have and hands back one meal you can actually make. Show up, eat, no math. Started as a React PWA, now moving to native Swift.
Menu anxiety isn't a nutrition problem.
It's a decision problem. Young adults under stress aren't choosing between healthy and unhealthy — they're frozen between any option and no option. Traditional trackers add friction where we need fluency. Go Macro reframes the entire interaction: check in with your body, get one realistic answer, and move on with your day.
Integration Engineer
I lived on the seam between the React frontend and the FastAPI backend. API contracts, async data fetching, auth state across the component tree, and keeping what the designer drew lined up with what the backend actually returned. When the team decided mid-spring to move to native Swift, I became the person mapping out what that handoff looked like: what the backend needed to expose differently for a native client, and where the web assumptions broke.
The project taught me that software is a team sport with real coordination costs. That's a different skill than just writing good code.
// Program: UW Informatics · Capstone 2026
// Winter MVP: React + FastAPI + Supabase
// Spring pivot: native Swift iOS
One goal: ship something real.
The goal from day one was simple: ship a working MVP by the UW Informatics capstone showcase. Something somebody could open, use, and come back to the next day. We spent the first week defining what "done" meant for us, and what we'd drop to get there.
As a team we set three success conditions. The core check-in → shuffle → log flow works end to end. User data persists across sessions. We can hand it to people before showcase and see them come back a second time. Everything else (fridge scanner, SMS nudges, social features) was labeled "only if we have time."
My own goal was to finish the project knowing how a full-stack system gets built across roles. I'd shipped solo projects. I'd never had to negotiate an API contract with another engineer, hand off a component to a designer, or tell a PM why a week-two feature wasn't going to make week six. That's what I wanted to learn. The AWS to Swift pivot was a crash course in it.
Research first, then build.
Winter quarter was almost entirely research and architecture. Our product researcher Shijie ran twelve hour-long interviews with UW students between 19 and 24. Two quotes shaped the product more than anything else we heard:
"I open the fridge, see five things, close it, and order Uber Eats. I just can't think about it again." // User interview · UW junior · fall 2025
"If the app makes me feel bad for skipping a day, I'll delete it by Thursday." // User interview · graduate student · recovering from tracking burnout
The first quote gave us the fridge scanner as a target feature. The second killed any idea of a calorie counter — we built the habit flame instead: a streak that rewards showing up and doesn't reset to zero as punishment for a missed day.
By the end of winter quarter we had a working proof-of-concept: the energy check-in and shuffle flow running in React + TypeScript + Vite against a FastAPI backend on Supabase. I presented the MVP at the winter capstone review. The panel feedback was consistent. The concept held up, the energy framing was original, but we needed to label what was real vs. mocked and cut scope if we wanted to ship a real product in spring.
My specific contribution in winter: I wired the React frontend to Siddheshwar's FastAPI endpoints — auth token handling, shuffle fetch, log writes, streak reads. I also designed the API contract between us so both sides could work in parallel without blocking each other.
The call that changed everything: AWS → Swift.
Spring opened with a team decision: move Go Macro from a React PWA on AWS to a native Swift iOS app. Our users live on iPhone, they don't install PWAs, and the camera handling and haptics we want for the fridge scanner are better in native iOS than in a browser wrapper.
The cost of that decision was not small. We had a working React codebase. Switching meant learning a new language and framework while still trying to ship something showcase-ready. The team split: Amanual moved into native iOS components in Figma, I started on the Swift integration layer alongside Siddheshwar (who owned the FastAPI backend), and Alexis held the product plan so we didn't lose the core flow in the rebuild.
Integration was my main work in spring. Every screen in the Swift app talks to the FastAPI backend (auth tokens, recipe fetches, energy log writes, streak calculations). I've been mapping existing endpoints to what Swift URLSession and async/await expect, flagging where the web assumptions break (cookies vs. bearer tokens, form data vs. JSON), and working with Siddheshwar on contract changes the Swift client needs.
The team side of spring has been staying aligned through real chaos. Our weekly standups call out what's blocking explicitly. We've gotten better at saying "that's not shipping before showcase" out loud instead of carrying it silently. Alexis running tight scope reviews is the main reason we're still on track.
One check-in, three side channels.
The core flow hasn't changed across the web and native versions — tap an energy level, the shuffle engine filters the recipe set, render a single card, log or shuffle. What changed is the client: the Swift app hits the same FastAPI backend through native networking with proper iOS auth handling instead of browser fetch.
Three calls worth explaining.
Biggest team call of the project. We had a working React PWA. Moving to Swift meant throwing away code, learning a new framework, and accepting that the spring build would go slower than the winter one. We did it because the camera UX and haptics for the fridge scanner are better on native, and our users don't install PWAs. The better product call was the harder engineering one.
Every food app we looked at starts with goals and grams. Research said the need was less thinking, not more precision. Energy (Low/Med/High) is one tap and filters the recipe space by prep effort and cognitive load, not nutrients. It also sidesteps the calorie-anxiety failure mode Shijie flagged. Go Macro has zero calorie fields anywhere in the product.
A list of options reintroduces the same paralysis we were trying to remove. The shuffle shows exactly one recipe; the user accepts it or taps shuffle. A list view is one line of code away, but we keep resisting shipping it — the constraint is the feature. Showing one option and making it easy to reject is different UX than showing ten options and making the user choose.
Shipping spring 2026.
Go Macro presents at the UW Informatics capstone showcase spring 2026. The winter web MVP proved the concept. Numbers below are from that pilot cohort on the React version. The Swift app is still in build, and it's the one we'll present. I'm not making any claims about nutrition outcomes this early. What I care about right now is whether people come back the next day.
What I learned.
The API contract is a product decision. I spent way too much of winter building React components against a mocked JSON shape I'd invented, then had to rework everything when Siddheshwar's FastAPI endpoint returned something different. Thirty minutes of agreeing on field names, types, and error formats up front would have saved two days of untangling. That conversation is the first thing I do now at the start of any integration work.
Pivoting is a team skill before it's a technical one. Moving to Swift mid-project needed the whole team to agree on what we were giving up and what we were getting. Some of us had sunk cost in the React code. Watching Alexis hold the product vision steady while the engineering foundation changed underneath her, keep scope from exploding, keep morale from collapsing, was worth more to me than any technical thing I picked up this quarter.
Being honest about velocity is harder than being strict about scope. It's easy to say "that's out of scope" when you're planning. It's much harder to say "this thing we scoped is going to take three times as long as we thought" three weeks in. The SMS nudge scheduler still isn't integrated. The fridge scanner lives on a branch. Saying that out loud in standup is a muscle I'm still building.
Integration engineering is its own job. I came in thinking I'd leave with React experience and a frontend resume bullet. I'm leaving with a much clearer picture of what happens at the seam between systems: how auth propagates, how API shapes drive UI decisions, how a client-side assumption can quietly break a backend contract. That's the skill I'll carry into whatever I do next.
Where we go from here.
The immediate work is finishing the Swift integration — getting every screen connected to the FastAPI backend with proper auth, so the app works end-to-end on a real device before showcase. That means bearer token auth replacing the web cookie flow, Swift Codable models mapped to every API response shape, and async/await networking that handles offline gracefully without crashing.
After showcase, the plan is to keep going. The team has talked about a real App Store submission once the native app is stable. That means Apple Developer enrollment, TestFlight beta, and — finally — wiring the Twilio nudges and OpenAI Vision fridge scanner into the Swift app rather than leaving them as web-only features on a branch.
There's also a recipe corpus problem we need to solve: we've been running on ~80 hand-written recipes and shuffle visibly loops on Low energy. A coverage matrix (energy × prep time × skill level) and a basic recipe-authoring tool are the un-glamorous work that makes the app still feel alive in week four. I'm staying on the integration layer through summer 2026.
What I'd do differently.
I'd negotiate the API contract before writing a single component. Building against a mocked response I invented cost real time. Thirty minutes of shared spec work at the start of winter would have paid for itself ten times over.
I'd wire Supabase auth on day one. We spent too long with localStorage demo profiles because "we'll add auth later," and later meant three demos where the habit flame didn't persist across a browser refresh. That's the kind of thing that makes a demo feel broken. There's no good reason to punt auth when Supabase makes it fast.
And I'd push harder to settle the web-vs-native question before winter quarter ended, not halfway through spring. The pivot to Swift was right. The timing wasn't — making it in week five of spring cost us scope we couldn't recover.