Bike Assistant
Keep every part in sync
A SaaS that auto-tracks wear on every component of your bikes from your ride data, then predicts and reminds you when parts need service — the maintenance layer Strava never had. Now in closed beta, ahead of a public MVP launch.
- Role
- Co-founder · full-stack (backend, data, APIs & front-end)
- Stack
- Next.js 16 · React 19 · TypeScript · TanStack Query · Zod · Node / Express · Supabase · Tailwind · Storybook · Chromatic · Strava API · Vercel · Railway · Cloudflare
The problem
Strava tracks your rides, but nothing tracks your bike. Chains need re-waxing on a schedule, drivetrains and tyres wear out by distance, and across a few bikes it’s impossible to remember what’s due. Riders find out when something fails on the road.
The idea
Bike Assistant treats every component as a tracked part with its own wear budget. It imports ride distance automatically from Strava, attributes that distance to the right bike and parts, and surfaces smart reminders — chain re-wax, replacement windows — plus analytics like cost-per-km and fleet health across multiple bikes.
Under the hood
Not one app — a system
Ride data flows through a deliberately lean, multi-service architecture. Each stage is its own deployable, wired together by a single typed contract.
Strava in → a maintenance plan out.
The typed API boundary both sides build against — one versioned source of truth, no drift.
Domain-organised service — sync, ingestion, gear, rides, maintenance — plus the Strava pipeline.
The app itself: a TanStack Query data layer and real-mode part & maintenance flows.
Published @bike-assistant/ui component library with visual-regression testing.
Schema, environments and the dev → prod path the whole system deploys along.
Each repo is typed and tested in isolation — Vitest and Node's native test runner, visual-regression gating on the design system via Chromatic, all enforced in GitHub Actions before anything ships.
Closed-beta preview
What it looks like today
The dashboard surfaces your last rides, an overdue chain-wax alert, and live per-part wear across every bike — all derived automatically from Strava, with nothing to log by hand. The same view scales from this mobile PWA to a full tablet and desktop layout.
Designed by my co-founder · in active development ahead of the public launch.
What I own
I co-founded the product with a design/product partner who owns design and UX. I own the data path end-to-end — and increasingly the engineering that turns the design into a working app:
- An idempotent, resumable Strava ingestion pipeline — OAuth, webhooks for automatic sync, cursor-based fetching and a background job runner that can recover mid-run without double-counting distance.
- A modular TypeScript/Express service over Supabase (Postgres, Auth, Realtime), organised by domain — sync, ingestion, gear, rides, maintenance — behind a Zod-typed, contract-first API boundary shared with the front end.
- The data model that maps activities → bikes → parts → wear — chains-as-parts, wax cycles, sealant and service intervals — which everything else builds on.
- Front-end implementation: wiring the PWA to the live backend — the TanStack Query data layer and the real-mode part-, maintenance- and settings flows (lifecycle, history edit/delete, sync) — on top of our shared design system.
The bigger idea
Built two people deep — with a fleet of agents
Bike Assistant isn't only the product — it's how it's built. The whole system is engineered so that people and AI agents ship the same product together: two founders and several AI tools work this multi-repo codebase every day through one shared setup. The contract-first, multi-service shape above isn't incidental — it's exactly what makes parallel human-and-agent work safe.
For me it's proof of what product work can be today: when product thinking, product engineering and creativity meet the willingness to dig deep and stay consistent, an idea turns into a system that actually runs. That mix — far more than any single tool — is what makes something like this possible.
A tool-agnostic entry file loads the right role, conventions and permissions per person and per agent — not one generic prompt.
Progressively-disclosed skills and live tool access — Linear, Supabase, Railway, Vercel, Figma — so agents act on the real system, not a description of it.
Interfaces are agreed and published before the consuming work starts, so async handoffs between people and agents never drift.
One issue, one branch, one PR — and an independent agent reviews the work behind merge-safety gates before any human merge.
Status
In closed beta with a small group of pilot riders. The marketing site is live, and the API and app run on our cloud infrastructure ahead of the production cutover. We’re a two-founder team heading into a public MVP launch in the coming weeks — so I frame this honestly as co-owned: product design is my co-founder’s, while the data, backend and the app’s real-mode engineering are mine.