SafeIgnite

Market insight

Drunk driving is a structural failure, not an awareness gap - every intervention (fines, cameras, checkpoints) acts after the vehicle has moved, with zero physical control at the one moment that matters: ignition. And the willingness to pay already exists.

Why B2B, non-negotiably

The person most likely to misuse the product - a drunk driver - will never buy it. The person who carries the liability - the fleet owner - will, because one incident means an insurance claim, legal exposure, and vehicle downtime with an immediate, computable ROI. Buyer and user are different people; only the buyer has skin in the game. That fact set the entire GTM.

Four decisions that shaped the product

1. Pairing can't be a dependency.

   The device had to enforce every safety rule offline - pairing became a one-way sync step, never a gate.

   Trade: More logic pushed onto the device, accepted because safety can't wait on a network.

2. A remote test never stops a moving car.

   A failed mid-journey check is logged and gates the next start, never the current drive.

   Trade: No instant enforcement, in exchange for never creating a worse outcome than the one being prevented.

3. Configurable timers, not fixed defaults.

   Ignition-window and reattempt-lock timers are admin-set. Validation surfaced the driver-replacement case - a sober replacement ready in 2 minutes shouldn't eat a fixed 20-minute lock.

   Trade: More configuration surface, for real operational fit across very different fleets.

4. No driver-management system in v1.

   The auto-captured test photo is the sole driver identifier - full accountability via photo + BAC + timestamp + location, without the profile system.

   Trade: Less structured driver data now, for a materially faster path to launch. Clean v2 once the core lock is proven.

Origin: reading the signal

SafeIgnite wasn't a blank-canvas idea. In mid-2025, running Parentalview (a school transport system), one small feature - an ignition interlock for school buses - pulled disproportionate inbound from operators and schools. That signal was loud enough to spin out as its own company. Catching that signal, and narrowing a whole company around it, is the kind of call I get hired to make.

The device: calm when sober, unmistakable when not

The device is the only surface a driver ever touches, often at night, sometimes about to drive. So the home state offers exactly two choices - Start Test and Settings - and nothing else. Every other state is produced by the flow, never presented upfront. The driver's job is: sit, blow, go.

• Ties to Decision 01 - Offline is a normal, calm state, never an error. The pair action stays reachable but never blocks; Start Test is always available first.
• Ties to Decision 02 - While driving, the screen freezes to a single quiet Engine Running state with no interactive controls that could distract or alarm a driver mid-road.
• Feedback runs on four channels at once - screen, ambient LED ring, audio prompt, haptic - so state is legible without staring at the display. Non-safe states use a soft white-to-color gradient: it informs without alarming someone who's done nothing wrong.

Web console: information architecture by urgency

The hardest design problem here wasn't visual - it was IA. An admin has many vehicles, many test types, many date ranges, many device states. Get the hierarchy wrong and they can't act when an alert fires. I structured it by urgency: fleet overview first, vehicle drilldown second, single-test detail third. Every high-stakes action is reachable in two taps.

• The 7-dot pattern on each vehicle row shows the last seven results as colored dots - an admin watching 50 vehicles spots a pattern (a run of reds) in seconds, instead of reading one last-status badge at a time.
• Ties to Decision 04 - With no driver-management system in v1, the vehicle-detail view uses the automatic test photo as the driver identity, beside BAC, timestamp, and map location.
• A remote diagnosis action answers a real objection we heard in validation - “what if the driver says the device isn't working?” - with ground-truth status instead of a standoff.

Mobile: built for the 2 a.m. alert

Mobile deliberately drops the dashboard charts. It's the surface for the moment of urgency - an admin gets an alert that a driver failed, and needs to act on one vehicle in seconds. Real-time alerts, one-tap on-demand retest, per-vehicle history. Speed of action here; depth of analysis on web.

• Ties to Decision 03 - The admin-set timers surface plainly, and the calibration runway (“tests left before service”) is visible in the home flow, so operators renew proactively rather than getting caught out.

The through-line

Every screen here traces back to a product decision. That's the work I do - sitting between the strategy and the pixels, so the thing that ships is the thing that was decided.

Next steps

1. Driver-management v2.

   Once the core lock behavior holds up in the field, layer in driver profiles and history on top of the existing photo-per-test record - without touching the accountability trail that already works.

2. Admin onboarding for the timer controls.

   Configurable timers are powerful but currently assume the admin already understands the trade-offs. Needs inline guidance or sane presets per fleet type (school run vs. 24/7 logistics).

3. Degraded-connectivity states on web and mobile.

   The device is offline-first; the admin surfaces aren't yet designed for “data hasn't synced in 6 hours” as a first-class state, only as an edge case.

4. Accessibility pass on the device UI.

   Next is validating legibility in direct sunlight and for colorblind users, since the color language is currently the primary signal across all three surfaces.

5. Design-system documentation.

   The cross-surface color and state language has been consistent by discipline, not by a documented system. Formalizing it now keeps that consistency from eroding as the team grows.