Marketplace · Tourism

Kampline

A multi-vendor booking marketplace that unifies tours, events, accommodation and product sales in one data model. 190k lines of code, 82 tables, 92 server functions and an Android app in the store.

kampline.com

190Ksatır kod

82tablo

92sunucu fonksiyonu

Open the site

Technical profile

What it is built with

Stack	React 18 + TypeScript, Vite, Tailwind CSS, TanStack Query
Backend	PostgreSQL with Deno/TypeScript edge functions and row-level security
Codebase	~190,000 lines · 1,060 files
Interface	261 components · 182 page components · 114+ routes
Database	82 tables · 218 versioned migrations
Server functions	92 (payments, coupons, email, reminders, reporting)
Mobile app	Android — com.kampline.app, from the same codebase
Locales	TR · EN · RU with per-locale sitemaps
Payments	Two card gateways, 3-D Secure, instalments, token balance

What makes it different

Not a standard website

Not a single product type. Tours, events, accommodation, rentals and physical goods live in one data model, each with its own booking and checkout flow. A standard booking site is written for one scenario; this one runs five under a single admin.
Pricing and ticket structure are not hard-coded. Sessions, ticket types, capacity and prices are read from a flexible schema the vendor defines — a new ticket type needs no code change.
There is a token economy alongside money. Refunds become tokens, balances live in a ledger and are applied to the next purchase, with refund rates set by the operator.
Payments are not tied to one provider. The active gateway is switchable from the admin panel, so an outage at one provider does not stop sales.
Three locales really means three locales. Not just the interface: content, currency, sitemap and canonical URLs all branch by language.
Web and mobile share one codebase. The Android app in the store is built from the same repository, not a separate project.

What we did

The solution in six parts

Multi-vendor operator panel

Operator onboarding with document approval, listing/room/session management, calendar and capacity, participant lists, commission and payout tracking. Each guest is shown with the ticket type and price they bought.

Dynamic ticket tiers

Fixed age groups were removed; every session defines its own ticket types and prices. The "from" price on listing cards is derived automatically, with backward compatibility for older records.

Targeted coupons

Coupons can be scoped to a single listing or even a single ticket type; the basket calculates the discount on a partial subtotal and usage limits are enforced server-side.

Token-based refunds

A token balance driven by the operator's own tiered refund rates: a refund becomes balance, the balance is applied to the next purchase, and every movement is written to a ledger. Cash refunds run as a separate flow.

Payments and ticket delivery

3-D Secure card payments, guest checkout without an account, automatic confirmation email and a digital ticket the customer can keep on their phone. Successful sales land in the operations channel instantly.

Content, language and visibility

Turkish, English and Russian interfaces with per-locale content, sitemaps and canonical handling, plus a places-to-see guide and regional pages built for search visibility.

Components

What was built

114+ screens with role-based routing (guest · member · operator · admin)
45 server-side functions covering payments, 3-D Secure callbacks, coupon validation, email and reminders
125+ versioned database migrations across listings, bookings, orders, coupons, tokens and payouts
Queued email infrastructure with configurable batch size, delay and time-to-live, drained by a per-minute scheduled job
Row-level authorisation — a member sees only their own records, an operator only their own bookings
Hero preloading, component-level lazy loading and route-based code splitting for speed
Automated booking reminders and sales notifications
Mobile app published in the stores, released by the same team