ChatOBD2
An AI car-diagnostics app, designed and built solo. In QA and field testing.
- Product surfaces built
- 3
- Token budget per scan
- 38k
- Reasoning layers before model call
- 6
- Designed and built by
- One person
- Scope
- Mobile app, marketing site, developer portal, backend pipeline
- Focus
- AI product design · Structured pipeline · End-to-end product engineering
A trouble code is not an answer
Diagnostic apps for cars are written by engineers for engineers. Codes, freeze frames, partial explanations, all surfaced raw. The driver staring at a screen is supposed to take all of that and produce a decision: drive it, don’t drive it, fix it now, fix it later.
The data is present, but the driver still has to turn it into a decision.
A verdict instead of a raw scan
ChatOBD2 returns a verdict instead of a raw scan.
The interface shows one verdict. Behind it, structured inputs go through layered interpretation, a constrained model call, and a constrained output. Every scan returns the same shape: is it safe to drive, how confident is the answer, what matters most, what to do next.
The model is one step in the pipeline. The output is schema-bound before it reaches the UI.
Three constraints that shaped the verdict
The verdict comes first, before any text. When a scan finishes, the safe-to-drive answer renders first. Full-width, color-coded, ahead of every paragraph. The tradeoff is less explanation, but the answer is visible in under a second.
Confidence is part of the answer. A partial scan changes what the verdict means. Showing scan quality costs some optimism but makes the result honest.
Prompts live in one module. If they are scattered across components, a copy change touches many files and the analytics fall out of sync. One module, keyed by verdict tier and code context, means one change updates the product.
How the system works
Chat surface as the home screen. Verdict card as the unit of output. The model held as one structured stage between deterministic input and constrained output.
The interface stops asking the driver to interpret data and starts telling them what to do next.
This is the moment the system stops exposing complexity and starts resolving it.
From data to decisionWhat a scan returns
Run a scan. Anything I should worry about?
One pending code, no immediate action
P0420 (catalyst efficiency) is logged but not active. Drivetrain pulled clean across two cycles. Re-scan in 200 mi.
- P0420 Catalyst efficiency below threshold
- 12 systems Healthy across drivetrain & emissions
Data becomes understanding
Same premise, different format.
The marketing site carries the same product premise into a public-facing surface. Same "verdict comes first" instinct, same constraint thinking. Designed and built end to end. Visual exploration where it helped, hand-written code everywhere else.
The pipeline behind the verdict.
Six deterministic reasoning layers run before every model call. The system prompt is composed per scan from a 38,000-token budget, with P0 sections always included and lower-priority sections added only if budget remains. BLE adapter integration. Write operations with rollback. I treated the developer site as a designed product, with the same care as the app.
