The prototype worked. The pipeline held. The demo video was too long. This is the field note.
---
What I Was Trying to Do
Run a four-person team through the Lovable x OpenAI Build-a-thon — Track 1: Patient Journey Automation — and ship a working healthcare AI prototype in four hours.
The real experiment was not the product. It was the team workflow: could four people with different tools, different strengths, and different locations coordinate well enough to build something demoable under extreme time pressure?
T → Codex, backend, AI pipeline F → energy, support, momentum, strategy D → business , commercial grounding V → user journey, UI/UX, product direction
---
Starting State
We had a week of prep before hack day. By the night before:
CareVault concept → scoped down to Tenang (pre-consult AI companion) Lovable-GitHub-Codex → pipeline tested by Tristan, working Document extraction → OpenAI extraction + summary functional Synthetic test data → five medical reports generated via ChatGPT UI/UX direction → designed via Stitch, exportable to Lovable BRD and PRD → drafted, providing scope anchor
What was not confirmed: whether Lovable Cloud's managed Supabase would play nicely with Codex. That gap cost us time.
---
What Actually Happened
The Pivot That Saved Us
We started the prep week with CareVault — Tristan's original concept for a patient-owned healthcare vault. Powerful, but too much infrastructure for a four-hour build.
The turning point was a question: *What is the most painful moment in a patient's healthcare journey?*
The answer — confusion between receiving a report and seeing a doctor — became Tenang. That pivot happened during prep, not on hack day. By the time we sat down at the event, everyone knew exactly what we were building.
The lesson: scope decisions made before the clock starts are worth ten times more than scope decisions made during.
The Tool Pipeline
The Lovable-to-GitHub-to-Codex flow was the backbone.
Lovable handled rapid scaffolding — UI components, Supabase integration, basic routing. T then pushed the Lovable project to a shared GitHub repo. From there, he layered backend logic and AI synthesis via Codex. Changes pushed to GitHub were picked up by Lovable automatically.
This split worked well in practice. I could preview the frontend in Lovable without running a local dev server. Tristan could work in Codex without touching the UI. Dino could review the app live while scraping the provider directory.
One friction point: Lovable Cloud bundles a managed Supabase instance. If you use Lovable Cloud, you don't get direct access to the Supabase project. That makes it hard for Codex to interact with custom database functions. Tristan flagged this the night before, saving us from discovering it mid-hackathon.
The Marathon Factor
F ran a full marathon that morning.Then came straight to the hackathon. No complaints, no excuses — just sat down and started contributing.
That kind of commitment changes the energy in a room. When someone has already run and is still showing up, nobody else gets to say they're tired.
The Demo Gap
Our prototype was functional. Document upload, AI extraction, patient explanation, doctor brief, booking flow, share link, dashboard, follow-up survey — all working.
But the submission required a one-minute demo video. One minute. We had built eight features and needed to show the most compelling three. We didn't ruthlessly edit the demo, and the video tried to show too much.
That was the miss. In a hackathon, the demo is the product. The judges don't see your codebase. They see your video.
---
What Broke
Lovable Cloud + Codex → managed Supabase limits external tool access.
Caught during prep, not during the event.
Demo video timing → tried to show too many features in 60 seconds.
Should have shown three features well,
not eight features fast.
Feature prioritisation → insurance coverage hints and identity checks
were technically impressive but impossible
to demo quickly.Nothing catastrophic broke. But the gap between "working prototype" and "winning demo" is where we lost.
---
What Worked
Prep week investment → pipeline testing, synthetic data, prompt refinement.
Made the four hours productive, not chaotic.
Clear role split → Tristan on backend/AI, Victor on UX/journey,
Dino on business grounding, Firuz on energy.
No stepping on each other.
Scope anchor → the BRD and PRD gave us a fast "is this in MVP?"
filter when feature creep tried to sneak in.
Pivot timing → CareVault to Tenang happened during prep,
not under pressure.---
Lessons
The hackathon starts the week before. Pipeline dry runs, synthetic test data, scope decisions, role clarity — all of that should be settled before the clock starts. The four hours are for building, not for figuring out how to build.
Demo is king. A working feature nobody sees scores zero points. Fewer features, shown well, beats more features shown fast. Next time: script the demo before building the last feature.
Tool integration has boundaries. Lovable + Codex + Supabase is a powerful stack, but the managed Supabase in Lovable Cloud creates friction for external tools. Know the boundaries before the event.
Energy is a contribution. F didn't write the most code. He brought the most commitment. After kilometres, he showed up and kept the team moving. That matters more than it gets credited for.
Business grounding prevents over-engineering. Di commercial lens — "Would a real patient care about this? Would a real doctor open this?" — was the filter that kept us from building impressive features nobody would use.
---
If You're Running a Hackathon Team
[ ] Settle scope before hack day — pivot during prep, not under pressure [ ] Test your tool pipeline end-to-end the night before [ ] Assign clear roles — backend, UX, business, energy [ ] Generate synthetic test data in advance [ ] Script the demo before building the last feature [ ] Know your submission format and time limit — build for it [ ] If using Lovable Cloud, check Supabase access for external tools
---
*All views are my own. This field note is shared for learning and experimentation.*