What can you build in 24 hours: one feature that works, on a real phone.
So, what can you build in 24 hours? One feature, for one kind of person, with its data on the phone and no sign-in screen, running on a real device by the time you stop. Not a product, not two sides of a marketplace, not accounts. The number that sets your scope is not the 24 on the poster. It is the uninterrupted build hours inside it, which is eight to twelve if the day is run well and three if it is not. If the point of the day is a first version you keep rather than a demo you delete, treat it as MVP app development on a very short clock, because the cutting rules are the same and only the clock changed.
Below is the arithmetic on a 24 hour app build, what fits in three build hours against ten, how to get the thing onto somebody else's phone before the day ends, and the two things no amount of speed buys you: an App Store listing and a Google Play production release.
Work out your real build hoursThe short version
Scope to the build hours you have, not the hours on the invite.
Two kinds of reader ask this, and the honest answer splits between them. If someone is judging you at the end of the day, the deliverable is a two minute demo, so build the screen the judges see and fake what sits behind it. If you want a first version you still open next week, the deliverable is an installable app in somebody else's hands, and that costs two or three hours before you write a line of feature code.
Both readers make the same cut. One job, one user, one screen that matters, data kept on the device. Accounts, payments, a server and a second type of user are each hours you do not have. They are where these projects die, with four screens half built and nothing to show.
The 24 hours on the poster is not 24 build hours
Start by subtracting. Sleep and food take five or six hours out of an overnight event. Forming a team and arguing about the idea takes one to three, and it is the most common place to lose the day. Setup takes an hour if you have done it before and three if you have not. Demo prep, the recording and the judging take about two. A solo builder at a well run 24 hour event ends up with eight to twelve hours of actual building, and a team of four gets the same wall clock and spends part of it talking to each other.
The shortest event we have run is a useful calibration, because the ratio holds at every length. Around twenty people came to a hackathon we ran with CPH Vibe Coders at Zoku in Copenhagen: five hours on the clock, and the published agenda gave building three of them. Thirty minutes to kick off and form teams, thirty to settle on an idea, three hours to build, then demos and awards. Three build hours is one screen, one action and data that persists. Everything past that tends to arrive half done.
So plan in three hour blocks rather than in hours. Block one gets the app running on a device with fake data in it. Block two makes the data real and makes it survive a restart. Block three is the part you show, which is usually one screen you make look deliberate. If a block slips, the next block goes, not the demo. Anyone who leaves the demo to the final block ends up showing a simulator and talking over it.
Try it
Hours that are actually build hours
Take out the parts of the event that are not building, then read the scope that fits what is left.
13 build hours, not 24
That is 54 percent of the event. Two or three screens, one device feature, and time to put it on a phone that is not yours. Sign-in with a server behind it: out of scope today.
What fits in three build hours, and what needs ten
Three hours: one screen, one action, and something saved that survives a restart. A timer that records sessions and lists them. A checklist for a job nobody has written a checklist for. A scanner that reads a barcode and keeps a list of what it read. These work because they do not need another person. No sign-up, no password reset, no server, no privacy policy, no support inbox.
Six to ten hours buys a second screen, one real device capability, and the smell of a finished thing. Camera, notifications or location, picked because the app is pointless without it. Starting data you typed in by hand, which beats an integration every time because it never rate limits you at hour nine. An icon, an empty state and one animation, in that order. Polish on one screen reads as a product. The same polish spread over four screens reads as nothing.
Ten hours and up is where people start adding sign-in, and it is usually still the wrong trade. Accounts pull in a server, a session, an error state for every network call, and a second device to test the whole thing on. If the idea genuinely needs two people to see the same data, that is a fine thing to build, just not against this clock. If choosing the idea is the part you are stuck on, what to build in a hackathon is the list, and the filter is whichever idea needs the fewest other people.
Getting it onto somebody else's phone is part of the day
A simulator on your laptop is not the same claim as an app on a phone. If a judge, a teammate or a first user is going to hold it, put that on the timeline explicitly, because the first build to a real device is where a day goes sideways. A bundle identifier, a signing certificate, a paid Apple Developer Program membership, and a store record that has to exist before the upload does.
Once that is set up, internal testing is the fast lane on iOS. Apple lets you designate up to 100 members of your development team who hold the Account Holder, Admin, App Manager, Developer or Marketing role as beta testers, and testers can use the builds you share on up to 30 devices. External testers are a different clock: up to 10,000 of them, but your first build has to be approved by App Review for TestFlight before any of them can install it. For a one day build that sentence is the whole planning constraint. People on your team can have it tonight. Strangers cannot.
Android is kinder on day one. A standalone APK installs straight onto a phone you are holding, and Play internal testing pushes a build to a short list of testers quickly. If you have never taken an app from nothing to a device, make an app is the walkthrough, and the day before the event is when to read it.
Apple, TestFlight: internal testers, external testers and devices
The two things 24 hours cannot buy
The first is a public store listing. Google Play requires new personal developer accounts to run a closed test with a minimum of 12 testers who have been opted in continuously for at least 14 days before they can apply for production access, and internal testing does not count towards it. A new personal account cannot be live on Google Play tomorrow, however fast you build. Fourteen days is the floor, and the application sits after it.
On the iOS side the queue is App Review, and the honest thing to say is that we are not putting a number on it here. Apple publishes its own current review timings, a rejection restarts the wait, and a first submission often collects one. So plan a demo for the end of the day and a launch for a fortnight later, in that order, and let nothing in your day depend on a stranger approving something.
The second thing you cannot buy is confidence. At the end of a one day project you have tested one phone, one operating system version, one happy path, and one person who already knows where to tap. That is enough for a demo and not enough for a launch, which is fine as long as you know which one you are holding. The list of checks you can honestly skip in a day, and the ones you cannot, is what you skip and what you cannot.
Google Play Console Help, requirements for new personal developer accounts
What a one day app project can include, and what it cannot
| What you are building | Build hours it needs | Needs accounts or a server | Fits one day | What you cut to make it fit |
|---|---|---|---|---|
| One screen that records something | 2 to 3 | No | Yes | Onboarding, settings, empty states |
| A tool with content you typed in | 4 to 6 | No | Yes | Search, an admin screen, a CMS |
| Camera, notifications or location | 5 to 8 | No | Yes | Permission copy, the unhappy path |
| Sign-in with data two people share | 10 and up | Yes | as a demo only | Password reset, roles, privacy work |
| A marketplace, or anything with payments | days | Yes | No | Nothing left that still works |
Building the one thing in the hours you actually have
Write the demo script before you write code. Three sentences: who opens this, what they tap, what they get. Then build only what those sentences need, in the order the script says them. It sounds like process overhead on a day this short. It is the one change that most reliably gets a team to a finished screen, because after it every cut decides itself.
Newly is an AI app builder, which changes the arithmetic at the start of the day rather than the end. You describe the app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. The part that matters on a short clock is that a new app is local first: data stays on the phone, with no accounts and no server, and a backend only appears when you ask for one. Code comes out as a ZIP from project Settings, or through the two way GitHub sync under Deploy.
A weekend app build is this same shape with one extra night, and the best use of the second day is not a fourth screen. Put the thing on somebody else's phone, sit next to them, and watch where they stop. The one or two changes that come out of that are worth more than everything you would have added instead.
Questions people ask before a one day build
One feature that works, for one kind of user, with its data stored on the phone. In practice that is one or two screens, one action that matters, and nothing that needs a second person involved. What does not fit is sign-in, shared data, payments, a second user type or a store launch. The limit is not talent. Each of those adds hours of error handling you have no time to test.
Pick the one thing and start the clock
Write the three sentence demo script, cut everything the script does not need, keep the data on the phone, and spend the last block on the version somebody else can hold.
Start building