I naturally lean toward absolutely silly ideas (parallel universe generator, shower thought NFT minter, that kind of thing) and I expect everyone to get on board. I often forget that not everyone shares my sense of humor.
So I wasn't super stoked about an app to help doctors take and summarize notes… but I couldn't deny how practical the idea was. And that's what we ended up shipping. Here's the full inventory of the day: the one we shipped, the one I built on the side, the one we wisely abandoned, and the one I should have pitched. Each taught me something different about building under constraint.
First: Lovable has limits (and they're instructive)
Lovable didn't let us collaborate on one product during the hackathon. No pro features for us hackers. In hindsight it worked out: one person per app meant fewer sync issues and fewer chances to break the prompt chain. The system gets confused if you prompt it too much, and sometimes starting from scratch was faster than debugging.
That last sentence is worth dwelling on, because it inverts a deep software instinct. With traditional code, you debug; throwing everything away is the expensive last resort. With prompt-driven building, the accumulated conversation is the codebase, and it degrades. A fresh start with a better-specified prompt often beats surgery on a confused one. The practical implication for anyone using these tools:
Which is, if you squint, just requirements gathering with the feedback loop compressed from months to minutes. The PM skill and the prompting skill turn out to be the same skill: knowing the whole shape of what you want before you start asking for it.
The one we shipped: an AI assistant for doctors
A working MVP that helps doctors take and summarize notes during patient visits. My friend prompt-coded everything. The only time we left the app was to connect Supabase. Schema creation, the API hook to LLaMA, all through natural-language coding. Not only were the people we showed it to impressed. We were impressed.
With more time and a bit of budget, we'd have added voice note-taking and handwritten-note recognition (we were getting rate-limited on high-load tasks). Fun bonus: my teammate injected prompts that made the assistant write a rap song about a patient's health.
The uncomfortable observation: the idea I was least excited about was the one that shipped, demoed well, and impressed people. Practical beats clever under a deadline, every time. I know this professionally — it's half of what product prioritization is — and I still needed the hackathon to make me feel it.
The one I built on the side
While coding the doctor assistant, I also built a baby version of Momentum, a micro-task generator for when you feel overwhelmed. It acts like your slightly snarky best friend and walks you through simple next steps to unblock yourself. It wasn't a technical feat yet, but it was genuinely helpful. And that's a good place to start.
This is the quiet argument for hackathons that nobody puts on the poster: the sanctioned project keeps your hands busy, and the side project you sneak in tells you what you actually care about. The doctor's assistant was the assignment. Momentum was the tell. It has since grown into a full app with three modes and selectable personalities — the whole story is in the case study — and it started here, in the gaps between someone else's build.
The one we abandoned: "Guess Who Said That"
A multiplayer guessing game for team-building. My teammate had already built a rough version, and I loved the concept. Very on-brand with my chaotic energy. But user sessions, auth, anonymizing player input, then revealing identities? Technically doable, not in the time we had. Right call.
Killing it was the most PM moment of the day. Loving an idea and shipping an idea are different verbs, and the discipline is knowing which one you're doing. We scoped the risk (multiplayer state is a time sink), checked it against the clock, and walked away before it cost us the project that could actually ship. I've watched teams at real companies take quarters to make the decision we made in ten minutes. The hackathon just makes the trade-off honest, because the deadline is real and nobody is pretending otherwise.
The one I should have pitched: pantry photo → recipe generator
The secret theme of the hackathon was "multimodal," and my magnum opus (scan your pantry, identify ingredients, generate a week of recipes within your constraints — diet, macros, exclusions, cuisine, household size) was perfect for it. But food is deceptively hard: image recognition, data validation, recipe logic, planning constraints. I'd spent days forcing myself to "just ship something," and in doing so, forgot to pitch the big one.
I'd talked myself out of my best idea before anyone else got the chance to. That's the failure mode nobody warns you about when they tell you to "lower the bar and just ship": the bar-lowering muscle doesn't know when to stop. It flattened my idea quality along with my execution anxiety.
The fix is preparation, not bravado. Walk in with a ranked list of ideas and a rough shipping path for each, so that ambition and feasibility get negotiated before the adrenaline starts, not during. That's the version of me showing up to the next one. With the pantry app. And possibly the parallel universe generator, if the vibes are right.