Work

Systems in production, not portfolios of mockups

Everything below is shipped and running for real clients. Much of our work is under NDA — we protect our clients' confidentiality as carefully as their systems — so names are withheld and identifying details are blurred. The architecture, the constraints and the outcomes are real, and we go deeper in conversation.

01

Real-time platform

Live scoring for moments that can't lag

A multi-sport live-scoring platform where fans, broadcasters and sponsors all watch the same second — and every organisation gets its own branded property on one codebase.

Read the full study ↓

02

Tournament operations

Match-day operations at national scale

A multi-application estate — offline-first data capture for match officials, tournament operations, identity and admin — run as one production system through years of live professional fixtures.

Read the full study ↓

03

Marketplace

A booking marketplace, end to end

Consumer mobile app, business portal and API for a services marketplace — bookings, payments, notifications and media, delivered by one team on one budget.

Read the full study ↓

Under NDA

The names are confidential. The engineering isn't.

We'll walk through architecture, decisions and numbers in a call.

01 · Real-time platform · confidential client

Live scoring for moments that can't lag

A multi-sport live-scoring platform where fans, broadcasters and sponsors all watch the same second — and every organisation gets its own branded property on one codebase.

  • FastAPI
  • PostgreSQL
  • Redis
  • SSE
  • React
  • ECS Fargate
  • CloudFront

The challenge

Live sport punishes latency. Scores must reach every screen the instant they happen, through traffic spikes, without polling storms — and each organisation using the platform wants its own look, its own domain, and its own sponsors.

What we built

A unified scoring platform serving multiple professional sporting codes: scorer consoles for matchday officials, public live sites for fans, and an admin CMS for competitions — with white-label theming and custom domains resolved per tenant.

Architecture

  • Python / FastAPI API with PostgreSQL and Redis; scoring writes publish to Redis pub/sub and fan out over server-sent events — the hot path never touches the database
  • React 19 CMS and public sites, with live caches updated in place so a score never triggers a refetch storm
  • Containers on AWS ECS Fargate behind CloudFront, with WAF, secrets management and OpenTelemetry tracing
  • Serverless video pipeline: uploads transcoded to HLS with event-driven callbacks
  • CI/CD via GitHub Actions with OIDC — build, scan, migrate, deploy, smoke-test

Outcome

  • Sub-second updates on live matchdays, by architecture — no polling anywhere
  • Multiple branded properties running on a single codebase
  • 600+ automated tests gate every change before it ships

02 · Tournament operations · confidential client

Match-day operations at national scale

A multi-application estate — offline-first data capture for match officials, tournament operations, identity and admin — run as one production system through years of live professional fixtures.

  • Flutter
  • React
  • Python
  • PostgreSQL
  • Redis
  • AWS
  • Firebase

The challenge

Officials score professional fixtures inside venues where connectivity is unreliable at best. The data they capture feeds competitions, standings and fan-facing products — so nothing can be lost, duplicated or delayed.

What we built

A Flutter scoring app that captures every event locally and syncs safely when a connection returns, a web portal for tournament operations — fixtures, teams, officials, standings, reporting — and the Python APIs that keep the whole estate in step.

Architecture

  • Flutter mobile app with an embedded local store — full matches scored with zero connectivity, conflict-safe sync afterwards
  • React tournament portal for competition operations and reporting
  • Python REST APIs with PostgreSQL, Redis and search indexing
  • AWS estate — containers, CloudFront, managed PostgreSQL — plus a realtime layer for fan-facing scores
  • App-store distributed, with a long, versioned release history

Outcome

  • Seasons of live professional fixtures scored in production
  • Offline-first design proven in venues with no signal
  • Continuous delivery cadence across mobile, web and API

03 · Marketplace · confidential client

A booking marketplace, end to end

Consumer mobile app, business portal and API for a services marketplace — bookings, payments, notifications and media, delivered by one team on one budget.

  • Flutter
  • Next.js
  • FastAPI
  • PostgreSQL
  • Stripe
  • Terraform
  • AWS

The challenge

A services marketplace needed three surfaces at once — a consumer app, a portal for business owners, and the backend to run both — with payments, scheduling and notifications, and a cloud bill that wouldn't outgrow the business.

What we built

A Flutter consumer app for discovery and booking, a Next.js management portal for business owners — profiles, catalogues, hours, bookings, analytics — and a FastAPI backend handling auth, availability, payments and geo search.

Architecture

  • FastAPI backend with PostgreSQL and Redis; JWT auth with role separation for consumers and business owners
  • Stripe payments, push notifications, and S3 + CloudFront media delivery
  • Next.js portal on AWS Amplify; API served through CloudFront
  • Target architecture designed as Terraform — ECS Fargate, managed Redis, secrets, budget alarms — with documented runbooks

Outcome

  • Three production surfaces — mobile, web, API — from a single team
  • Payments, notifications and media handled end to end
  • A documented, cost-guarded path from launch infra to scaled infra

Why no logos or screenshots? Our client work is under NDA, and we treat confidentiality as part of the engineering. Every claim on this page is recorded with its evidence — ask, and we'll walk you through it.

Start that conversation →