What to build in a hackathon: one screen, one action, one story.
Build one thing a person already does by hand, on one screen, with the data kept on the phone. That is what to build in a hackathon, and it is a scope decision rather than a matter of taste. The build window inside an event is a few hours, not the number printed on the invitation. Across the hackathons we run, 35 events for 1,462 people in 24 countries and online, the scope that actually gets finished has looked the same every time: one screen, one action, and data that is still there when the app is reopened.
This page is about choosing, not building. It starts with the real clock, taken from the published agenda of one of our own events. Then the two readers this question splits into, because one wants to win the room and the other wants a first version to keep. Then the idea shapes that survive three build hours, the four things that eat them, and what Apple asks if you decide to publish the thing afterwards.
See what is left for the ideaThe short version
Pick the idea that fits the build hours, then build the demo path first and the rest after.
What to make at a hackathon depends on why you are there, and the split is clean. If you came for the judging, choose the narrowest idea with a payoff someone can see from the back of the room. A small thing that works presents better than a large thing that half works. If you came to start something, choose a problem you personally have, because that is the only kind of project that is still open the following week.
Both readers get the same filter at the front. Anything needing accounts, a second device, a payment, or an API you have never called spends hours you do not have. And the uncomfortable half, said plainly: most hackathon projects are never opened again after the event. Nobody has a real number for that, ours included, so take it as what the room looks like rather than as a measurement. It points the same way regardless: the ones that survive are the small ones.
The real build window is about three hours
Take the shape of the day from an agenda rather than from the poster. We ran a hackathon with CPH Vibe Coders at Zoku in Copenhagen, around twenty people in the room. The published agenda: noon to 12:30 for kickoff and team forming, 12:30 to 13:00 for the ideation sprint, 13:00 to 16:00 to build, then 16:00 to 17:30 for demos and awards. The invitation said five hours. The agenda ran slightly past that, and three of those hours were building.
That ratio is what you plan against, and it holds at longer events instead of disappearing. A day long event does not hand you 24 build hours. It hands you what is left after teams form, food arrives, people sleep and somebody rehearses the pitch. If you want the arithmetic worked through at that length, what you can build in 24 hours does it. For choosing an idea the consequence is narrow: the idea has to be finishable in a single afternoon of work, by people who have not worked together before.
Three build hours buys one screen, one action, and data that persists between launches. It does not buy a sign-in screen, two devices talking to each other, or a payment. One more thing worth saying, since we are the ones running these events: we keep no public record of what teams built, so this page has no winning projects to wave at you. The shape of the day is the part we can show you, and it is also the part that decides the idea.
Two readers ask this, and the answers differ
Search for hackathon app ideas and you get lists of twenty, none of which know your clock, your team or why you came. So start with why you came. If the day ends in judging, optimise for legibility. Someone watches for three minutes, in a noisy room, on a screen they are not holding. So the idea needs one path, one obvious payoff and no setup. A list app with one clever ranking rule presents better than a marketplace with two empty sides. Originality is worth less here than it feels: a familiar idea taken to a finish is easier to score than a novel one that needs two minutes of explaining before anything moves.
If you came to start something, invert the filter. Pick the problem you have had for months and currently solve with a note or a spreadsheet. You become the first user, which is the only reliable reason anyone opens the project again after the room empties. Treat the event as the first afternoon of MVP app development rather than as a contest, and cut by the same rule: one job, one kind of data, no accounts.
Both answers shrink the same way once you put minutes on them. Tick what your idea needs below. Each of those things has a cost, and it comes out of the same window as the idea itself. The minute figures are our estimates for a small team in a room, not measurements. The pattern is the point: two constraints and the idea has no time left at all.
Try it
What is left for the idea
Set the build window from your agenda, then tick what the idea actually needs. Everything ticked comes out of the same minutes as the idea.
120 minutes left for the idea
Room for the idea itself, and a second screen if it needs one. That is 180 build minutes, less 40 to get a project running on a device, less 20 to rehearse the demo, less 0 for what you ticked. The minute figures are our estimates for a small team in a room, not measurements, so replace them with your own once you have them.
The four things that eat a hackathon build
Sign-in is the first one. An account screen drags in a server, a session, a reset path and an error state for every call. It is a normal week of work squeezed into an afternoon, and it adds nothing anyone watching can see. Nobody has ever scored a project higher for having a login screen.
Shared data is the second. If two people must see the same thing, you need a server, two devices, and a demo where both of them behave at once on borrowed wifi. The third is money: taking a payment inside a phone app means the store's own purchase flow, which is a submission and a review, not an afternoon. The fourth is anything you have never used before: an API, a device capability behind a permission prompt, or a model you have not tried on your own data. One unknown is a fair bet. Two is how teams reach 16:00 with nothing that runs.
There is a quieter fifth: the group deciding what to build. The Copenhagen agenda gave that thirty minutes and then closed it, which is the right instinct. Write the idea in one sentence, name who opens the app and what they tap, and start. A team still arguing at the ninety minute mark has already chosen to present a screenshot.
What the demo needs, and what happens to it after
Build the demo path first, not last. Decide the three sentences you will say, then build only what those sentences need, in the order you will say them. It sounds like ceremony on a five hour clock. It is the one habit that reliably ends the day with something that runs, because every cut after it decides itself. Seed the screens with data that looks real too, since an empty list on a projector reads as broken rather than as new.
In the last hour, polish is worth more than a feature. Even spacing, one accent colour, real words instead of placeholder text. That is a job small enough to fit, and it changes how finished the thing looks, which is most of what people in the room are actually reacting to. If that is where your last hour goes, making it demo well is the version of this with the layout detail in it.
Then Monday arrives. If you want the project in the App Store, treat that as separate work, and know that the rules are about the app rather than about how it was written. Apple's guideline 4.2 asks for features, content and UI that elevate an app beyond a repackaged website, and says an app that is not particularly useful, unique or app-like does not belong on the store. Guideline 4.2.6 reads: "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content." Nothing in the guidelines cares whether a person or a model typed the code. A three hour demo is usually not a 4.2 app yet, and that is fine, because it was not built to be one.
Apple, App Store Review Guidelines, 4.2 Minimum Functionality
Five idea shapes and what each one costs you on the day
| Idea shape | Shows in three minutes | Needs accounts or a server | The part that can fail on the day | Still useful on Monday |
|---|---|---|---|---|
| A logger for one thing you track by hand | Yes | No | nothing outside the phone | Yes |
| A decider: a few inputs, one clear answer | Yes | No | agreeing the rules | Yes |
| One camera or sensor trick, saved locally | Yes | No | a permission prompt on a borrowed phone | as a demo, rarely as a product |
| A wrapper on one API you have called before | Yes | a key, not accounts | the wifi in the room | while the API stays free |
| Two sided, live shared, or paid | No | Yes | both devices, at once, on stage | nothing finished to keep |
Building it inside the three hours
The gap between choosing an idea and seeing it on a screen is where the afternoon disappears. Close it by starting from a project that already runs: a screen, navigation, a list, and somewhere to keep local data. If someone is still typing that from scratch at 13:10, the idea has lost an hour it will not get back.
Newly is an AI app builder, and the part that matters on this clock is the first twenty minutes. You describe the app in plain English and it writes a real React Native and TypeScript project you own. It runs on cloud iOS and Android simulators while it builds, and ships to TestFlight and to Google Play internal testing when you want it on a real phone. It is $25 a month and there is no free plan.
New apps start local-first, which happens to be the correct hackathon default: data sits on the phone, with no accounts and no server. Newly Backend is added only when the app needs sign-in, shared data, syncing or payments, and on a three hour clock the honest advice is not to ask for it. The code is yours either way, as a ZIP from project Settings or through the two-way GitHub sync under Deploy. What you carry out of the room is a normal codebase rather than a slide.
Questions people ask before picking a hackathon project
One screen that does one job for one kind of person, with the data stored on the phone. Pick something people currently do by hand in a note or a spreadsheet. That fits the build hours you really get, it presents as a single path, and it is the shape that routinely gets finished. Anything with accounts, two devices or a payment is a different project on a different clock.
Write the one sentence, then start the clock
Name who opens the app, what they tap, and what they get, in one sentence. Build only what that sentence needs, keep the data on the phone, and stop building when the demo block starts.
Start building