Browsing minders by service, price, rating and distance
Overview
A two sided platform connecting pet owners with local pet minders. Minders list the services they offer and their prices. Owners add their pets, browse minders near them, then book and pay for a service.
Most of the work sits around the booking itself. The minder accepts or declines the request, it moves through its stages automatically as the time passes, and both sides have to confirm it took place before it closes. A completed booking is what unlocks a review, and those reviews feed the ratings the next owner browses on. Payments are simulated, so no money moves.
Owners and minders each get their own dashboard, with messaging between them. There is also an admin role, since a marketplace that puts strangers in each other's homes needs a way to handle people. Users report each other, and an admin resolves the report with a warning, a suspension or a ban.
I led a team of seven, designed the interface and built most of the front end. My first product build.
Stack
- React
- Vite
- TypeScript
- CSS
- Node.js
- Express
- Socket.IO
- Multer
- node-cron
- JSON store
- Google Maps Platform
Decisions
Running the team
Seven people on one codebase, four weeks of build time. I took the lead on how we operated. I set up the repo and the branching and review standards, ran a Notion board for the schedule and task assignment, split the work into pairs, held calls twice a week, and reviewed every merge. I checked in constantly, and where someone had fallen behind I sat with them and filled them in properly.
One account, two roles
Owners and minders could have been separate account types, but plenty of people are both, and that would have meant two logins and two profiles for the same person. A user holds either role or both and switches between them, with the dashboard changing to match.
No database, no real auth
Data sits in JSON files that the server reads and writes directly, loaded into memory on start. Logins live in those same files, passwords in plain text, and a session is a user id kept in local storage. It meant anyone on the team could run the project with nothing to install or configure, which mattered more than durability for a prototype with a fixed deadline. None of it would survive real use, and that was the accepted trade.