Platform ArchitectureThe technical shape, at the level investors need — boring by design
Executive summary
GigXchange runs on a deliberately boring, proven stack: SvelteKit applications on Cloudflare's edge network, PostgreSQL via Supabase with row-level security throughout, and Stripe for all payment flows. One web codebase also ships the native iOS and Android apps. The architectural bet is robust-and-lean over broad-and-fragile — enforced by policy and automated gates, not aspiration.
How the build method exploits this architecture: Building GigXchange.
The stack, in one paragraph
The public website and the logged-in product are SvelteKit applications served from Cloudflare's global edge network — fast everywhere in the UK without capacity planning. Data lives in PostgreSQL (via Supabase) with row-level security on every table and business logic in audited database functions. Stripe handles every payment flow — protected payments, payouts, tickets — so card data never touches GigXchange. The native iOS and Android apps wrap the same codebase, so features ship to web and both stores from one implementation.
The architectural principles
- Serverless edge, no fleet — no servers to size, patch or babysit; traffic spikes are absorbed by the platform layer.
- One canonical mechanism per job — a standing anti-entropy policy: duplicate paths are collapsed, dead code deleted, every state change routed through a single guarded write path.
- Security in depth — row-level security everywhere, least-privilege grants verified by automated tests, and hard blocks on destructive operations.
- Degrade gracefully — public pages render even when a data call fails; every data failure is logged into an operations dashboard rather than swallowed.
Why boring is the strategic choice
Every exotic component is a maintenance liability and a hiring constraint. A proven, widely-documented stack maximises what AI-assisted development can execute reliably, minimises the surface a small team must keep in their heads, and keeps infrastructure cost near-negligible relative to the market served — which is precisely what makes a fragmented, modest-ticket market economically serviceable (the cost-structure argument).
What scales and what would need investment
The serving layer scales with the platform providers, and the database has ample headroom for orders of magnitude more bookings. Honest constraints: single-founder operational dependency (mitigated by written, machine-enforced process — and named plainly in the thesis risks), and human-scaling of things machines can't do alone, like directory verification. Scale economics are covered in Scaling strategy.
