Technology Stack

Document Purpose

This document defines the planned technology stack for Tripinger across frontend applications, backend services, infrastructure, development tooling, data systems, integrations, and operational workflows.

Its purpose is to create a shared engineering baseline for architecture, implementation planning, onboarding, and documentation consistency across the repository. This document describes the currently intended stack direction based on the approved Phase 1 documentation set. It should be treated as the canonical reference for technology choices unless later architecture decisions explicitly replace part of the stack.

Stack Principles

Tripinger’s technology choices are guided by a few core principles:

• Prefer a TypeScript-first platform where possible.
• Keep the MVP operationally simple without blocking future scale.
• Use a modular architecture that supports multiple product surfaces.
• Select tools with strong ecosystem maturity and developer productivity.
• Keep the primary transactional system relational and strongly structured.
• Introduce specialized infrastructure only where it solves a clear product or operational need.
• Favor shared tooling across apps to reduce maintenance overhead in the monorepo.

The platform serves multiple clients and user types, including the public web app, admin dashboard, partner portal, and backend API. The stack is therefore chosen not only for raw feature delivery, but for consistency across these surfaces and the workflows that connect them.

Stack Summary

Frontend Stack

Tripinger includes three web-facing frontend applications in the current documentation scope: the public traveler app, the admin dashboard, and the partner portal. The existing documentation already treats all three as React/Vite/TypeScript applications with shared conventions across the monorepo.

Application framework

React is the planned frontend library across all current web surfaces. It fits the project’s need for reusable component systems, route-driven experiences, stateful dashboards, and feature-rich flows such as search, booking, onboarding, and moderation.

Vite is the planned frontend build tool and development server. It supports fast local development, a lightweight setup model, and independent deployment for each app surface. That aligns with the documented expectation that the public app, admin app, and partner portal can all run as standalone clients against the same API platform.

TypeScript is the standard language for frontend applications. This supports typed API integration, reusable models, maintainable component interfaces, and consistent developer experience across the full stack. The root README also describes the project as a TypeScript-centric platform.

Styling and UI

Tailwind CSS is the planned styling layer for frontend applications. Existing app documents already reference Tailwind as the shared styling approach, mainly because it enables rapid implementation, design-system consistency, and reusable dashboard or booking UI patterns.

Framer Motion is part of the planned public web stack for polished traveler UX, especially around transitions, interaction feedback, and motion-enhanced booking or planning flows. It is most relevant to the public product surface rather than the operational dashboards.

Maps and geospatial UX

Mapbox is the planned mapping provider across location-aware product features. The existing public web documentation identifies it for hotel and vehicle maps, route previews, destination discovery, and location context in planning flows.

Why this frontend stack

This frontend stack is appropriate for Tripinger because it supports:

• Fast product iteration in a startup context
• Strong component reuse across multiple apps
• Typed integration with a shared backend
• Good performance for both traveler-facing and dashboard-style interfaces
• Straightforward monorepo adoption

Backend Stack

The API is the central backend platform for the repository and acts as the orchestration layer for web, admin, partner, and future mobile consumers. The existing API and architecture docs already define the backend direction as Node.js, NestJS, and TypeScript, organized as a modular domain-driven platform.

Runtime and framework

Node.js is the planned backend runtime. It supports a unified TypeScript-based engineering model across frontend and backend, reducing context switching and simplifying developer onboarding.

NestJS is the planned backend framework. The API README explicitly positions it as the main framework for modular backend services, clean domain separation, and a practical path from modular monolith to independently scalable service boundaries if needed later.

TypeScript is also the backend language standard. This is consistent with the repository’s TypeScript-first direction and supports shared types, clearer interfaces, safer refactoring, and a more maintainable codebase across domains such as auth, bookings, payments, partners, reviews, and AI planning.

Backend design fit

This stack is well suited because Tripinger’s backend must support:

• Authentication and role-based authorization
• Partner and admin workflows
• Booking state management
• Payment provider integration
• Search indexing orchestration
• Notifications and background processing
• Multi-client API consumption

These responsibilities are already described in the architecture and API docs as modular domain boundaries, making NestJS an appropriate fit for structure and long-term maintainability.

Data Stack

