Moni Share

Overview

Moni Share is a car sharing web application built as part of The Gym's curriculum in Kigali. It's a platform where car owners can list their vehicles and others can browse and book them.

What made this project different wasn't just what we built — it was howwe built it. The entire project was structured to simulate enterprise team dynamics: Figma designs, Trello boards, daily standups, and a real code review pipeline. It was one of the most complete simulations of professional development I've been through.

The Workflow

Work was managed through Trello. Each ticket moved through five stages:

Once a ticket was moved to “In Review”, it went through a three-stage review process before it could be marked done:

The Senior Review was a live call — she would go through your code, give feedback, and share insights from real production experience. That part was especially valuable.

Every morning started with a standup: what did I do yesterday, what am I doing today, any blockers? It felt repetitive at first. Then I understood why teams do it.

Two Sprints

The project ran across two distinct phases, separated by a short break:

Sprint 1: Building the Frontend

We were given Figma screens and a Swagger API spec. The work was split into over 50 Trello tickets. Each team member would pick one up, implement it independently, then put it through the full review pipeline.

The features we built covered the full booking flow: browsing available cars, making and managing bookings, and handling different user roles (driver and car owner).

Sprint 2: Building the Backend

After the frontend was signed off, we switched to building the NestJS backend. The codebase we were handed to work in was intentionally complex — designed to teach us what a production-grade backend actually looks like.

Finding your way around someone else's large codebase is a real skill. This sprint made that very clear.

The Architecture

The backend wasn't structured the way NestJS scaffolds it by default — one folder per feature with everything inside. Instead, it used a layered architecture: a persistence layer, a service/domain layer, a controller layer, and a presentation layer, each with clearly defined responsibilities.

The architect, Raphael Pigulla from MaibornWolff (a German software company), recorded a walkthrough explaining the design decisions. We had to watch it and work through the structure before writing a single line. It took time — but it gave me a much better mental model of what “enterprise backend” actually means in practice.

A Moment Worth Remembering

During the frontend sprint, we hit a bug where deleting a car from the listing wouldn't reflect in the UI without a full page refresh. We traced it back to a race condition — the delete request would resolve but the list query would fetch stale data before the backend had finished updating.

One teammate suggested TanStack Query. Its cache invalidation approach solved the problem cleanly — after a mutation, you invalidate the relevant query and the UI updates automatically. I picked it up from that conversation, and it's been part of how I think about data fetching ever since.

That's something team environments do that solo work doesn't — you pick up tools and patterns through other people solving problems out loud.

Tech Stack

• React & TypeScript — component-based frontend
• TanStack Query — server state management & cache invalidation
• NestJS — layered backend architecture
• PostgreSQL — relational database
• Docker — containerized services
• Git & GitHub — version control and peer review

What I Learned

Moni Share was the closest thing to a real job I'd experienced before actually having one. The Trello workflow, standups, and review pipeline weren't just process for its own sake — they existed because software built by teams without structure tends to fall apart.

The two-sprint structure also gave me something rare: perspective on the same product from both sides. Building the frontend first meant I deeply understood what the API needed to do. Building the backend second meant I understood why certain design decisions were made. Most developers only ever see one side at a time.