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. 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.