The approved documentation set clearly treats PostgreSQL as the primary system of record, with Redis and Elasticsearch as supporting systems rather than peer databases. The database architecture document makes that separation explicit and treats relational modeling as the core persistence strategy.

Primary database

PostgreSQL is the planned primary database for Tripinger. It is intended to hold users, partners, hotels, vehicles, experiences, bookings, payments, reviews, notifications, planner data, and operational records. The database architecture document explicitly defines PostgreSQL as the canonical source of truth for transactional and structured business data.

PostgreSQL is the right fit here because the platform includes:

• Transaction-heavy booking workflows
• Financially sensitive payment and refund records
• Partner verification and operational traceability
• Strong entity relationships across listings, bookings, reviews, and accounts
• Lifecycle history and audit-sensitive state changes

ORM and migrations

Prisma is the currently intended schema and migration layer. The database architecture already references Prisma migration workflows and names docs/database/MIGRATIONS.md as the place for detailed migration rules, which makes Prisma the expected choice for schema definition, migration management, and typed database access.

Prisma is a strong fit because it supports:

• Type-safe database access
• Structured schema ownership
• Versioned migrations
• Good compatibility with PostgreSQL
• Efficient developer workflows for a TypeScript codebase

Cache and ephemeral coordination

Redis is the planned cache and short-lived coordination layer. Current documents position Redis as useful for hot-read caching, temporary coordination, rate limiting, optional session-adjacent data, and async workflow support. It is explicitly treated as a supporting layer, not the canonical data source.

Search infrastructure

Elasticsearch is the planned search engine for filter-heavy and full-text traveler discovery flows. Both the root README and the database and architecture docs identify it as the search layer for hotels, vehicles, experiences, autocomplete, and derived search indexes.

This is a good fit because PostgreSQL should remain focused on transactional correctness, while traveler discovery often requires:

• Relevance ranking
• Faceted filtering
• Autocomplete
• Search index denormalization
• Fast read-heavy search experiences

Polyglot persistence note

Earlier planning materials referenced MongoDB for flexible review or community-oriented content, but the approved current documentation set does not define MongoDB-backed modules. For the current repository baseline, PostgreSQL remains the documented primary persistent store unless a later architecture decision reintroduces a second database formally.

AI and Planning Stack

Tripinger includes AI-assisted trip planning and itinerary capabilities in both the product vision and the technical plan. The current docs reference OpenAI and also leave room for a Python/FastAPI extension when AI workloads need stronger separation from the core API runtime.

AI provider

OpenAI API is the planned AI provider for itinerary generation, planning assistance, and related intelligent travel workflows. The root README and API documentation already list OpenAI as the intended provider for these capabilities.

AI service boundary

A Python / FastAPI service is treated as an optional AI extension path rather than the only backend path from day one. The README identifies “OpenAI + Python/FastAPI” as the planned AI direction, while the architecture keeps open whether AI logic remains embedded in the main API boundary initially or evolves into a separate service earlier.

Why this AI setup

This approach gives the project flexibility:

• Keep Phase 1 operationally simple
• Avoid over-fragmenting the backend too early
• Preserve a path to isolate AI cost, latency, and scaling concerns later
• Support specialized AI orchestration if the planner grows more complex

Payments and Financial Integrations

Tripinger’s payment strategy is explicitly split between local and international payment handling. The existing docs consistently identify PayHere for Sri Lankan or local-currency flows and Stripe for international card payments.

Payment providers

PayHere is planned for locally relevant payment flows, especially LKR transactions and Sri Lanka-oriented payment handling.

Stripe is planned for international traveler payments and global card support.

Why dual payment support

This split is appropriate because the product serves both:

• International tourists booking from outside Sri Lanka
• Local or Sri Lanka-centered payment use cases

The existing architecture and API docs also emphasize that booking state changes must be driven by verified payment outcomes and webhook-confirmed transitions rather than only frontend callbacks. That makes webhook-safe provider integration and explicit payment lifecycle modeling essential to the stack.

Media, Messaging, and External Services

Tripinger depends on more than core application code. The architecture and app docs already assume integrations for media delivery, transactional communication, location context, and alerts.

Media storage

AWS S3 and/or Cloudinary are the planned media-storage options for listing photos, review media, and partner documents. The root README references both, while the database and architecture docs describe a clear separation between binary file storage and relational metadata stored in PostgreSQL.

