Multi-user, stateful web app. Your app must be a full-stack web app, with a back end that provides persistent storage, and a modern front end that allows dynamic interactions without distracting page reloads. You can build your app for a phone, either by having it run in the browser or by using a framework such as Capacitor (but the teaching staff will not be able to help you with that aspect of your work). Your app should serve multiple users, and should be stateful, maintaining information between sessions. In particular, it should not be a wrapper for a one-shot function that could just as well be implemented as a desktop script. Preferably, your app should involve interactions between its multiple users, since it it unlikely that an app that involves no such interactions will fulfill a practical need.

Authentic need. Your app should aim to fulfill an authentic need. That means that it should be motivated by a real problem for which there is compelling evidence. A problem is something experienced in the course of daily life or work, and is not just a perceived flaw of an existing app. Games tend not to make good projects, because successful games are most often distinguished not by their design but by their artistic and narrative qualities (which are important of course, but just not the subject of this class). You might seek your problem in the activities and groups that you participate it; the most interesting problems are likely to be those that are ones for which you have particular experience or knowledge. But beware generic apps to support student life (such as apps for forming study groups, getting together with friends, sharing food deliveries or assigning living group chores); these tend to lead to uninteresting projects because the problem is rarely severe enough to be worth solving. If you have connections to people outside the university who are engaged in complex activities, they may be a valuable source of project ideas. Perhaps you’re connected to a non-profit, for example, that would benefit greatly from a software app but has not had the resources to build it.

A complete app. You should aim to produce a functionally complete version of the app that your stakeholders can actually use. Designing, building and testing such an app is a much more valuable experience than building a small part of a more complex app that will be hard to evaluate.

Ambitious, but not too ambitious. You should be ambitious enough that you are excited not only by constructing the app but also by the prospect of it being used. But don’t be too ambitious. As you no doubt discovered in your personal project, software takes longer to develop than you originally expect, and complications always arise. To balance these, be ambitious in the problem you take on, but think hard to design a simple solution that achieves its purpose with the minimal number of features.

Innovative. Your project must be innovative, in the sense that you should not build a clone of an app that already exists. This does not mean that you project must be unprecedented in the sense that there are no other existing applications that address the same problem or have similar features. If your project is similar in function to an existing app, then make sure that it is innovative in terms of its particular combination of features, and in refinements that make it simpler, more flexible or easier to use.

Review prior advice. Make sure to review the problem framing advice from the first lecture and the first assignment of the personal project.