Introduction

Tripinger is an all-in-one Sri Lankan travel platform designed for both international tourists and local travelers. It combines accommodation booking, vehicle rentals, experiences, food arrangements, AI-powered trip planning, budget management, reviews, social travel features, partner tools, and admin operations into one connected product.

Previous project name: Ceylon Journeys. Current working project name: Tripinger.

Table of Contents

• Overview
• Problem Statement
• Platform Scope
• Core Modules
• Target Users
• High-Level Architecture
• Repository Structure
• Technology Stack
• Getting Started
• Documentation Map
• Delivery Phases
• Assumptions
• Status

Overview

Tripinger is being positioned as Sri Lanka’s integrated travel and mobility platform, bringing together booking, planning, budgeting, and community features that are usually split across multiple separate products. The platform vision is to support the full travel journey, from discovery and trip planning to booking, on-trip coordination, reviews, and post-trip social engagement.

The product serves two primary audiences: foreign tourists visiting Sri Lanka and local Sri Lankan travelers planning domestic trips. It is intended to support a marketplace model with multiple supply-side participants, including hotels, vehicle owners, guides, food and experience partners, and internal administrators.

Problem Statement

The project is based on the idea that Sri Lanka’s travel market remains fragmented across disconnected services. Accommodation, transport, food planning, itinerary creation, and social travel sharing are typically handled through separate tools and vendors, creating friction for travelers and limiting revenue capture for local service providers.

Tripinger aims to reduce that fragmentation by offering one platform for discovery, planning, booking, budget tracking, and community interaction. The business case also emphasizes lower commission opportunities for local partners compared with large global OTAs and more direct digital access for Sri Lankan travel businesses.

Platform Scope

Tripinger is planned as a multi-surface product with separate applications and shared backend services. The approved documentation plan indicates dedicated applications for the public web platform, API, admin dashboard, and partner portal.

The platform scope includes both customer-facing and operational capabilities:

• Public booking and trip-planning experience.
• Partner onboarding and listing management.
• Admin oversight, moderation, reporting, and payouts.
• Shared backend services for identity, bookings, payments, notifications, search, and AI-assisted planning.

Core Modules

The current confirmed product scope includes the following major modules:

Target Users

Tripinger is designed for two main demand-side user groups:

• International tourists traveling to Sri Lanka for leisure, adventure, long stays, or group travel.
• Local Sri Lankan users planning short trips, weekend stays, transport rentals, and domestic experiences.

It also supports multiple supply-side and internal roles:

• Hotel and accommodation partners.
• Vehicle owners and fleet operators.
• Experience hosts and food-related partners.
• Internal administrators and moderators.
• Operational teams managing support, content, reviews, and payouts.

High-Level Architecture

The product is currently planned as a modular platform with a dedicated API layer and multiple frontend applications. The investor blueprint describes a service-oriented architecture centered around an API gateway, separate functional modules, async processing, and shared infrastructure for payments, storage, caching, notifications, and AI features.

At a high level, the architecture is expected to include:

• A public web application for traveler-facing features.
• A backend API for business logic, authentication, integrations, and data access.
• An admin dashboard for internal operations and moderation.
• A partner portal for supply-side users to manage listings, availability, and payouts.
• Shared data and infrastructure services such as PostgreSQL, Redis, search, object storage, and payment integrations.

See:

• docs/ARCHITECTURE.md
• docs/DATABASE.md
• docs/MONOREPO.md

Repository Structure

The approved file plan indicates a monorepo-style structure with separate application folders and shared documentation. The exact repository tree is not yet confirmed, so the structure below should be treated as a working documentation-oriented layout.

/
├── README.md
├── CONTRIBUTING.md
├── CODE_OF_CONDUCT.md
├── SECURITY.md
├── .env.example
├── apps/
│   ├── api/
│   │   ├── README.md
│   │   └── docs/
│   ├── web/
│   │   ├── README.md
│   │   └── docs/
│   ├── admin/
│   │   ├── README.md
│   │   └── docs/
│   └── partner/
│       ├── README.md
│       └── docs/
└── docs/
    ├── ARCHITECTURE.md
    ├── DATABASE.md
    ├── DOCKER.md
    ├── TECH_STACK.md
    ├── MONOREPO.md
    ├── ENVIRONMENTS.md
    ├── DEVOPS.md
    └── database/

