"Building static HTML pages" is not always inappropriate for a hackathon. For most college-level demos, a mostly-static demo with just enough javascript to pull

"Building static HTML pages" is not always inappropriate for a hackathon. For most college-level demos, a mostly-static demo with just enough javascript to pull data to make it feel fresh is a "hack" that will get you further than your peers. Depending on your level of ethics, some companies will actually do demos that are this level of wire-and-duct-tape to sell the product, and then build it afterwards. The one big catch with this approach is that you can't pitch something that's non-trivial technically -- if you do, and can't demonstrate you figured out the secret sauce, then your pitch becomes worthless. Many first-timers will walk into a hackathon with just their laptop, and get stuck in the trap of setting up their environment over the whole weekend. They'll spend hours trying to download an IDE and interpreter/compiler and libraries over a poor or nonexistent internet connection. For these people, "build some static web pages" is one of the easiest ways to get them to the point where they have something they can comfortably demo in front of their peers -- and so what if it doesn't really work; they had fun and can come back next time. If you build a thing that really works, fine. But a lot of people also walk into hackathons with pre-formed teams and 80% completed projects (idea, mocks and artwork already done; IDEs already set up; maybe even hardware already wired up) and having an emphasis on "real working code" for a time-constrained event only encourages this sort of "cheating".