A public acquisition product and private operating system I built to carry automotive service work from enquiry through job state, notifications, and digital warranty delivery.
Visit live product
Public customer interface. Private operational screens and customer data are intentionally excluded.
Observed in production
Evidence, with a date attached.
GA4 and GSC snapshot for 29 June–26 July 2026. AI referral sessions are observed GA4 referrals for 19–25 July 2026. Customer, vehicle, financial, and private operations data remain excluded.
- GA4 sessions · 28 days
- 2,401
- GSC clicks · 28 days
- 750
- AI referral sessions · 7 days
- 9
Context
The product behind the interface.
Context
Automotive protection work continues after the first enquiry. A job moves through customer details, vehicle details, service work, follow-up messages, and warranty delivery.
Problem
If each step lives in a message thread or separate note, operators lose the job state and customers receive inconsistent follow-up. Notifications also need to survive provider failures.
My role
I designed and implemented both sides of the product: the public service and lead journey, plus the private job and warranty lifecycle, notification delivery, retry behavior, and relational data behind operations.
Public product evidence
More than a homepage.
These public screens show the product flow and presentation. Private operations, customer records, and administrative data stay out of the case study.
What I built
A complete working flow.
- A job lifecycle for customer, vehicle, service, and status information
- A durable SMS outbox created with the job record
- Asynchronous delivery with retry and dead-letter handling
- Token-based digital warranty creation and delivery
- Email and SMS notifications tied to operational events
- A public acquisition experience separated from private customer data
- 01Job created
- 02Notification queued
- 03Response returned
- 04Delivery attempted
- 05Retry or complete
- 06Warranty issued
Product and technical decisions
The choices that shaped the system.
Do not block a job on SMS
The system records the job and notification intent first. Delivery happens after the core response, so a provider failure does not lose the business event.
Make retries visible
A queued notification has an explicit state and retry path. Repeated failures move to a dead-letter state instead of disappearing inside a generic error log.
Keep portfolio evidence privacy-safe
The case study shows public product surfaces and system design. Real dashboards, vehicle details, customer records, and financial data stay private.
What the system enables
What the system makes possible.
- Job and notification state traceable through one operational system
- Messaging failures separated from the core job-creation path
- Warranty delivery generated from a controlled record
Challenge
Small-business software still needs durable behaviour. Provider outages and repeated actions are production cases, not edge cases to ignore.
What I learned
A lightweight queue and explicit states can add more reliability than tightly coupling every external action to the request that triggered it.