The premise
Most diagnostic tools assume the user already knows how to interpret them. They don’t.
That’s not a polish problem. It’s a translation problem.
Codes, freeze frames, partial explanations. The data is technically present, but the user is left to assemble it into an answer. The tool exposes complexity instead of resolving it.
That gap is the actual problem.
A different idea
ChatOBD2 is built around a different premise: diagnostics should explain themselves.
The interface is intentionally simple. The system behind it isn’t.
It pairs structured diagnostic inputs with layered interpretation and AI-assisted reasoning, and it constrains the output. Every scan returns the same shape: is it safe to drive, how confident is the answer, what matters most, what to do next.
This is where AI earns its keep. The model’s job is reducing complexity, not generating content.
Three decisions that shaped the product
The verdict comes first, before any text. When a scan finishes, the safe-to-drive answer is the first thing rendered, full-width and color-coded, ahead of every paragraph. The tradeoff is less narrative warmth, but anyone glancing at the screen has the answer they came for in under a second.
Confidence is part of the answer. A partial scan changes what the verdict means. Showing scan quality as a fixed bar instead of hiding it costs a small piece of optimism, but earns a much larger piece of trust. It’s the kind of decision a less-confident product wouldn’t make.
Prompts live in the system, not in components. When prompts get scattered across components, every copy change is a hunt across N files, and the analytics taxonomy quietly drifts behind it. Pulling them into one module, keyed by verdict tier and code context, means a single change updates the whole product, and the analytics stay coherent across it.
The shape of the system
Chat surface as the home screen. Verdict card as the unit of output. AI in the middle of the pipeline, constrained by structure on either side.
The interface stops asking the driver to interpret data and starts telling them what to do next.
What 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 with Claude Design and Claude Code.
The dev surface gets the same care as the product.
ChatOBD2 has grown into a substantial codebase. Six deterministic reasoning layers in front of every model call, an AI prompt assembled by priority from a 38,000-token budget, BLE adapter integration, write operations with rollback. Holding that together is the actual job.
Claude Code maintains the developer portal continuously as the codebase moves. Module ownership stays current. System diagrams regenerate when contracts change. Dev UX is held as a product-quality bar, not an afterthought. The aim is simple: anyone landing in the repo can find the thing they need without reading it through.