DEV Community: Jonas

One analytics codebase, three runtimes (web, native, offline)

Jonas — Wed, 29 Jul 2026 10:55:34 +0000

Here's a failure mode I was determined to avoid: the season page says a player shoots 62%, the live view says 58%, and the native app says 60% — all for the same player, same games. Three numbers, three slightly different implementations, zero trust.

This is post #3 in my build-in-public series about SportsFlow. The fix was to make the analytics a single thing that runs in all three places.

The shape: a pure-compute package

There's a package, @sportsflow/analytics, with one hard rule: no database dependencies, no DOM dependencies. It's just functions. Events in, numbers out.

match_event rows  ──adapter──▶  AnalyticsEvent[]  ──compute──▶  KPIs / heatmaps / momentum

Because it's pure, the same functions run in:

The web app — over data fetched via tRPC.
The native app (Expo) — same import, same results.
Offline, during live tracking — over the in-memory event queue, before anything has even synced to the server.

That third one is the payoff. The live "stats" tab during a game isn't a separate, simpler implementation that you hope matches the real one later. It is the real one, fed from local events. When the game ends and the data syncs, the season numbers are computed by the same code. No drift, by construction.

Decoupling from the database

The trick that makes this work is the AnalyticsEvent type — a DB-decoupled view of an event with all the metadata it needs resolved inline: which side it's for, whether it scores, the action type, whether the player is a goalkeeper. The compute functions never reach back into the database to look anything up. An adapter turns raw match_event rows (and custom-action definitions) into AnalyticsEvents, and from there it's all pure transformation.

This is the boundary that keeps the package portable. The moment a compute function needs a DB handle, it stops working in React Native and offline. So it never gets one.

The router only fetches

The tRPC analytics router does exactly one thing: fetch and filter. No aggregation lives on the server. It returns a match's events, players, lineups, and custom actions in a single roundtrip — and then the client computes everything with the shared package. (Every query is also scoped to the organisation ID as defense-in-depth, but that's about tenancy, not analytics.)

Keeping aggregation out of the router is what guarantees the server and the offline path can't diverge: there's no server-side math to diverge from.

One detail that bit me: position lives in context, not on the event

A subtle modelling call. A player's position (back, wing, pivot, goalkeeper) isn't stamped onto each event — it lives in an AnalyticsContext.playerPositions map, derived from the current roster. Why? Because position is a property of the player in the season, not of a single shot. Stamping it per-event would mean a player who switched positions retroactively corrupts old games, and you'd be duplicating mutable data across thousands of rows. Context-level is the correct altitude.

One more guard: `safeRate()`

Every percentage in the system goes through a single safeRate(made, total) helper. Sounds trivial, but "shooting percentage" with zero attempts is 0/0 — and a stray NaN rendered into a chart is the kind of bug that makes users distrust every number on the page. One helper, used everywhere, means division-by-zero is handled once and identically across all three runtimes.

What I'd tell past me

If a number must agree across surfaces, compute it in one place — and make that place portable enough to actually run on all of them.
Purity is a feature. No DB/DOM deps isn't an aesthetic; it's what lets the function run offline and on native.
Push the fetch/compute split to the router boundary. Servers fetch, clients compute. The server has no analytics opinions to disagree with.

Honest status: this layer type-checks clean and the architecture holds, but I still owe it a full manual verification against the legacy app's numbers on real tracked data. Build-in-public means admitting the test column isn't green yet.

Next (and last in this arc): the meta post — how one person ships web, native, marketing, and docs out of a single Turborepo without losing their mind.

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.