App ideas for students are not a creativity problem. They are a constraints problem.
Student projects have three constraints nobody else has in the same combination. The deadline is a term and it does not move. The budget is nothing. And it ends in a demo, usually in a room with unreliable wifi and a person asking questions.
Those three rule out more ideas than any technical limit does, and they rule them out late, which is the expensive way. Choosing against them at the start is the whole trick.
See what fits a termThe short version
Pick for the demo, not for the pitch. The demo is the part that is graded.
An idea that sounds ambitious in week one is a liability in week eleven. The projects that finish are the ones where the most impressive moment is something that works offline, on one device, in under thirty seconds.
That is not a lowering of ambition. It is choosing where to spend it: on a thing that works completely rather than a bigger thing that works in parts.
What makes a student app different from any other project?
The deadline is the obvious one, but the subtler constraint is the audience. A student app usually has its users in the same building: your cohort, your society, your department. That is a real advantage and most student projects waste it by choosing a generic idea that could have been built anywhere.
Proximity means you can watch someone use it, which is the feedback loop professionals pay for. It also means the problem is one you can verify is real rather than assume. A timetable clash finder, a lab equipment sign up sheet, a society subs tracker: each of these has a user you can go and ask.
The second difference is that the output is usually judged as work rather than as a product. Nobody is asking whether it scales. They are asking whether you understood what you built, which rewards a small thing you can explain completely over a large thing you assembled.
The other thing proximity gives you is a reason the app should exist that you can state in one sentence to a marker. That is worth more than scale. A project that solves an irritating thing for forty people in your department is easier to defend than a platform concept with no users, and the questions you get asked will be ones you can answer. Simple app ideas for beginners is a good source of shapes to adapt to a campus context.
Do you have to pay 99 USD to publish a student project?
Only if you intend to put it on the App Store, and there is a waiver worth understanding precisely because it is widely misread. Apple will waive the Apple Developer Program fee for a nonprofit organization, an accredited educational institution or a government entity that meets its requirements.
The part that catches students out is who the waiver is for. Apple's requirements say the applicant must be a legal entity with that status, and specifically must not be an individual, a sole proprietor or a single person business. So a student applying personally does not qualify. The university might, and a project published under a departmental account is a different conversation from one published under yours.
If you are not publishing, none of this applies. You can build, run on your own phone and demo without a paid membership at all, and for a graded project that is usually the right scope. Google Play is a one time 25 USD registration if you do want it in a store and the Android side is enough.
If the project is a group one, settle the account question in week one rather than week ten. Whoever holds the developer account holds the app, and on a student team that person graduates. Publishing under a departmental account where one exists avoids the whole problem. Student app development goes through the practical side of running a project inside an institution.
Apple, Apple Developer Program fee waiver requirements, read 7 October 2026
Which ideas actually fit a term?
The reliable shape is: one screen that does one thing, data stored on the device, no accounts, and a reason that a phone is the right place for it. Within that shape there is plenty of room to be specific, and specific is what makes a project interesting to mark.
Workable examples from a campus context: a tracker for a lab protocol with timed steps, a tool that turns a reading list into a weekly plan, a split calculator for a shared house that remembers who paid last, a practice log for a music student with a timer per piece, a field notebook for a geography unit that records entries offline.
What those share is that the interesting work is visible on screen, so when something is wrong you can see it, and the demo is the app doing its job rather than you narrating what it would do if the server were up.
A hackathon is the compressed version of all of this and a good rehearsal for a term project, because the constraints are the same ones turned up: no budget, a fixed deadline, a demo at the end. What to build in a hackathon applies the same filter over a weekend instead of a term, and the ideas that survive there tend to survive here.
Which ideas fail at demo time?
Anything that needs the network to be impressive. A live multiplayer anything, a social feed, a real time dashboard: these are the projects that work in your room and die in the lecture theatre, and the failure is public.
Anything that needs the camera or sensors without a plan to test on a real device, because a simulator does not give you a real camera and you will discover that late. If the idea genuinely needs it, start the device testing in week two rather than week ten.
And anything that is primarily a collection of links or a wrapper around an existing website. If you intend to publish, Apple's guideline 4.2.2 names exactly that, other than catalogs, as not acceptable. If you do not intend to publish, it is still the project that is hardest to say anything interesting about.
If the project turns out well, the question of whether to carry on with it after the module ends is a different one, with its own constraints around support and payment. Whether an app is a good side hustle is the honest version of that, including the parts that are unglamorous.
Five student ideas against the three constraints
| Idea | Fits one term | Costs nothing | Survives a bad wifi demo |
|---|---|---|---|
| Timed lab protocol tracker | Yes, one screen and a timer | Yes, local only | Yes, works offline |
| Reading list to weekly plan | Yes | Yes | Yes |
| Shared house bill splitter | Yes, if it stays on one device | Yes | Yes |
| Campus wide events feed | No, needs a server and content | No, hosting | No, needs the network |
| Live study group chat | No, real time and accounts | No | No, this is the classic demo failure |
Getting it built inside the term
The schedule risk on a student project is almost never the idea, it is the first fortnight disappearing into setup. Describing the app in plain English and getting a working React Native and Expo project back removes that fortnight, which is the part of the term you cannot get back.
Because the output is an ordinary codebase you own, it is also a project you can talk about in a viva and hand over to a marker, rather than a configuration inside a platform account that expires.
Newly is a paid product from $25 a month with no free tier, so it is worth checking whether your department has a budget line for tooling before you pay for it yourself.
Questions students ask about app projects
Not as individuals. Apple's requirements say the applicant must be a legal entity with status as a nonprofit, an accredited educational institution or a government entity, and must not be an individual, sole proprietor or single person business. An institution can hold a waived membership; a student applying alone cannot.
Pick something you can finish and demo
Choose the idea whose best moment works offline on one device, then describe it in plain English and get a real Expo project you own.
Start building