← back to all projects
Splitwise Lite
Parts 4–5 — Testing, Auth, Full Stack Integration
Why This Project
This is your first real full stack app. Splitwise Lite has actual business logic
beyond CRUD — you need to calculate who owes whom, handle splits that don't divide
evenly, and make sure only group members can see and modify expenses. It's the kind
of app where bugs in your math or your auth logic produce visible, wrong results,
which makes it perfect for practicing testing.
What to Build
An expense-splitting app. Users create groups (e.g., "Apartment", "Trip to Baguio"),
add members to groups, and log expenses within a group. Each expense has a payer
and is split among selected members. The app calculates a simplified debt summary:
"Kyle owes Maria ₱450" rather than showing every individual transaction. Frontend
in React, backend in Express + MongoDB.
Requirements
- Backend:
- User registration and login with JWT + bcrypt
- Models: User, Group (with members array referencing Users), Expense (payer, amount, splitAmong, group)
- Only group members can view/add expenses in that group
- GET /api/groups/:id/balance — returns simplified debts (who owes whom, how much)
- The balance calculation is the hard part: minimize the number of transactions needed to settle all debts
- Integration tests with supertest: test auth flows, test that non-members can't access groups, test balance calculations with known inputs
- Separate app.js from index.js for testability
- At least 15 test cases
- Frontend:
- Login/register forms — store JWT, attach to requests
- Dashboard: list of user's groups
- Group page: list of expenses, add expense form, balance summary
- Notification component for success/error messages
- Component tests with Vitest + React Testing Library: test that expense form validates inputs, test that balance renders correctly
- One E2E test with Playwright: register → create group → add expense → see balance
Skills Practiced
JWT auth
bcrypt
authorization logic
business logic
Mongoose populate
supertest
React Testing Library
Playwright
full stack integration
frontend auth flow
Pain Point to Notice
The balance calculation algorithm is the first time in this roadmap where you have
real business logic that's hard to verify by just looking at the screen. You NEED
tests for this. Write the balance function, write test cases with known inputs and
expected outputs, and run them. If you try to verify the math by manually clicking
through the UI, you'll miss edge cases (what if someone paid for themselves? what
if the amount doesn't split evenly?). This is where testing stops feeling academic
and starts feeling necessary.