Email and communication

SendGrid is the documented email provider direction in the API README, particularly for auth flows, confirmations, and transactional communications.

Twilio and Firebase FCM are listed in the API README as messaging and push-notification technologies for SMS, WhatsApp, and mobile or app notifications. These are currently best treated as planned integrations rather than fully locked implementation details.

Maps and geolocation

Mapbox is the planned location provider for public user experiences involving maps, routes, and listing geography.

DevOps and Delivery Stack

The root README and architecture documents already describe Tripinger as a containerized, CI/CD-driven platform with independent frontend surfaces and a backend container runtime.

Containerization

Docker and Docker Compose are the planned standard for local infrastructure and container packaging. The existing docs already refer to Docker-based local setup and service orchestration.

Continuous integration and delivery

GitHub Actions is the planned CI/CD platform for validation, build automation, and release workflows. The root README includes it in the baseline DevOps direction.

Hosting direction

Vercel or an equivalent edge-friendly frontend host is the current direction for frontend delivery. The public web and root docs both describe frontend hosting as edge-friendly and environment-configurable.

Container-based backend hosting, likely AWS-aligned, is the current backend hosting direction. The architecture document keeps the exact split open, but describes containerized backend deployment and a likely AWS-oriented path as the platform grows.

Operational fit

This delivery stack works well because it supports:

• Independent deployment of frontend surfaces
• Environment-based configuration
• Container-friendly backend execution
• Progressive scaling without early infrastructure overengineering
• Standardized local development and CI workflows

Monorepo and Developer Tooling

The current docs already frame the repository as a monorepo with multiple applications and shared packages. That structure requires tooling that can coordinate dependency management, scripts, and cache-aware builds efficiently.

Workspace management

pnpm workspaces is the planned package and workspace management approach. The root README’s setup placeholders and the documentation plan both assume a workspace-driven monorepo structure rather than isolated repositories.

Build orchestration

Turborepo is the planned monorepo task runner and orchestration layer. The Phase 1 file plan explicitly includes docs/MONOREPO.md for Turborepo configuration and workspace coordination, which signals Turborepo as the intended build and pipeline tool for the repo.

Developer productivity tooling

The current setup direction across the generated docs implies the following developer baseline:

• Git for version control
• TypeScript-first code standards
• Shared environment-variable management via .env.example
• Docker-backed local service startup
• Workspace-filtered app commands for local development

Exact linting, formatting, and commit tooling has not yet been fully specified in the attached generated files, so those should remain implementation decisions until confirmed in CONTRIBUTING.md and docs/MONOREPO.md.

Technology by Surface

Versioning Policy

The existing generated docs do not yet confirm exact versions for Node.js, TypeScript, React, Vite, NestJS, Prisma, PostgreSQL, Redis, or Elasticsearch. The root README explicitly lists these version details as still pending confirmation, so this document should not invent final versions yet.

Until exact versions are approved, the repository should follow these rules:

• Prefer current stable major versions for production-ready tools.
• Standardize one Node.js LTS version across all apps.
• Avoid frontend-backend TypeScript version drift where possible.
• Pin critical infrastructure and tooling versions in Docker and CI once implementation begins.
• Update this file when versions become official project standards.

Selection Rationale

The chosen stack works because it balances startup delivery speed with architectural clarity:

• React and Vite support fast product iteration across multiple frontend surfaces.
• TypeScript improves consistency across frontend and backend codebases.
• NestJS supports modular backend organization for a broad domain surface.
• PostgreSQL provides the transactional integrity needed for bookings, payments, partner verification, and traceable operations.
• Redis and Elasticsearch solve specialized performance and discovery needs without displacing the relational system of record.
• PayHere and Stripe reflect the platform’s split between Sri Lankan and international payment contexts.
• Docker and GitHub Actions support local consistency and structured delivery workflows.

Current Status

This technology stack is the planned baseline for Tripinger based on the currently generated Phase 1 documents. Several exact implementation details remain open, including final version numbers, final hosting split, queue/event tooling, and whether some optional supporting services are introduced in Phase 1 or deferred.

Until those decisions are finalized, this document should be used as the repository’s canonical technology-direction reference, not as proof that every listed tool is already implemented.