Shipping 4 apps solo from one Turborepo

Jonas — Mon, 20 Jul 2026 09:07:48 +0000

SportsFlow is four apps: a web app, a native (Expo) app, a marketing site, and a docs site. I'm one person. The only way that's sustainable is to make the four apps share as much as possible without coupling them into a tangle.

This is the final post in my build-in-public arc. It's the meta one: the conventions that let one brain hold the whole thing.

The layout

apps/
  web/        the product            (TanStack Start)
  marketing/  the public site        (TanStack Start, no auth/db/trpc)
  fumadocs/   the docs
  native/     mobile                 (Expo)
packages/
  ui/         design system + app-agnostic court geometry
  api/        tRPC router
  auth/       better-auth + org + stripe plugins
  db/         Drizzle schema + relations
  analytics/  pure-compute stats (runs everywhere)
  env/        t3-env validated config
  config/     shared tsconfig

Turborepo + pnpm. The pnpm catalog pins shared dependency versions in one place, so all four apps move in lockstep instead of slowly drifting into four different React versions.

Conventions are the real architecture

When you're solo, you can't rely on review to enforce consistency — there's no second person. So the rules have to be structural, the kind a type-checker or a linter catches.

Zod-first types. Every type is a zod schema + z.infer. No standalone interfaces anywhere. This isn't a style preference; it means runtime validation and compile-time types are the same artifact and can't drift. Value vocabularies live as code constants + zod, not Postgres enums — extending a list is a deploy, not a migration.

The tRPC procedure ladder. Authorisation is a staircase, and you physically cannot skip a step:

publicProcedure
  → protectedProcedure   (valid session)
    → orgProcedure       (active team + verified membership; injects orgId)
      → staffProcedure   (mutations; staff role only)

Every domain query filters on orgId, and orgProcedure is the thing that provides orgId to the context. You can't write a query that forgets tenancy scoping, because the scoping comes from the procedure you built on. Multi-tenant safety becomes a property of where you start, not a checklist you remember.

One design system, two consumers. packages/ui holds brand-locked, app-agnostic atoms — Button, ScorePill, PlayerChip — plus the court geometry: the SVG math for a handball court, goal zones, and play playback. Both the web tracking UI and the marketing site's live demos render the same court from the same geometry. The marketing animations aren't a reimplementation; they're the real component with demo data.

Billing stays out of the domain. Subscriptions are per team (referenceId = orgId) via better-auth's Stripe plugin. But domain tables know nothing about billing — tier limits live in one file (limits.ts, e.g. assertCanCreateMatch) called from the API. The schema never grows a plan column. If pricing changes, exactly one file changes.

What the monorepo buys me concretely

Change a type once. A field added to a zod schema in db ripples through the tRPC router, the web app, and the native app as type errors — a to-do list the compiler writes for me.
The same analytics run everywhere (see post #3) precisely because it's a shared package, not copy-paste.
Marketing has no auth/db/trpc at all. It's deliberately a different dependency graph — a fast static site that imports only the design system. The monorepo lets me share the look without sharing the weight.

What it costs

Honesty section. A monorepo isn't free:

Native is early. It's scaffolded and has a first cut of season analytics, but it lags the web app. Sharing packages helps, but React Native still needs its own UI primitives.
The better-auth schema is generated, which means a re-merge checklist every time (strip the old relations blocks, since relations live centrally for the new query builder). Generated code in a monorepo needs guardrails.
One person is still one person. The tooling multiplies what I can build; it doesn't multiply the hours.

The throughline

Across this whole series — offline-first capture, cross-platform analytics, this monorepo — the same idea keeps showing up: make the correct thing structural. Idempotency in the schema instead of the network. Tenancy in the procedure instead of the query. Types from one zod definition instead of two. Stats from one pure package instead of three implementations.

When you're solo, discipline you have to remember will eventually fail. Discipline the system enforces is the only kind that scales to one person building four apps.

Thanks for following the series. If you're building something in this space — live sports, offline-first, multi-tenant SaaS, solo — come say hi.

Hi, I'm Jonas — building a sports SaaS solo, in the open

Jonas — Mon, 29 Jun 2026 06:25:52 +0000

Hi 👋 I'm Jonas.

CS bachelor, Entrepreneurship master. By day I'm at nono. On the side I'm building SportsFlow solo — and I'm going to write about every hard part of it out in the open. This is the intro.

What I'm building

SportsFlow replaces the thing every amateur handball coach still uses: a clipboard and a pen.

The idea is simple. Live-track every shot, assist and save during the game on a phone or tablet, and get real season analytics out the other end — shooting percentages, heatmaps, goalkeeper saves, momentum, lineup impact. Handball first, then volleyball, basketball, ice hockey.

I sat on enough benches to know the problem is real: the data is right there in the game, and it evaporates the second the whistle blows. Nobody should need a spreadsheet and a good memory to coach with numbers.

Why I write about both code and product

I build at the seam between engineering and product — that's the CS + Entrepreneurship combo. So I won't only post architecture. I'll also post the decisions about what's worth building at all: where I drew scope lines, what I deliberately didn't build, how billing shapes the data model.

The recurring theme in everything here is one idea:

Make the correct thing structural.

Idempotency in the schema, not the network. Tenancy in the procedure, not the query. Types from one zod definition, not two. Discipline the system enforces, not discipline you have to remember — because when you're solo, the stuff you have to remember eventually fails.

What you'll get if you follow along

Biweekly build-in-public deep-dives, including the honest costs and not just the wins:

Offline-first capture — sports halls have zero WiFi, so the whole tracking pipeline works offline and reconciles later without double-counting goals.
One analytics codebase, three runtimes — the same shooting-percentage code runs in the web app, the native app, and offline during live tracking, so the numbers can never disagree.
Shipping four apps solo from one monorepo — web, native, marketing, and docs, and the conventions that make that sane for one person.

The stack

If that's your filter: TypeScript (zod-first), TanStack Start, tRPC, Drizzle, better-auth, Turborepo, Expo.

Come say hi

If you're building in live sports, offline-first systems, or multi-tenant SaaS — or you're a solo dev shipping more than one person reasonably should — follow along, and please come argue with me in the comments. The build-in-public part only works if it's a conversation.

First deep-dive drops soon.

DEV Community: Jonas