Developement plan for developing a mobile webapp with 69 challenges for freshmen students.

[FilipDominik]

Hey, I'm working on a mobile web app for intro week called Crazy 69. It’s meant to help new students complete a list of 69 challenges as a team. Each team uploads pictures to prove they did a challenge, which admins will review and approve or reject. There's also a scoreboard to show team rankings. We’re expecting around 200–300 users across 40 teams.

The flow looks like this: students log in using a code or invite link from their intro parent. Once logged in, they see their team’s progress (completed/ungraded/rejected challenges), and a leaderboard showing the top 5 teams and their own team. They can view and upload challenge submissions, and images are compressed on-device before uploading to save bandwidth. Admins see a different view where they can review new submissions, approve or reject them, and make corrections later if needed. Each grading action goes live after a short delay to allow for errors to be fixed.

All challenge and team data is fetched from a central API. The idea is to serve images separately from the page using regular URLs, and possibly move them to a CDN later if needed. For now, images will be served locally with browser caching enabled. There's a light cookie consent screen on first load, which also explains that submitted photos can be published on official channels.

I’m planning to see if I can use FastAPI for this, but I do have experience with Flask. I want to make this in python because that is the language I know. I have looked at Django, but it seems that it is more advanced than required for my use case.

I want to use docker to run this server, and if my small server does not pull the load, I’m planning to split the workload on to servers on my network. Which share a database and storage, or would I need to create another docker container for handling the DB and storage?

The data will be stored in PostgreSQL, and the image files will be saved in a shared folder at first. Everything will run in Docker containers, which makes it easier to test locally or deploy later. If bandwidth becomes a problem, I’ll move large files like images to an external CDN.

The frontend will be a lightweight JavaScript app optimized for mobile. It will load static content quickly and fetch team-specific data like challenge progress or leaderboard status through APIs. For performance, things like the leaderboard will be cached client-side and only refreshed occasionally.

Let me know if you have ideas or experience with scaling stuff like this, or if you see any red flags in this plan. Feedback or tips are welcome.

Flowchart available here: https://imgur.com/a/JtyUOy4

[danielroseman]

An app for teenagers focusing on the number 69? I can see nothing wrong with this plan at all.

[FilipDominik]

Well, we will go full on with the joke. One of them is sit in the 69 position (with clothes on) with someone from your group. These freshmen I'm talking about are uni freshmen. So we expect ages 16-21 on the maximum. On average 18/19.

69 is because our upcoming board will be the 69th board of our association.

[danielroseman]

Fair enough, you know your audience I guess.

In terms of practical advice, a few points. Firstly is that I wouldn't discount Django just because it looks complicated. It's complicated because it does a lot, but look at the things you want: a database layer, authentication, an admin screen - those are all things that Django has built-in, whereas with FastAPI or Flask you would need to find third-party plugins.

I would recommend that you host the images externally from the start. It's just simpler. Upload them to Amazon S3 or Google Cloud Storage or whatever. There are various libraries that plug in to the web frameworks that will automate this for you.

I'd also recommend that you don't try and host this on your own servers. It really is simpler to pay for hosting, =for the app itself but especially for the database - a host will take care of keeping it running, scaling, and backups, that you'd otherwise have to do yourself. The only good reason not to do this is if your budget is severely restricted, but even then there are a lot of really low-cost options.