Backend Developer

IsoVoyage is a travel-agency SaaS initiative intended to compete with / mimic AlgebraTech, providing travel-agency management for flight and hotel bookings, group management, and reservation workflows. The product integrates Global Distribution Systems (GDS) to access consolidated flight, hotel, and travel inventory. The project required substantial independent domain research because many product requirements were not provided.

My first assignment was to prove my system-design capabilities by delivering a complete architecture and high-level system design for the platform (I can attach the diagram/screenshot I created). After the design was approved, we started backend implementation based on UI designs and the architecture.

Key responsibilities & contributions

Designed the system architecture and database schema to support bookings, group management, and GDS-driven inventory flows.

Implemented core backend endpoints including authentication (multi-layer RBAC), health checks, file uploads, and other platform APIs required by a small team.

Auth & performance optimization: implemented a multi-layer RBAC (4–5 role layers). To accelerate authorization checks I injected role IDs into JWTs and cached authorization strings in Redis — reducing DB dependency and improving authorization latency and throughput.

Implemented global API/docs configuration (Swagger) and global caching strategies to improve developer experience and runtime performance.

Advocated and designed separation between user profiles and company profiles to avoid schema coupling and future scalability/maintenance costs.

Evaluated Domain-Driven Design (DDD) approaches versus simpler code-first patterns to protect long-term maintainability and encourage clear domain boundaries.

Performed deployments and runtime configuration on Railway, and coordinated closely with the small frontend team to align API contracts and deliver features quickly.

Challenges & outcome

The project required intensive independent research because there were no direct client conversations; requirements were discovered mainly through product exploration and competitive analysis.

Building a SaaS product with only one backend and one frontend magnified responsibility and scope — I handled a wide range of backend tasks and contributed frontend work where needed.

After two months with limited clarity on long-term deliverables, I decided to leave the team. The experience taught a core lesson: we must deliver solutions, not just code — and without clear problem discovery and stakeholder alignment, produced code cannot deliver sustainable value.

The architecture and backend implementation I produced established the foundation for the product and reinforced best practices in maintainability and scalability.

Technical focus & themes

Respect for product lifecycle: requirement discovery, iterative validation, and avoiding premature implementation that increases technical debt.

Maintainability: clear domain boundaries, schema isolation (user vs company) to reduce future costs.

Scalability: token-based role injection + Redis caching to reduce DB load and speed up authorization decisions.

Operability: deployed and configured services on Railway to support rapid iterations in a small team.

Team: 1 team lead, 1 frontend, 1 backend — a full SaaS built with a very small team (one backend + one frontend)

.

Tech stack: NestJS, PostgreSQL, Prisma, Redis, Next.js, Railway (deployment)