Admin App

The Tripinger admin app is the internal control dashboard for running the platform. It gives authorized operators the tools to verify supply, moderate content, review bookings and payments, support partners and travelers, and oversee the platform’s trust, safety, and operational quality.

Purpose

Tripinger is planned as an all-in-one travel and mobility platform with hotels, vehicle rentals, food arrangements, itinerary planning, budget tools, reviews, social features, AI assistance, and partner onboarding. A platform with that scope needs an internal app where staff can monitor activity, enforce trust rules, resolve operational issues, and manage launch-critical workflows.

Why the admin app exists

The blueprint includes verified hotel listings, owner onboarding for vehicles, verified reviews, partner management, social/community content, trust and safety controls, and compliance-sensitive travel flows. Those requirements make an admin dashboard essential from the beginning, even if the first version is smaller than the long-term operations suite.

Main responsibilities

The admin app should initially cover the operational areas that directly affect launch quality and platform trust:

• user oversight,
• partner approval,
• listing verification,
• booking monitoring,
• payment issue review,
• review moderation,
• support workflows,
• content moderation,
• trust and safety actions,
• platform configuration,
• audit visibility,
• reporting and operational KPIs.

Technology alignment

The admin dashboard should follow the same frontend direction as the other web surfaces so the monorepo stays consistent and maintainable.

Phase 1 priorities

The public roadmap prioritizes user auth, hotel search, hotel booking, tuk-tuk listings, vehicle booking, itinerary building, budget tools, and mobile responsiveness for the MVP. The admin app in the same phase should therefore focus on what keeps those launch flows safe and manageable rather than trying to implement the full future backoffice suite at once.

Recommended Phase 1 admin priorities:

1. Admin authentication and role checks.
2. Dashboard overview of platform health.
3. Hotel and vehicle listing review.
4. Partner approval and verification workflows.
5. Booking lookup and status review.
6. Payment issue review and webhook visibility.
7. Review moderation.
8. Support case notes or internal action logging.
9. Basic analytics and counts for launch operations.

Suggested folder structure

The exact code layout may change, but the app should be organized by admin workflows and shared internal UI patterns.

apps/admin/
├─ src/
│  ├─ main.tsx
│  ├─ App.tsx
│  ├─ app/
│  │  ├─ providers/
│  │  ├─ router/
│  │  ├─ layouts/
│  │  └─ guards/
│  ├─ components/
│  │  ├─ ui/
│  │  ├─ tables/
│  │  ├─ filters/
│  │  ├─ drawers/
│  │  ├─ forms/
│  │  ├─ charts/
│  │  └─ feedback/
│  ├─ features/
│  │  ├─ auth/
│  │  ├─ dashboard/
│  │  ├─ users/
│  │  ├─ partners/
│  │  ├─ hotels/
│  │  ├─ vehicles/
│  │  ├─ food/
│  │  ├─ activities/
│  │  ├─ bookings/
│  │  ├─ payments/
│  │  ├─ reviews/
│  │  ├─ social/
│  │  ├─ moderation/
│  │  ├─ compliance/
│  │  ├─ support/
│  │  ├─ reports/
│  │  └─ settings/
│  ├─ lib/
│  │  ├─ api/
│  │  ├─ auth/
│  │  ├─ config/
│  │  ├─ permissions/
│  │  └─ utils/
│  ├─ hooks/
│  ├─ types/
│  ├─ styles/
│  └─ tests/
├─ public/
└─ README.md

Suggested admin routes

The exact URLs can vary, but the information architecture should support a practical internal workflow.

• /login
• /
• /dashboard
• /users
• /partners
• /partners/:id
• /hotels
• /vehicles
• /restaurants
• /activities
• /bookings
• /payments
• /reviews
• /community
• /moderation
• /compliance
• /support
• /reports
• /settings
• /audit

Dashboard overview

The main dashboard should surface the operational metrics that matter most to a young marketplace launch. It should help a small team quickly see whether supply onboarding, bookings, moderation, and payment flows are healthy.

Recommended dashboard blocks:

• total users,
• active bookings,
• pending partner approvals,
• pending listing verifications,
• flagged reviews or posts,
• payment failures,
• booking cancellations,
• recent support cases,
• top destinations,
• hotel and vehicle supply growth,
• recent operational alerts.

Listing verification

The blueprint depends heavily on trust, especially for hotels and vehicle owners. It also highlights SLTDA verification, registration checks, owner documents, and compliance-sensitive onboarding for travel services.

The admin app should therefore support:

• review of new hotel submissions,
• review of vehicle-owner documents,
• identity and registration checks,
• approval or rejection actions,
• notes for incomplete applications,
• listing status changes,
• badge assignment where supported,
• internal audit notes.

This is especially important because the early market strategy relies on quickly onboarding independent hotels and local vehicle owners while still preserving trust.

Booking operations

Hotel and vehicle booking flows are core MVP revenue paths in the roadmap, so admins need visibility into booking states from the beginning. The admin app should allow staff to search and inspect bookings without needing direct database access.

Recommended booking operations:

• booking lookup by ID, user, or partner,
• booking status tracking,
• payment status review,
• cancellation review,
• refund or escalation notes,
• booking timeline visibility,
• contact details for operational follow-up,
• links to associated listing and traveler records.

Payment review

The platform plans to use PayHere for local currency payments and Stripe for international payments, which means operations staff need a unified internal view of payment state and failure handling.