Technology Stack

The current blueprint recommends a modern TypeScript-centric stack for web, API, infrastructure, and AI-assisted features. These choices are part of the project’s current planning baseline and should be validated against implementation constraints before being treated as final.

See:

• docs/TECH_STACK.md
• docs/DEVOPS.md
• docs/DOCKER.md

Getting Started

This repository is currently documentation-led and implementation details are still being finalized. Until the project bootstrap is confirmed, use the steps below as placeholders rather than final setup instructions.

Prerequisites

• Assumption: Node.js version: <<TO_BE_CONFIRMED>>.
• Assumption: Package manager: <<TO_BE_CONFIRMED>>.
• Docker and Docker Compose for local infrastructure.
• PostgreSQL, Redis, and any other local dependencies defined later in docs/DOCKER.md.

Initial setup

# Assumption: clone the repository
git clone <<REPOSITORY_URL>>
cd tripinger

# Assumption: install dependencies
<<PACKAGE_MANAGER>> install

# Assumption: copy environment file
cp .env.example .env

# Assumption: start local infrastructure
docker compose up -d

# Assumption: start development applications
<<PACKAGE_MANAGER>> run dev

Application-specific setup

Application-specific setup will be documented in:

• apps/api/README.md
• apps/web/README.md
• apps/admin/README.md
• apps/partner/README.md

Documentation Map

This README is the main documentation entry point. It should stay concise and link outward to detailed documents instead of duplicating technical specifications.

Foundation documents

• docs/ARCHITECTURE.md — overall system architecture, service boundaries, and data flow.
• docs/DATABASE.md — high-level data model and database strategy.
• docs/DOCKER.md — local container setup and service wiring.
• docs/TECH_STACK.md — technology choices and rationale.
• docs/MONOREPO.md — repository organization and workspace conventions.
• docs/ENVIRONMENTS.md — local, test, staging, and production environment rules.
• docs/DEVOPS.md — CI/CD, deployments, and release automation.

Backend and API

• apps/api/README.md — API service setup and overview.
• apps/api/docs/AUTH.md — authentication and authorization model.
• apps/api/docs/API_CONVENTIONS.md — API standards and response conventions.

Frontend applications

• apps/web/README.md — public web application setup.
• apps/admin/README.md — admin dashboard setup.
• apps/partner/README.md — partner portal setup.

Database module documentation

• docs/database/README.md — database documentation entry point.
• docs/database/ENUMS.md — shared enum definitions.
• docs/database/MIGRATIONS.md — migration workflow and rules.
• docs/database/ERD.md — ERD descriptions and Mermaid diagrams.

Governance and collaboration

• CONTRIBUTING.md — contribution workflow and review expectations.
• CODE_OF_CONDUCT.md — team behavior standards.
• SECURITY.md — vulnerability reporting and disclosure process.

Delivery Phases

The approved documentation program is divided into three phases totaling 79 files. Phase 1 covers foundation and architecture, Phase 2 covers core product implementation and database modules, and Phase 3 covers quality, operations, governance, and advanced capabilities.

Assumptions

The following items are not yet confirmed and should remain placeholders until explicitly approved:

• Final repository URL.
• Final package manager and lockfile standard.
• Exact Node.js and TypeScript versions.
• Final deployment hostnames and domain structure.
• Exact service boundaries, especially whether the system will remain modular within one API codebase or move to independently deployable services.
• Whether the mobile app is part of the current repo or a future phase.

Status

• Documentation status: Draft.
• Product implementation status: planned and partially defined at the documentation level; implementation completion is not asserted in this file.
• This README is intended to evolve as architecture, setup, and delivery decisions are confirmed.