Case Study / 02

PitPulse: A Severe-Duty Maintenance Forecast for Working Drivers

A paid, privacy-conscious vehicle-health membership that turns a VIN, weekly driving pattern, and service history into a dated maintenance forecast.

The business problem

For an owner-driver, a vehicle is income equipment. Generic maintenance checklists do not account for severe-duty driving, weekly mileage, model-specific intervals, incomplete service history, or the consequences of a reminder system that sends too much noise. PitPulse needed to turn uncertain vehicle data into a trustworthy forecast, then carry that forecast through payment, persistent records, service logging, recalls, reminders, and cancellation without overstating what the data could prove.

02 / Strategy

Approach

01
Build the maintenance logic as a deterministic domain engine first, with vehicle attributes, driving pattern, time, mileage, service history, and explicit uncertainty all represented in typed data.
02
Treat the membership boundary as a product and database concern, not just a button state: setup can be explored temporarily, but saved vehicles, history, reminders, and export unlock only after Stripe confirms payment.
03
Design reminders around trust and repeatability — mileage-based identity, grouped digests, signed one-tap actions, and idempotent writes — so the service stays useful at the moment a driver is busy.

03 / Implementation

What I built and changed

A Maintenance Engine That Understands Working Cars

The schedule engine models 16 service types with applicability rules and intervals keyed to year, engine, fuel type, transmission, model overrides, driving pattern, and service history. It projects both due mileage and due date, then uses whichever arrives first.

Added hand-entered overrides for 15 high-volume models and applied severe-duty adjustments on top of those overrides rather than replacing them.
Used a 400-mile-per-week threshold to preselect severe duty for gig-level driving, while keeping the choice visible and overridable during setup.
Made powertrain logic explicit: EVs drop oil, plugs, air filter, belt, and transmission-fluid rows instead of showing a generic gas-car checklist.

A Setup Flow That Separates Preview From Ownership

The public journey starts with a VIN or manual vehicle selection, asks for the odometer and weekly driving pattern, and carries the temporary setup draft through authentication and Stripe Checkout without putting the VIN in a URL.

Decode and normalize vehicle data through the public NHTSA vPIC endpoint, including fuel type, powertrain, CVT detection, body class, and display-friendly engine data.
Keep setup answers in browser storage for up to 24 hours, then persist the vehicle only after the Stripe webhook confirms the subscription.
Use a single paid membership with $39/year emphasized, $4.99/month as the secondary option, and a 7-day refund promise rather than a free tier or trial.

A Paid Garage With a Real Data Boundary

Supabase is the live source of truth for paid members: vehicles, service logs, subscriptions, profiles, and reminders are mapped from the local domain model into account-scoped rows. The database enforces the entitlement boundary so the UI is not the security boundary.

Scoped reads and writes with Row Level Security and ownership checks, including the vehicle relationship on service logs to prevent cross-vehicle or cross-tenant access.
Used subscription-aware database triggers and policies so active or past-due members retain access while lapsed accounts retain deletion and data-control paths.
Kept the storage layer swappable: the localStorage branch remains only for migrating legacy garages, while the product model stays independent of its persistence provider.

Reminder Delivery That Stays Quiet and Idempotent

A scheduled Cloudflare Worker calls the existing reminder route, which builds timelines for subscribed users, selects the 14-day advance and 2-day final windows, groups nearby services into one digest, and sends through Resend.

Made the dedupe identity mileage-based — a fixed due key such as `m60000` — so projected dates drifting with the odometer cannot create a new reminder every day.
Insert the reminder row before sending and let the database uniqueness constraint act as the lock when cron retries or stages race.
Sign one-tap “I already did this” links with HMAC-SHA256 tokens scoped to one vehicle, service, and due instance; verify the signature before parsing the payload and make completion idempotent.

Safety, Privacy, and Honesty as Product Behavior

The project treats trust boundaries as user-facing behavior: customer analytics are disabled, VINs are stripped before storage, auth errors stay generic, and recall language distinguishes model-year data from a confirmed VIN-level repair status.

Normalize NHTSA recall data by cleaning shouted text, repairing Windows-1252 punctuation, deduplicating repeated components, and sorting do-not-drive and fire-risk flags first.
Keep card data on Stripe-hosted Checkout, require a shared 15-character password policy, and separate admin email authorization from the cron secret with an exact recipient allowlist.
Document remaining production checks explicitly — Supabase migrations, RLS integration coverage, webhook ordering, auth email delivery, and Cloudflare logging/cache review — instead of treating local tests as proof of deployment state.

04 / Outcomes

Business results

Completed a working vertical slice from landing page and real schedule preview through authentication, paid Stripe checkout, webhook-confirmed entitlements, garage records, service history, recalls, export, and reminder delivery.
Encoded 16 maintenance services, 15 model overrides, powertrain-specific applicability, severe-duty adjustments, mileage/date projection, and uncertainty-aware estimated states into a tested domain layer.
Built paid-only access into Supabase triggers and RLS rather than relying on client-side gating, with lapsed-account behavior and data-control paths documented as deliberate product states.
Reduced reminder noise through mileage-based dedupe, grouped due-point digests, two reminder stages, signed one-tap completion, and idempotent service-log writes.
Verified the core product behavior with 107 passing tests covering VIN handling, schedule math, severe duty, garage history, recalls, reminders, privacy controls, rate-limit keys, auth errors, and subscription state.
Delivered the app as a mobile-first PWA using Next.js, React, TypeScript, OpenNext, and Cloudflare Workers, with Supabase, Stripe, NHTSA, and Resend integrated behind explicit boundaries.

05 / Takeaway

What the work proved

The difficult part was not generating a maintenance checklist. It was deciding which facts were trustworthy, carrying those facts through a paid product boundary, and keeping the forecast useful as the vehicle's real history changed. The same discipline appears in every layer: model severe-duty driving instead of flattening it into a generic rule, mark estimates instead of inventing certainty, let the database enforce ownership, and make reminders idempotent instead of hoping cron runs only once. For a product that touches safety, money, and a driver's ability to work, correctness is the feature.