A Team's Write-Up: What We Tried, What Failed, and What We'd Change

How we started: the idea and the first sketch

When we signed up for the MS Hackathon, we had one goal: build something small enough to finish but bold enough to feel exciting. Our team of four met on a Tuesday evening and filled a whiteboard with three ideas. We picked the one we could explain in a single sentence, a tool that helps event visitors find quiet spaces on a busy campus.

We spent the first two hours sketching screens and arguing about scope. That argument saved us later, because it forced us to cut features before we wrote any code. We agreed on one core flow and wrote it on a sticky note that stayed on the wall for the whole weekend.

What we tried: tools, sprints, and late-night decisions

We divided the work into three tracks: frontend, data, and presentation. Each track had a clear owner, and we checked in every ninety minutes. That rhythm kept us honest about progress and stopped one person from silently falling behind.

Our stack was intentionally boring: a static frontend, a tiny backend, and a spreadsheet as our first database. Boring tools let us move fast, and speed mattered more than elegance during a weekend sprint.

• Write the demo script before writing the demo.
• Keep a shared list of blockers and review it every hour.
• Sleep at least a few hours, even when the clock is loud.

What failed: the bugs and the bad assumptions

Our biggest failure was the map view. We assumed an open map library would work out of the box, but the setup consumed four hours and still looked rough. We abandoned it and used a simple list instead. The list was less impressive, but it actually worked during the demo.

We also underestimated how long testing would take. We tested the happy path and ignored edge cases, so a judge found a broken button within thirty seconds. That moment was painful, but it taught us more than a smooth demo would have.

A working small thing beats a broken big thing, every single time.

What we would change: process and priorities

If we started again, we would lock the demo scenario on day one and build only what that scenario needs. We would also assign one person as the dedicated tester, rotating every few hours so no one got stuck in a single mindset.

We would set a hard cutoff for new features, maybe two hours before the deadline. After that cutoff, the team would only fix bugs and polish the presentation. That rule alone would have saved us from our messiest moment.

What we took away: lessons for the next team

The hackathon ended with a prototype that half worked and a team that fully bonded. We did not win, but we left with a clear sense of what we can build when the pressure is on and the scope is small.

Our advice to the next team is simple: choose a problem you can describe in one breath, protect your demo path, and write down every lesson while it is fresh. The write-up you make afterward is often more valuable than the code you shipped.