Building GigXchangeHow a working musician shipped an entire marketplace — the build story and method
Executive summary
GigXchange was built by its founder — a working UK musician — using an AI-assisted development method on a deliberately boring stack (SvelteKit, PostgreSQL, Cloudflare, Stripe). The result documented in the public timeline: a full marketplace, two native apps, a monthly data product and three national directories, shipped in months at a fraction of conventional startup cost.
Why this build economics matters to the investment case: Why now.
The method
GigXchange is founder-led and AI-assisted: the founder directs product, priorities and quality bars; AI agents execute implementation, testing and review under explicit written rules. The method is disciplined rather than improvised — engineering policy is written down and machine-enforced, with deploy gates that block regressions in type safety, database security posture and architectural drift. Updates ship most weeks, each recorded on the public release notes page.
The engineering posture
- Boring, proven stack — SvelteKit on Cloudflare Workers, PostgreSQL via Supabase, Stripe for payments. No exotic dependencies to maintain.
- Robust-and-lean over broad-and-fragile — an explicit standing policy: consolidate before adding, delete dead code aggressively, one canonical mechanism per job.
- Security as a gate, not a hope — row-level security on every table, least-privilege grants verified by automated tests, and hard rules that block destructive operations.
- Verification by design — features carry code review, security review and automated tests scaled to their risk before they count as done.
Why the build story matters to investors
Two reasons. First, cost structure: the surface area shipped would conventionally require a funded engineering team; here it is sustained by one founder plus AI leverage, which is what makes a fragmented, modest-ticket market economically serviceable (the timing argument). Second, credibility of execution: the shipping record is public and dated — an investor can verify velocity from store listings, release notes and monthly reports rather than take it on trust.
Built by a member of the market
The founder has gigged on the UK circuit since 2009 and still does. Product decisions come from lived failure modes — the unanswered DMs, the handshake deposits, the no-show with no recourse — which is why the workflow handles cancellations, emergency cover and payment protection as first-class features rather than afterthoughts. The origin story is told in Why GigXchange exists.
