background

HippoExchange was a practice capstone project designed to introduce us to developing software in a larger Agile environment before beginning our senior capstone. Our class worked toward the same product goal as a 13-person team, divided into separate web and mobile development groups.

I worked on the mobile development team as the lead front-end developer, primarily using Dart and Flutter. My role focused on building the application's interface, interpreting project requirements into functional mobile experiences, and helping maintain a consistent design across the app.

HippoExchange taught me how different software development feels when you're building alongside a larger team. It gave me hands-on experience with Agile workflows, coordinating development with other people, dividing responsibilities, and adapting as the project evolved. Those lessons became especially valuable when I later moved into my senior capstone, CampusWatch.

the project

The project itself was intentionally nebulous. Our professor gave us the idea for an app called HippoExchange, where users could list and borrow items from one another without exchanging any real currency. Beyond that basic concept, it was largely up to us to figure out what the platform would actually look like and how it would work.

The easiest comparison is something like Facebook Marketplace, except instead of buying something and permanently taking ownership of it, HippoExchange was centered around temporary borrowing and lending. That left us with a lot of questions to answer as a team: how should exchanges work, what motivates someone to lend their belongings, and how do we create a sense of trust between users?

our interpretation

With the concept intentionally left open-ended, our team had to decide what borrowing and lending would actually look like on the platform. After working through several user flows and stories, we landed on a karma-based point system built around our virtual currency, HippoBucks (HB).

Every user starts with 1,000 HB. When someone lists an item, they assign a HippoBuck value to it. Another user can then borrow that item, and once the transaction is completed, the agreed amount of HippoBucks is transferred to the lender.

This system gave us a foundation to build the rest of the application around, including listings, borrowing, lending, user profiles, and the different states an exchange goes through from beginning to completion.

mobile development

This was everyone's first time using Dart and Flutter, so there was a pretty significant learning curve from the beginning. I really had to dig into documentation, tutorials, and examples to figure out not only how Flutter worked, but how we could use it efficiently while building an actual application as a team.

To say it lightly, the development environment was not always friendly to work with. We ran into plenty of situations where something that seemed simple turned into hours of debugging, especially while we were still learning the quirks of Flutter and Dart. Once we got into the flow of things, though, we learned how to work around those frustrations and development became much smoother.

As the lead front-end developer for the mobile team, I spent a lot of my time figuring out how the pieces of the interface should come together. That meant thinking beyond individual screens and considering navigation, reusable UI elements, consistency between pages, and how the application should respond as a user moved through an exchange.

working in agile

Agile development was extremely helpful with a team this big. Every time we had a meeting, we all went around the table and spoke about what we did yesterday, what we will do today, and if there are any blockers. This exercise was super important to keep everyone in the loop.

We had a scrum master in our group that was in charge of keeping accountability between groupmembers, removing roadblocks, and while still working on the project. Once a week, all the scrum masters from multiple groups would have a scrum-of-scrums meeting and talk about what we did last week, what we will do this week, and any blockers.

We had bi-weekly sprints, meaning we would set a goal for every two weeks (set by the scrum master), complete everything in those two weeks, and present the changes in front of the class at the end of the sprint. We did this cycle until we all completed the project after a few months.

what i learned

One of the biggest things I learned was how to balance a project like this with everything else in my life. There's always more work that could be done, but I learned that managing my time and knowing when to step away was just as important as getting the work done.

This project also forced me to become comfortable with learning a technology while actively building with it. I couldn't wait until I completely understood Flutter or Dart—I had to research, experiment, make mistakes, and learn as I went.

Most importantly, I learned to trust the people I was working with. Being the lead didn't mean I needed to write every line of code or have every idea. Agile development works because everyone contributes, and learning when to contribute, listen, and trust my teammates made me a much better team member.