From zero to meal logging in 72 hours

Every side project starts with the same lie: "I'll just set up the basics this weekend."

On December 3rd, 2025, I ran my first commit on what would eventually become WhispCal. Three days later, I had a working meal logger with nutrition modals, quick logging, and a pantry overlay. Looking back at those early commits, I'm somewhere between proud and horrified.

Day one: the blank canvas

The first commit was just scaffolding — Expo, TypeScript, file-based routing. Nothing exciting. But by the end of that same day I had an onboarding flow and a date picker modal. There's something intoxicating about a greenfield project. No legacy code. No "we've always done it this way." Just you and a blank screen.

I made a deliberate choice early on: ship ugly, ship fast. The goal wasn't a polished product — it was a working prototype I could put on my own phone and use for actual meals. If I couldn't log my own lunch with it by Friday, I'd failed.

Day two: the core loop

December 5th was the most productive day of the entire project. I pushed the overview page, a date modal, and wired up the basic navigation. The commit messages tell the story — "wip - more components and overview page" isn't exactly poetry, but it's honest.

By evening I had the skeleton of the app: a home screen showing your day's meals, a way to navigate between dates, and the beginning of a component library. The "DuoSelect" modal I built that day survived (in spirit) all the way to the current version, though it's been refactored at least four times since.

Day three: it actually works

On December 6th, the log meal screen came together. I could tap a meal type — breakfast, lunch, dinner, snack — and start adding food items. The nutrition modal showed calories, protein, carbs, and fat. It was ugly. The layout was wrong. The numbers were hardcoded in places they shouldn't have been.

But I logged my actual dinner with it that night.

There's a specific feeling when your own app does something useful for the first time. It's not the "hello world" satisfaction. It's closer to the moment a bicycle stays upright — suddenly this pile of code has momentum, and you realize you're actually going to build this thing.

What I learned from the sprint

Looking back, those 72 hours taught me a few things that carried through the rest of the project:

• Prototype for yourself first. I didn't build for hypothetical users. I built for tonight's dinner. That kept every decision grounded.
• Commit messages don't matter yet. Half my early commits say "wip" or "tryout." That's fine. When you're exploring, documentation is friction.
• The core loop is everything. If the basic action — logging a meal — doesn't feel right, nothing else matters. I spent most of my time on that flow, not on settings screens or profile pages.
• Expo is absurdly fast for prototyping. Going from zero to a running app on my phone in minutes still feels like cheating compared to native development.

The prototype was rough. But it existed. And that's the hardest part of any side project — making it real before the motivation fades.