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 isn't working harder — it's eliminating everything that slows you down.
Here's the big shift: software engineers are transitioning from code creation to code curation. We're no longer just writing code — we're 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 engineer who ships fastest isn't the fastest typist — they're 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 — far better than GitHub Copilot because it indexes the whole project
- Inline edits with Command+K — editing 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 — zero translation needed
Instant UI
describe it, install it, ship it
- Live code previews in an easy-to-navigate tab — see 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.”
Former Tesla AI lead, OpenAI founding member
Thomas Dohmke
“AI coding is here to stay. It's a new way for developers to express their creativity.”
CEO of GitHub
Why This Works — The Science of Constrained Execution
The best hackathon teams don't just move 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 — even if it's ugly. Then refactor only what's needed for the demo. In 24 hours, most teams never get past step one — and that's fine.
— Kent Beck, creator of XP and TDD
“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.
— Reid Hoffman, co-founder of LinkedIn
“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.
— Vilfredo Pareto, 1906 / Joseph Juran
From SpaceX engineering — applied in 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 — don't optimize what shouldn't exist
- 4Accelerate cycle time — Speed up only after simplification
- 5Automate — Automate last — never automate a broken process
— Elon Musk, SpaceX Starbase
Scope Hammering
Fixed time, variable scope. You don't extend 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 — end to end, fully working
- One killer demo moment that shows the vision
- Polished UI on the happy path — 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 — hardcode a user, skip the 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 — you should be able to 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 — 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 — 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 — it's 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 — Devpost, video, repo. Don't make changes after submission. Use remaining time to rest and prepare mentally for judging.
Timeboxing — Harvard Business Review ranks it among the most effective productivity techniques. Assign fixed time blocks and stop when time is up, regardless of completion.
Brooks's Law — “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
shadcn/ui, Radix, Material UI — don't build 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 — Supabase, Firebase, 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. Focus human effort on what only humans can do — 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” — and that's perfectly fine. A working demo that tells a clear story beats a half-finished masterpiece every time. The teams that win aren't the ones with 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. You're no longer measured by lines of code written — you're measured 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 — never demo from localhost
Get end-to-end flow working before adding any features — ugly is fine, broken is not
Timebox every task — if it takes more than 2 hours, cut scope or switch approach
Use AI tools for boilerplate — 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 — polish UI, record demo video, rehearse pitch
"Done is better than perfect" — ship what works, cut what doesn't, tell the story of what it could become
Remember: The goal isn't to build the best software — it's to deliver the best demo. Every minute should serve that outcome. Build less, leverage more, and always be ready to show what you've got.