EasyTrip was a semester project: plan trips, share itineraries, and coordinate tasks. It became a sandbox for practicing pragmatic team engineering.
Core Features
- Trip creation & shared editing
- Day-by-day itinerary timeline
- Attachment & note support
- Simple invite / permission model
My Focus Areas
- API Design: Defined REST resources (trips, days, items, invites) + consistent JSON envelope
{ data, meta, error }. - Validation Layer: Central request schema using joi so frontend errors returned with field context.
- Review Process: Instituted PR template (context, screenshots, test notes) to reduce back/forth.
What Worked
- Short issue scopes (< 2 days) kept momentum.
- Early domain language ("day block", "activity item") reduced ambiguity.
- Slack bot that posted deploy logs increased transparency.
What Didn't
- Underestimated offline editing complexity—cut feature mid‑sprint.
- Test coverage lagged; retro added a daily 15‑min test sweep.
- UI polish backlog ballooned; instituted weekly "polish hour".
Key Takeaways
- Write the happy path first then list failure modes explicitly.
- Low ceremony, consistent structure beats heavyweight process for student teams.
- A stable API contract unblocks parallel UI work quickly.
If Rebuilt Today
I would layer in type safety end‑to‑end (TypeScript + zod), and adopt a thin event bus for activity feeds.
Shipping with reflection loops meant we improved team mechanics while building real value.