0 to Hero — a campus sustainability game built by five people in six weeks.

A second-year university group project. A Django web app that gives students one sustainability challenge a day, scores them for doing it, and lets them spend the points on a virtual village. Two sprints, a shared repo, and a live deployment for the demo.

The brief.

Build a web app that gets students to act more sustainably on campus. Run it as a real software project: a team of five, sprints with a kanban board and meeting minutes, a shared codebase, and a demo at the end. The app needed a "gamekeeper" role so that staff could run the game after we'd handed it over, plus the privacy policy and terms that come with holding student data.

We called ours 0 to Hero. Six weeks from first commit to final submission, with over two hundred commits from five people.

What we built.

• One challenge a day. A scheduled job picks a new sustainability challenge each morning from the pool, skipping anything used in the last week. Challenges can carry a campus location, which shows up on the map.
• Post to complete it. Students write a short response to the day's challenge. Submissions earn a base score, a bonus for answering early, and a bonus for keeping a streak going. Miss a day and the streak resets.
• Spend it on a village. Points are coins. Coins buy items in the village shop, which get placed in your own village. You can visit other people's villages, which is most of the reason to keep going.
• Leaderboards by streak and score, and a profile page with a picture, current streak and best streak.
• Gamekeeper tools. Staff accounts can add, edit and delete challenges, set their locations, and moderate student posts.
• Exeter accounts only. Registration requires a university email address and consent to the privacy policy.

My part.

We split the app by page rather than by layer, so each of us owned a slice from template to view to form. Mine were:

• Registration and login, including the university-email validation and the privacy-policy consent step.
• The challenge submission page, which is the core loop: show today's challenge, take the response, record it against the user, and hand back to the home page.
• The map page's front end, and the wiring in the submission flow that records where the student was.
• Profiles: profile pictures, viewing other people's profiles and villages, and making sure you can only edit your own.
• The navigation bar that changes depending on whether you're signed in, the seed set of challenges, and the tests for the flows I owned.

Working in a team.

This was the first time I'd written code that depended on someone else's code while they were still writing it. The data model was one person's job; everything I built sat on top of it, and when a field changed, my pages broke. We ran a Trello board with snapshots taken each sprint, kept minutes for every meeting, and got very familiar with merge conflicts, because five people were committing straight to main.

The thing that actually worked was the page-ownership split. Nobody was blocked waiting for someone else's layer, and the seams between pages were simple enough that integrating was mostly a matter of agreeing on URL names and template blocks.

"Owning a page end-to-end taught me more about Django than any tutorial. Owning it next to four other people taught me more about software."

What I'd do differently.

• Branches and pull requests. Everyone on main worked at five people for six weeks, barely. A branch per feature and a quick review before merging would have caught half the last-day fixes earlier.
• Test from the start. The test suite landed in the final days, which meant it confirmed things worked rather than catching things that didn't. Writing the login and posting tests first would have made every later change safer.
• Check the location. Challenges have coordinates and submissions record where the student was, but nothing compares the two. It runs on the honour system. A simple distance check would have made location challenges mean something.
• Pin the environment. No requirements file meant "it works on my machine" was a recurring conversation. Ten minutes on a lockfile at the start would have saved hours.

What it taught me.

Everything else on this site I built alone. This is the one that looks like a job: other people's code, a deadline that didn't move, a client-style brief, and a demo to a room. The habits I have now around small commits, clear ownership and talking before touching shared code started here, mostly by learning what happens without them.