Skip to main content
All case studies

Product Strategy, UX & Full-Stack Systems

PitPulse: A Maintenance Forecast for Working Drivers

A paid vehicle-health product that turns VIN data, mileage, and driving intensity into an actionable maintenance forecast for people whose cars generate their income.

Role
Solo Product Designer & Full-Stack Developer
Project span
Active product build · vertical slice
PitPulse vehicle maintenance forecast social preview

The challenge

A rideshare or delivery driver can lose a shift when a vehicle issue appears without warning. Generic maintenance checklists do not account for severe-duty mileage, different powertrains, or incomplete service history, and a system that pretends to know more than it does will not earn trust. PitPulse needed to make the next maintenance action clear while keeping its estimates, billing boundaries, and vehicle data honest.

The approach

  • Start with the driver's economic reality: position maintenance as a way to protect earning capacity, not as a hobby or a long list of automotive facts.
  • Turn sparse inputs into a useful forecast — vehicle identity, current odometer, weekly mileage, driving type, and whatever service history the driver actually knows.
  • Make uncertainty visible: distinguish estimated history from known service logs, show whether mileage or time drives a recommendation, and send users back to the owner's manual when guidance is generic.
  • Treat the product as a complete action loop: forecast the work, remind the driver, let them mark it complete, and use that new record to improve the next forecast.

What was built

01

An Onboarding Flow Built Around Real Inputs

The setup flow accepts a 17-character VIN or a manual year, make, and model selection, then confirms the decoded vehicle profile before asking for the information that changes the forecast.

  • Show year, make, model, engine, body, drivetrain, transmission, fuel, and horsepower with warnings when the vehicle data is uncertain.
  • Collect current odometer mileage, weekly mileage, driving type, and an optional last-oil-change mileage.
  • Keep the draft available across authentication and hosted checkout for a limited period, without saving the vehicle until payment is confirmed.

02

A Maintenance Engine That Adapts to the Vehicle

A reusable schedule engine covers 16 maintenance categories and combines general service rules with powertrain classification, severe-duty factors, and hand-entered overrides for common models.

  • Calculate due mileage and due date, then use whichever arrives first so a low-mileage driver is not forgotten by a purely mileage-based system.
  • Adjust service intervals for high-mileage rideshare and delivery use while allowing the driver to override the initial driving-type suggestion.
  • Remove services that do not apply to EVs and hybrids while preserving relevant tire, brake, cabin-filter, battery, and inspection guidance.
  • Use a bounded estimate when history is missing instead of inventing an overdue service, and replace the estimate when the driver logs known work.

03

A Paid Garage With a Clear Entitlement Boundary

After Stripe confirms an active or past-due membership, the driver gets a persistent garage for multiple vehicles, maintenance timelines, service history, recalls, reminders, and cost-per-mile context.

  • Keep Stripe Checkout and card handling hosted, while resolving accepted plan choices and price IDs on the server.
  • Use Supabase Row Level Security and server-side subscription checks so a client-side success screen cannot grant access by itself.
  • Give the garage operational views for what is due, what was logged, which recalls affect the model, and how the vehicle's maintenance costs relate to its working mileage.

04

Reminders Designed to Close the Loop

A daily Cloudflare scheduled job groups upcoming and overdue services into digest emails instead of sending one message per task. Each reminder includes a signed, expiring action link that can record completion without requiring a login.

  • Deduplicate reminders by service and due instance so estimated-date drift does not create repeated messages.
  • Insert the reminder record before attempting delivery, then track the action so an email failure cannot silently erase the underlying task.
  • Use scoped HMAC tokens, expiry checks, idempotent action keys, and service-log updates so repeated clicks remain safe.

05

Privacy and Trust as Product Features

The product treats vehicle identity and subscription state as trust-sensitive data. VINs are used for lookup but removed before long-term storage, while model-based recall guidance is kept separate from VIN-specific recall status.

  • Send the VIN to the vehicle-decoding service without retaining it in the user-facing vehicle record.
  • Use year, make, and model for recall lookup, then link drivers to the official NHTSA VIN checker for VIN-specific status.
  • Provide reminder controls, export, billing access, and deletion paths so users can understand and manage their relationship with the product.

Results

  • Implemented an end-to-end product path from vehicle identification and forecast preview through paid access, persistent garage records, reminders, and service completion.
  • Built one schedule engine that can power the marketing preview, onboarding, vehicle timeline, and automated tests instead of maintaining disconnected versions of the same logic.
  • Made uncertainty explicit through estimated-history labels, manual-date prompts, model-based recall language, and owner-manual guidance.
  • Added server-enforced subscription boundaries, privacy-conscious VIN handling, signed reminder actions, and idempotent service logging.
  • Verified the current repository test suite with 107 passing tests and no failures. No user, revenue, retention, or downtime-reduction metrics are claimed because they are not present in the project files.

Working through something similar?

Tell me what the business needs to do, and I'll tell you what it would take to build.

Start a project conversation