Research, pivots, punts: the Go Macro capstone journey

Go Macro is the UW Informatics capstone I've been working on with four teammates (full case study here). This post isn't about the product. It's about how we kept changing our minds.

Where we started: a calorie tracker

The pitch was what you'd expect from five seniors who eat like college students. "Young adults don't track their nutrition, we'll build an app that makes tracking easier." We had wireframes. We had a data model. We had a roadmap for a premium tier, which is the part I'd like to pretend didn't happen.

Then Shijie, our product researcher, ran the first round of interviews. Nine people, ages 19 to 24, a range of relationships with food. They all said some version of the same sentence: "I don't want another app telling me what I ate was bad."

Pivot 1 — from tracking to encouragement

We reframed. Instead of a tracker, a positive-reinforcement tool. Streaks instead of shame. Show up, get the flame. Data model mostly the same, UI warmer.

Round two of interviews ran two weeks later. The feedback was less angry but just as blunt: "I don't need encouragement. I need to just pick something." Two interviewees were dealing with active menu anxiety, the kind where you open DoorDash, see 40 options, and close the app. Friendly encouragement was still friction for them.

"I don't need macros. I need someone to just hand me a plate." — user interview #14, Feb 2026

That quote flipped the whole project.

Pivot 2 — from encouragement to decision removal

We threw out the wireframes. All of them. Siddheshwar (backend) and I (frontend) sat in the iSchool lobby for four hours arguing about what we were even building. The answer we landed on: the product isn't about food. It's about not having to decide about food.

So the core loop flipped:

• User opens the app.
• App asks one question: how much energy do you have?
• App shows one meal that matches.
• User can shuffle if they hate it.
• Done.

No barcode scanning. No photographing meals. No portion entries. Nothing that feels like homework. The painful part was deleting features we'd already half-built. Writing code is easy; pulling it back out is the hard part of the job nobody warns you about.

Pivot 3 — the fridge scanner

This one was smaller. Round three surfaced a pattern we'd missed: plenty of our users had food at home but didn't know what to make with it. We'd been so zoomed in on "what should I order" that we skipped "what's in my fridge and can I cook it."

So we added OpenAI Vision. Point your phone at the fridge, the model reads the ingredients (once called a lemon "a tennis ball"), and the shuffle engine pulls recipes that use what's there. It's the feature that tests best in the current prototype.

What the capstone taught me about building software

// Research is not a phase

We treated research as a block at the start of the project. Interviews, then build, then ship. That's backwards. Interviews should run on a cadence for the entire project. Every round we did changed what we built.

// The best quotes are the ones that kill your roadmap

The quotes you pull for a pitch deck aren't the ones that matter. The useful quote is the one that makes you put your coffee down. Interview #14 was ours.

// Deletion is the hardest skill

Writing features is easy. Cutting the ones you've already written is where it gets hard. We cut barcode scanning, macro tracking, weekly reports, and a social feed. Every cut stung. Every cut was right.

// Teams argue better when the disagreement is about the user

The four-hour lobby argument wasn't React vs. Svelte or FastAPI vs. Node. It was whether the user wanted X or Y. Anchoring disagreements to the person you're building for (instead of to what the builders want to build) tends to resolve them faster.

What's next

Spring 2026 launch. Small cohort beta first. Still learning.

If you're working on a research-driven capstone or hit your own "oh" moment mid-project, I'd like to hear about it.