[pjreddie]

At my last job I worked at a YC startup where the entire codebase was written in the 3 months leading up to demo day when the team was under a lot of time pressure. Sure it worked fine as a demo, but with the pace of startup land this same code was then thrown into production and as the startup grew the codebase couldn't quite keep up. There weren't many catastrophic failures but there ended up being a lot of patching that had to happen on a daily basis. I would say 80% of my time was spent tracking down weird bugs in the code and trying to figure out what the hell the original authors were thinking when they designed things so poorly.

The point is, you probably will write really bad code if you are under a lot of time pressure. Hackathons seem like they are probably useful for some things like bouncing around ideas and quickly fleshing stuff out but please, for the love of god, if you decide to take your hackathon idea and run with it DELETE ALL OF YOUR CODE. Just do it. Then take some time and think through your overall design because trying to make major modifications when there are paying customers relying on your site every day really sucks.

[shuzchen]

In my experience (at various hackathons, global game jams and startup weekends), the tactic that's given me most success is to be very strict about what features to implement, and to keep any unfamiliar technologies at a minimum. When you only have so much time, don't waste it writing profile settings pages (why even have auth at all? everyone just types in a username and they're logged in as that person now!), don't waste time dealing with any browser compatibility (just program for chrome, or whatever tablet you're going to demo on). There are so many things that I've seen other people mess around with that just wastes your time and energy.

Regarding unfamiliar technologies, choose a stack you're used to (that way, you don't waste time debugging/googling how to do something) and use whatever helps you get things done fast. If anything, have one unknown thing in the mix so you can take advantage of the learning opportunity. Just make sure that thing is necessary for the product you're working on of course - for example, use mongodb's geospatial indexes for that geo-aware app, or try out d3 for those nifty interactive charts, or use websockets/zeromq for a real-time system.