Building for real scale from day one

One of the decisions that defines a startup is how much infrastructure to build upfront versus how much to skip "for now". We made a deliberate choice: build for real scale from the start, even if we're not there yet. Here's why, and what that means in practice.

The stack

TripLike runs on Next.js 16 (App Router) on Vercel's edge network. API calls fan out in parallel — flights from Duffel and hotels from LiteAPI — and are optimised server-side before the client sees a result. We use Supabase (PostgreSQL with row-level security) for user accounts, booking history, and wishlist data. Emails go out via Resend.

Real payments, real providers

We use Stripe for payment collection (PCI SAQ-A compliant — we never touch raw card data). Duffel acts as the merchant of record for flights, which means we don't need an IATA license to sell airline tickets. LiteAPI handles hotel payments via their Account Credit Card model. For the customer, it's one payment. Behind the scenes, the plumbing is solid.

Test-to-live in one variable swap

Everything is built so that going live means swapping three environment variables: DUFFEL_ACCESS_TOKEN from a test token to a live token, LiteAPI from sandbox to production, and Stripe from test keys to live keys. The code doesn't change. The product is the same. We built it this way intentionally so that the engineering work is done before the commercial work is done.

What we learned

Building this way forced us to confront the real complexity early: multi-passenger booking flows, price-change guards, cancellation policy parsing, idempotent retries, rate limiting, proper money formatting (no floating-point surprises). It also meant every investor demo runs the same code that will run in production. There's no demo mode — just the product.