Execution
Time management, tech stack selection, MVP strategy, and team coordination.
The Speed Mindset
Hackathons are time-limited events. Anything that can be sped up, should be sped up. The winning edge comes not from working harder, but from eliminating everything that slows you down.
Here's the big shift: software engineers are transitioning from code creation to code curation. Instead of just writing code, we're now guiding AI tools to build it smarter and faster. At most hackathons, AI generates the boilerplate. From there, you modify and optimize it to fit your project.
Every minute spent on something that doesn't improve the demo is a minute wasted. Cut features, skip polish, and get the core flow working first. Speed comes from subtraction, not addition.
If a feature takes more than 2 hours, question whether it belongs in the demo at all.
AI code editors, generative UI tools, managed services, and pre-built templates are your force multipliers. Use them to generate boilerplate, then focus human effort on what only humans can do: vision, design, and core logic.
The fastest-shipping engineer isn't the fastest typist, but the best curator of tools.
You're not building a production app. You're building a working proof of concept that tells a story in 3 minutes. Every decision should pass one test: “Does this make the demo better?”
Polish the happy path. Ignore the edge cases. Judges will never see them.
Parkinson's Law
“Work expands so as to fill the time available for its completion.”
— Cyril Northcote Parkinson, 1955. The tighter the deadline, the more focused the output. Use timeboxing to create artificial urgency within the hackathon itself.
The AI-Powered Workflow
I don't write all my code at hackathons. AI generates the boilerplate. I modify and optimize it to fit the project. Here are the three tools that have massively boosted the workflow.
- Context-aware code generation that far outperforms GitHub Copilot because it indexes the whole project
- Inline edits with Command+K, letting you refine your code rather than generating from scratch
- Multi-line cursor predictions that understand your intent
Edit, don't create
from code creation to code curation
- Generates full React components from natural language descriptions
- Outputs npm-installable components you can drop directly into your project
- Already uses Next.js, shadcn, and Tailwind, so zero translation is needed
Instant UI
describe it, install it, ship it
- Live code previews in an easy-to-navigate tab that show results instantly
- A game changer for debugging and understanding teammates' code mid-hackathon
- Full interaction history so you can retrace your steps
Tens of hours
saved at each hackathon
Andrej Karpathy
“The hottest new programming language is English.”
Thomas Dohmke
“AI coding is here to stay. It's a new way for developers to express their creativity.”
Why This Works — The Science of Constrained Execution
The best hackathon teams go beyond moving fast. They follow principles refined by decades of engineering and entrepreneurship research.
“Make it work, make it right, make it fast.”
The creator of Extreme Programming laid out the order that matters. First get the flow working end-to-end, no matter how ugly it looks. Then refactor only what's needed for the demo. Most teams never get past step one in 24 hours, and that's completely fine.
“If you aren't embarrassed by the first version of your product, you shipped too late.”
The LinkedIn co-founder didn't mean “cut corners recklessly.” He meant: ship quickly so you can test assumptions and learn. If your hackathon demo feels polished, you likely spent too long building and not enough time refining the story.
“80% of consequences come from 20% of causes.”
Vilfredo Pareto's observation applies perfectly to hackathons: 80% of your demo's impact comes from 20% of its features. One sharp “pointy feature” that solves one problem very well beats a broad platform with ten half-built features.
Adapted from SpaceX engineering, to be applied in this order:
- 1Make requirements less dumb — Question everything, especially from 'smart' people
- 2Delete the part or process — If you're not adding things back, you're not cutting enough
- 3Simplify or optimize — Only after deleting, since you shouldn't optimize what shouldn't exist
- 4Accelerate cycle time — Speed up only after simplification
- 5Automate — Automate last, and never automate a broken process
Scope Hammering
Fixed time, variable scope. Instead of extending the hackathon, you cut features until what's left fits. This is the discipline that separates shipping teams from unfinished messes.
Ryan Singer's Shape Up methodology from Basecamp defines scope hammering as “forcefully questioning a design, implementation, or use case to cut scope and finish inside the fixed time box.” In a hackathon, time is the one thing you can't negotiate. Scope is what you cut.
- One core user flow that works end to end
- One killer demo moment that shows the vision
- Polished UI on the happy path, because first impressions matter
- The 20% of features that carry 80% of the impact
Ship this
the core that tells the story
cut here
cut here
- Auth and login flows, since you can just hardcode a user and skip signup
- Admin panels, settings pages, user profiles
- Edge cases, error handling, input validation
- Database migrations, multiple user types, permissions
Kill this
it won't change the outcome
Sheryl Sandberg / Facebook
“Done is better than perfect.”
Jason Fried / Getting Real
“Build less. Underdo your competition. Fewer features, fewer options, fewer meetings, fewer promises.”
The Hackathon Timeline
A battle-tested breakdown of how to allocate 24 hours. Adapt the ratios for 36- or 48-hour events, but keep the structure.
Ideation and Architecture
Hour 0-2Finalize the idea, assign roles, sketch the architecture on a whiteboard, and set up the repo with a boilerplate. Deploy to staging immediately so you can demo 'hello world' within the first hour.
Core Pipeline
Hour 2-4Get the end-to-end flow working. Ugly is fine. Hardcode values, skip error handling, wire everything together with duct tape. The goal: prove the concept works before investing more time.
Build Sprint
Hour 4-16Heads-down feature work in timeboxed 2-3 hour blocks. Checkpoint after each block: 'Can we demo right now?' If a feature is taking too long, cut it. Sleep in shifts if you can, because exhaustion kills productivity faster than lost hours.
Integration and Polish
Hour 16-20Connect all the pieces. Fix critical bugs only. Polish the happy path UI, since this is what judges will see. Don't start new features. If it's not working by hour 16, it's not going to work.
Demo Prep
Hour 20-22Record the demo video. Build the pitch deck. Prep appendix slides for Q&A. This is not optional and is actually the highest-ROI activity of the entire hackathon. A polished pitch with a working demo beats a perfect codebase with a bad presentation.
Rehearse and Submit
Hour 22-24Practice the pitch 3+ times. Time it. Submit all deliverables early, including Devpost, video, and repo. Don't make changes after submission. Use remaining time to rest and prepare mentally for judging.
Timeboxing is ranked by Harvard Business Review as one of the most effective productivity techniques. Assign fixed time blocks and stop when time is up, regardless of completion.
Brooks's Law tells us that “adding manpower to a late software project makes it later.” When you're behind, resist adding scope or people. Cut features instead.
The Leverage Toolkit
Tools and techniques that multiply your output without multiplying your hours. Focus human effort on what only humans can do.
Boilerplate Repos
Pre-built starters (Next.js, Flask, Express) so you skip the first 2 hours of setup. Have your go-to stack ready before the hackathon starts.
Component Libraries
Use shadcn/ui, Radix, or Material UI instead of building UI primitives from scratch. Import, customize, ship. The fastest code is code you didn't write.
Deployment Pipeline
Vercel or Netlify one-click deploy. Set up CI in the first hour so you can always demo a live URL. Never rely on localhost for judging.
API-First Approach
Use managed services like Supabase, Firebase, and Auth0 instead of building infrastructure. Let someone else handle auth, storage, and databases.
Version Control Discipline
Commit often, branch per feature, never break main. A broken main branch at hour 20 is a hackathon-ending disaster.
Communication Shortcuts
Shared Figma for design, quick standups every 2-3 hours, one Slack/Discord channel. Over-communication beats under-communication at 3AM.
Naval Ravikant — AngelList Co-founder
“Code and media are permissionless leverage. They're the leverage behind the newly rich. You can create software and media that works for you while you sleep.”
Use leverage: templates, AI, APIs, no-code where it fits. Reserve human effort for what only humans can do, like vision, design, and high-impact decisions.
“Make it work.
Make it right.
Make it fast.”
— Kent Beck, creator of Extreme Programming
In a 24-48 hour sprint, most teams never get past “make it work.” That's perfectly fine. A working demo that tells a clear story beats a half-finished masterpiece every time. Winning teams don't have the cleanest code. They're the ones who shipped something that works and told a compelling story about it.
The role of a hackathon engineer is evolving. Your contributions are no longer measured by lines of code written, but by the quality of the experience you deliver. Use every tool, template, and AI assistant at your disposal. Curate, don't create from scratch. Ship, then polish.
The fastest path to first place is the shortest path to a working demo.
Execution Checklist
A step-by-step summary for shipping under extreme time pressure. Follow this and you'll never be the team scrambling at the last minute.
Set up repo, boilerplate, and deploy pipeline in the first hour, because you should never demo from localhost
Get end-to-end flow working before adding any features. Ugly is fine, but broken is not
Timebox every task, and if it takes more than 2 hours, cut scope or switch approach
Use AI tools for boilerplate so you can focus human effort on core logic, design, and integration
Checkpoint every 2-3 hours: "Can we demo right now?" If not, fix that before building more
Stop building 4 hours before submission and use that time to polish UI, record your demo video, and rehearse your pitch
"Done is better than perfect." Ship what works, cut what doesn't, and tell the story of what it could become
Remember: The real goal isn't building the best software. It's delivering the best demo. Every minute should serve that outcome. Build less, leverage more, and always be ready to show what you've got.