The prototype both roles were built from: employee flow on the left, employer on the right, mapped tap by tap before anyone wrote a screen.
Quick Cash is an Android app for finding small paid work nearby: mowing a lawn, walking a dog, fixing a computer. Every user is either an employer or an employee, never both at once, and the two roles get separate journeys through the app. Employers post jobs with a location, salary and category. Employees see what is near them on a map, search and filter it, apply with a short cover letter, and get paid through the app once the work is approved.
Six of us built it over three iterations for CSCI 3130 at Dalhousie in summer 2025, working to a written client brief. I led the team.
The part that made it a software engineering course rather than a programming one is that the process was the deliverable. Every iteration started with user stories, which became acceptance criteria, which became engineering tasks small enough to estimate by planning poker. Everything landed on a GitLab issue board, burned down against a chart that made it obvious when we were behind, and ended in a retrospective about what went wrong. We were graded on that as much as on the app.
What we used
Java on the Android SDK, with Firebase behind it for authentication, the database, and push notifications. Google Maps and the location provider for detecting where a user is and plotting jobs around them. The PayPal SDK for payments. JUnit for unit tests, Espresso and UI Automator for the interface, running on every push through a GitLab CI pipeline that linted, built and tested before anything merged. SonarLint sat on top of it flagging what we had written badly.
What I did
I led the team, and the coordination turned out to be the harder half of the job. Six people, three of them working in Mandarin, all writing into the same Android project on separate branches. I ran the branch and merge process, wrote up the deadlines and task breakdowns, chased the pieces that were blocking other pieces, and did a lot of merge conflict resolution in the last week of each iteration.
We had a real language barrier on the team, and it got worse as the codebase got more complicated: the same task would be understood three different ways. Setting up a second Discord channel that carried every announcement in Mandarin alongside the English was the single most useful thing I did on the project, and it is not a technical contribution at all.
On the code, I owned the payment flow end to end. That meant wrapping the PayPal SDK in a reusable helper, gating payment behind the employer actually approving the completed job, and writing the paid status back to the database. The interesting part was that the SDK's API is bound to an Android activity and therefore almost impossible to test, so I pulled the validation logic out into a plain class with no framework in it and tested that properly instead. I also built the location detection and map view, the multi-step password reset, and a chunk of the test suite.
Zach took the initiative to coordinate his group's efforts. He created a Discord channel for communication and established a separate channel that provided messages in Mandarin to assist three group members with limited English proficiency. This thoughtful approach helped bridge a language barrier that could have otherwise impeded their progress. He was a proactive leader who kept the team on track by notifying them of deadlines, clarifying tasks, and organizing out-of-lab meetings. Zach's ability to take on a leadership role, manage complex group dynamics, and make significant contributions to the team's output makes him a valuable asset.
Teaching assistant for the course, managed Zach directly · August 2025
What I took from it
- Estimates are wrong, and the tools built to show you that work. Planning poker, velocity and burndown charts were all new to me here, and the burndown is the one that earns its keep: ours sat flat for two weeks and then fell off a cliff, twice, before we started believing what it was telling us
- Test-driven development only works if the whole team is doing the same version of it. Half a team writing tests first is not half the benefit
- Code that is hard to test is usually telling you something about its shape. Pulling the payment validation away from the SDK was the fix, and it was a better design afterwards anyway
- A language barrier is a project risk, and you handle it the same way as any other: name it out loud, then build a process around it
- Write the report as you go. Doing it in the same week as the final merge, three times, was a choice we kept making
What it left me with: Java, Android SDK, Firebase (authentication, realtime database, push notifications), Google Maps and location services, PayPal SDK integration, JUnit, Espresso and UI Automator testing, Git and GitLab CI, static analysis with SonarLint, and Agile in practice: planning poker, user stories and acceptance criteria, burndown charts, retrospectives, and leading a team through all of it.
Built with Nathan Dsouza, Andrei, Xueqian, Yizhou Chen, and Deyang.