SaveOurSpecies
Category
Year
Stack
The brief was simple on paper: build an educational web platform about endangered animals, deliver it as a team, ship it within the capstone timeline. What made it real was the constraint. This was not a solo project. I was leading a team of five developers, most of whom had never shipped a product together before.
The subject matter gave it weight. Endangered species are not an abstract topic. The data is real, the loss is ongoing, and the platform needed to communicate that without feeling like a school assignment. We wanted people to actually care when they left the page.
Landing page
Dicoding capstone submission
Coordinating five developers meant the first real challenge was not technical. It was alignment. Tasks had to be divided without creating overlapping work. Components had to be consistent across contributors who had different coding habits. I set up the architecture early so the team had clear boundaries to work within.
Early testing surfaced two problems fast: contrast was too low in several sections, and the content hierarchy made it hard to know where to look first. We restructured the layout, tightened the type scale, and ran another round of testing before the final submission. Both issues were fixed before anyone outside the team saw the final build.
Community and conservation volunteers
Save Our Species was the first time I shipped something with a team under a hard deadline. It taught me that good frontend architecture is not just about the code. It is about making the codebase legible to people who did not write it, and making coordination feel like less of a friction than the actual work.
The database has since gone offline. But the project still runs. The UI holds up. And the lesson it left behind is one I carry into every team project since.