Recommended payment capabilities:

• view payment attempts,
• inspect provider and status,
• review webhook outcomes,
• detect mismatched booking and payment states,
• flag suspicious transactions,
• mark issues for follow-up,
• export or filter finance-relevant records.

Reviews and content moderation

The blueprint makes verified reviews and social/community content part of the long-term differentiation strategy. It also emphasizes verified-stay reviews and community trust, which means moderation tools are not optional.

Admin moderation should support:

• review approval or removal where needed,
• flag queue handling,
• content visibility changes,
• spam or abuse actioning,
• appeal notes,
• moderation history,
• reviewer and listing context,
• basic community post moderation in later phases.

Partner operations

Tripinger’s supply side includes hotels, vehicle owners, restaurants, guides, and experience providers. The admin app should help the internal team track onboarding quality and operational responsiveness across those partner types.

Useful partner features:

• partner search,
• onboarding stage tracking,
• verification status,
• missing documents list,
• listing counts,
• booking performance summary,
• last activity,
• support notes,
• suspension or reactivation controls.

Compliance and safety

The blueprint includes emergency assistance concepts, verified suppliers, insurance-related flows, travel compliance checks, and background validation concerns, especially for vehicle and guide-related operations.

The admin app should be prepared to support:

• compliance status views,
• registration and license checks,
• incident or complaint records,
• safety report intake,
• emergency escalation flags,
• restricted listing actions,
• fraud review notes,
• high-risk booking visibility.

User and support operations

Even in an MVP, admins need the ability to help users recover accounts, investigate issues, and resolve booking confusion. The admin app should make support faster without exposing unsafe write access everywhere.

Recommended support workflows:

• search traveler by email or phone,
• review recent bookings,
• inspect account status,
• view support interactions,
• add internal notes,
• trigger safe support actions through the API,
• escalate disputes to specialized queues.

Reporting

The platform blueprint includes revenue projections, partner growth targets, booking growth targets, and multi-stream monetization. The admin app should therefore include at least lightweight operational reporting to help the founding team monitor early traction and launch health.

Useful early reports:

• bookings by day,
• bookings by module,
• partner signups,
• approval conversion,
• payment success rate,
• cancellation rate,
• review volume,
• destination demand,
• top-performing hotel and vehicle categories.

Environment variables

The admin app should use public-safe frontend environment values, typically including:

• VITE_ADMIN_APP_NAME
• VITE_ADMIN_API_BASE_URL
• VITE_ADMIN_BASE_URL
• VITE_ADMIN_SENTRY_DSN

Additional feature flags can be introduced as admin-only UI modules are added.

Local development

Prerequisites

Install:

• Node.js LTS
• pnpm
• the Tripinger API running locally
• access to the root .env file
• Docker if dependent local services are started through containers

Typical setup

pnpm install
cp .env.example .env
pnpm docker:up
pnpm --filter admin dev

If the monorepo uses root-level scripts, prefer those.

Expected local URLs

Admin app: http://localhost:3001
API:       http://localhost:4000/api/v1

Auth and permissions

This app should never be treated as a public client. Access must be restricted by backend-enforced roles and permission checks, not only by hidden routes in the frontend.

Suggested internal roles:

• Support Agent
• Operations Admin
• Content Moderator
• Compliance Reviewer
• Finance Ops
• Super Admin

Recommended permission model:

• route guard by role,
• fine-grained action permissions,
• read-only views where possible,
• write access limited to approved workflows,
• audit trail for sensitive actions.

UX expectations

An admin app should optimize for clarity and speed rather than visual marketing polish. It should help a small operations team process large amounts of information safely and quickly.

Important UX patterns:

• dense but readable data tables,
• global search,
• quick filters,
• status chips,
• detail drawers and side panels,
• bulk actions with confirmation,
• clear empty and error states,
• keyboard-friendly workflows,
• visible audit context for destructive actions.

Testing expectations

At minimum, the admin app should support:

• auth guard tests,
• role-based route tests,
• table filter tests,
• moderation action tests,
• partner approval flow tests,
• booking lookup tests,
• report view smoke tests.

Highest-priority Phase 1 admin test flows:

1. Admin login.
2. Pending partner review list.
3. Listing approval or rejection path.
4. Booking search and detail view.
5. Payment issue inspection.
6. Review moderation action.
7. Restricted route protection for non-admin users.

Deployment direction

Like the public web app, the admin dashboard should be easy to deploy as a standalone frontend with environment-specific API configuration. It should remain isolated from public marketing concerns and optimized for internal reliability.

Recommended deployment properties:

• strict auth gating,
• non-indexed pages,
• environment-specific admin URL,
• audit-friendly logging hooks,
• error tracking,
• stable table and filter behavior,
• safe fallback handling for protected routes.

Contribution guidance

When adding a new admin workflow:

1. Create it under src/features/<domain>.
2. Reuse shared table, filter, and layout components where possible.
3. Define permission requirements early.
4. Add loading, empty, forbidden, and error states.
5. Prefer read-only defaults for sensitive data.
6. Document any new env variables in the root .env.example.
7. Update this README if the workflow changes app-level structure.

Current status

This README defines the intended role and structure of the Tripinger admin dashboard based on the approved architecture work and the operational needs implied by the startup blueprint. Exact route labels, scripts, and package-level decisions should be aligned with the repository once the admin app scaffold is committed.