Lessons from my capstone project
Two weeks. Three people. One app that needed to work on demo day in front of a room full of people who had opinions about it. That's the capstone project experience in a sentence.
We built a recipe recommendation app — the kind that asks what ingredients you have and suggests what you can make. Simple enough concept. The execution, as always, had other ideas.
Day one was too optimistic
We split up the work cleanly on day one. I'd handle the backend API and database, my teammate would build the front end, the third person would handle the recommendation logic and external API integrations. Clean, parallel, efficient.
By day three, none of us could integrate because we'd made different assumptions about the data shape. My API was returning recipes as an array. The front end was expecting an object keyed by ID. The recommendation engine was outputting ingredient matches as a percentage string instead of a number.
We lost a full day untangling it. A day we didn't have.
Define your API contracts before you write a single line of implementation. A 30-minute schema discussion on day one is worth six hours of debugging on day three.
The API rate limit incident
We were using a food database API for nutritional data and ingredient matching. Free tier. Two thousand requests per day. We didn't read that limit carefully enough.
On day four, we ran the app during a full test run, seeding the database, making test requests, running the recommendation engine. We hit the limit by 11am. The app was broken for the rest of the day. No nutritional data, no ingredient matching, just a very sad empty screen.
The fix was straightforward — add caching, reduce redundant calls, upgrade the plan. But it cost us most of a day and some team morale.
What I learned: always read the rate limits. Then assume you'll hit them anyway and build caching on day one.
The merge conflict that wasn't
On day eight, my teammate and I both made changes to the same configuration file without communicating. The merge conflict was technically small — a few lines. But we spent an hour second-guessing each other's changes, neither of us sure what the "right" version was.
We'd been working in parallel without updating each other on scope changes. After that, we added a ten-minute standup every morning — what are you working on today, does it touch anything I'm touching? Sounds basic. It was transformative.
What actually shipped
The final demo had three features working:
- Search by ingredients — paste in what you have, get recipes back
- Recipe cards with photos, timing, and difficulty
- A simple save/favourites system
That was it. We'd planned for dietary filters, nutritional summaries, a shopping list feature, and meal planning. None of that shipped. None of it needed to.
The demo went well. Not because it was complete — because what it did, it did well, and we could explain every decision clearly.
Final thoughts
A working MVP you can demonstrate beats a half-built feature set every time. The instinct to add one more thing is real and usually wrong when you're up against a deadline.
The three things I carry from that project:
- Define interfaces before you split work
- Read the docs for third-party limits on day one
- Daily standups are not bureaucracy; they're collision prevention
I'd do the whole thing again. Probably with slightly better sleep hygiene.