Full case study

Hey everyoneđź‘‹,

I am Aniket Budhwani, CPO @SafeIgnite

Digital marketer turned Product Designer / Manager. I run design and tech.

Case study 01 · Pitch walkthrough

SafeIgnite

Live pilot

An ignition interlock that stops a vehicle from starting if the driver isn't sober - plus the surfaces a fleet runs it from.

RoleCo-Founder & CPO
TeamCEO, CTO + 3 Devs
SurfacesDevice · Web · Mobile
StatusIn pilot · 20 vehicles
The problem

Drunk driving is a structural failure, not an awareness gap.

Every intervention today acts after the vehicle moves.

  • Fines & checkpoints - punish after the fact.
  • GPS & dashcams - record, never prevent.
  • Nothing sits at ignition - the last point it can still be stopped.
Backed by MoRTH report

10 – 15×

India loses that much to crashes versus what it spends preventing them. The money exists. The prevention layer doesn't.

Govt road-safety spend₹20,000+ crPer year
Fleet spend₹20–30kPer vehicle / year
Accident losses₹2–3 lakh crPer year
Positioning

Why B2B, non-negotiably.

USER

The driver

Never the buyer. Wants to defeat it, not buy it.

BUYER

The fleet owner

One incident = claim, legal exposure, downtime. ROI is computable.

Buyer and user are different people. That one fact set the entire GTM.

Go-to-market

Target by buying trigger, not by industry.

01

Schools

Reputational. One incident ends trust.

02

Logistics fleets

Pure ROI on downtime and claims.

03

Bus & taxi

Liability plus regulatory pressure.

04

Corporate fleets

Duty-of-care and insurance leverage.

Sequencing: paid pilots with high-liability operators → fleet-wide rollout, expansion agreed pre-pilot → insurers and regulators shorten the cycle → OEM certification and factory fit.

Four decisions that shaped the product
DECISION 01

Pairing can't be a dependency.

Every rule enforced on-device. Pairing syncs; it never gates.

More logic on-device. Safety can't wait on a network.

DECISION 02

A remote test never stops a moving car.

A failed mid-journey check gates the next start.

No instant enforcement. Never cause a worse outcome than the one prevented.

DECISION 03

Configurable timers, not fixed defaults.

A sober replacement driver shouldn't eat a fixed 20-minute lock.

More config surface, for real fit across very different fleets.

DECISION 04

No driver-management system in v1.

The test photo is the identifier. Photo + BAC + time + location.

Less structured data now, for a much faster launch.

Surface 01 · Device

Calm when sober, unmistakable when not.

The only surface a driver touches, often at night. Home offers two choices: Start Test and Settings. Sit, blow, go.

  • Decision 01 - offline is a calm state, never an error.
  • Decision 02 - while driving, the screen freezes to Engine Running. No controls.
  • Four feedback channels - screen, LED, audio, haptic. State is legible without looking.
Drag to rotate · six on-device states. Enclosure is a stand-in; shipping form is under patent filing.
Surface 02 · Web console

Information architecture by urgency.

Not a visual problem - an IA one. Fleet → vehicle → single test. Every high-stakes action is two taps away.

  • 7-dot pattern - last seven results per vehicle. A run of reds is visible across 50 vehicles at a glance.
  • Decision 04 - the test photo carries identity, beside BAC, time and map location.
  • Remote diagnosis answers "the driver says it's broken" with ground truth.
Surface 03 · Mobile

Built for the 2 a.m. alert.

No dashboard charts. An admin gets an alert and acts on one vehicle in seconds.

  • Real-time alerts, one-tap retest, per-vehicle history.
  • Decision 03 - admin timers and the calibration runway sit in the home flow.
  • Speed of action here. Depth of analysis on web.
Competitive moat

Nothing on the market prevents at ignition, priced for India.

Gap in existing options SafeIgnite's answer
Dräger / Intoxalock / LifeSafer - US court-mandated, expensive, blow-suck-blow pattern Indian users reject
Single-blow pattern, priced for commercial fleets
GPS trackers, dashcams - record, never prevent
Physical ignition gate - stops the event
No India-specific hardware
Built for Indian climate extremes, with a fleet admin layer none of them have
Business model

Pricing shaped the product, not just the deck.

Device~₹28,000+ GST per vehicle
RecurringAMCCalibration, service, uptime
Renewal cueIn-product"Tests left" countdown
  • Mobile counts down tests to recalibration - admins renew before sales chases.
  • Economic View turns a fleet's own test data into costs avoided - they sell it to their CFO with our numbers.

If a business model needs a human to explain it every quarter, the product hasn't absorbed it yet.

Origin

One feature pulled harder than the product around it.

Mid-2025, inside Parentalview: an ignition interlock for school buses pulled inbound from operators far outside the school market.

Loud enough to spin out as its own company. Catching that signal and narrowing a company around it is the call I get hired to make.

What's next

Five things I'd ship next.

01

Driver-management v2

Profiles layered on the photo-per-test record, without touching what works.

02

Onboarding for timers

Config assumes the admin knows the trade-offs. Needs presets per fleet type.

03

Degraded-connectivity states

"No sync in 6 hours" isn't yet a first-class state on the admin surfaces.

04

Accessibility on the device

Sunlight legibility, colorblind validation. Color is the primary signal everywhere.

05 · Design-system docs - the cross-surface color and state language is consistent by discipline, not by a documented system.

Where it stands

In the field, on real fleets.

Vehicles live20Pilot deployment
FleetsOperators in pilot
Tests loggedSince pilot start

What the field changed:

A pilot buys the one thing a lab can't: how the device behaves with a driver who'd rather it didn't work.

The through-line

Every screen traces back to a decision.

The work is sitting between the strategy and the pixels, so what ships is what was decided.

Case study 02 · Pitch walkthrough

Parentalview

Sunset

A school automation ecosystem I co-founded - seven connected surfaces across web, mobile and hardware. And the product SafeIgnite spun out of.

RoleCo-Founder & CPO
TeamCEO, CTO + 9 Devs
Surfaces7 - Web · Mobile · Hardware
StatusPhase 1 built · Phase 2 roadmapped

No longer in active development - the company pivoted to SafeIgnite, which began as one feature inside this product.

The problem

Indian schools aren't automating. They're only digitizing.

Paper became basic apps. The structural problems stayed put.

01

Overwhelmed admins

Buried in manual paperwork.

02

Disconnected comms

Parents out of the loop.

03

Manual processes

Attendance, grading, scheduling.

04

Transport chaos

No live visibility during the commute.

Sharpest version sits in transport. GPS and dashcams monitor. None of them prevent.

The stakes

Preventable, and nobody is preventing it.

Preventable90%Of school-transport incidents
Leading causesAlcohol · fatigueDriver-side, not road-side
Existing toolsMonitor onlyRecord after the fact

If the cause sits with the driver before the bus moves, the intervention has to sit there too - not in a dashboard read later.

Positioning

Automation, not digitalization.

Mapped against Edunex, Campus 365 and the rest: every player crowds one corner - digitizing records and messaging.

We took the open quadrant: automated safety with prevention built in.

That one call shaped the hardware strategy, the pricing model and all of Phase 1.

Safety · DigitalizationGPS, dashcams - record, act on nothing
Safety · AutomationParentalview - prevention inside the vehicle
Communication · DigitalizationThe crowded corner - notice boards, fee portals
Communication · AutomationEvent-driven updates, no physical control

DigitalizationAutomation

Vertical axis: communication (bottom) → safety (top)

Scope

Why Phase 1 is transport, and only transport.

01

Anxiety is the buying trigger

The highest-emotion touchpoint a school owns. Solve it and the loudest stakeholders become champions.

02

Hardware is the moat

Alcohol, fatigue, seatbelt and door alarms, ADAS. Software-only rivals can't follow without becoming a different company.

03

Daily usage compounds

Two rides a day, so the parent app opens twice a day - the base Phase 2 plugs into.

Sequencing: Phase 1 (2025–26) transport across Tier 1–2 → Phase 2 (2026–28) expand each account into the full school OS.

What I built - Phase 1

Not one app. Seven role-specific surfaces, one backend.

Ecosystem map - seven surfaces sharing one backend and one design language

School panel · Super admin · Bus app · Parent app · Guard app · Support & sales · Breathalyzer interface - all designed by me, sharing identity, state colors and notification grammar.

Five decisions that shaped the system
DECISION 01

Prevent, don't monitor.

Alcohol detected, the bus doesn't start. The admin gets an alarm, not a log.

Hardware complexity. Monitoring-only is where every competitor stops.

DECISION 02

Hardware inside the subscription.

Device, install, maintenance, replacement - one monthly per-student fee.

We carry the capex, for recurring revenue and a shorter sales cycle.

DECISION 03

Role-specific apps, not a mega-app.

A driver never sees analytics. A parent never sees route optimization.

Seven surfaces to maintain, for near-zero onboarding friction.

DECISION 04

Validate before building the OS.

500+ parent and 50+ school surveys shaped both prototypes.

The ROI schools respond to - 30-35% admin time saved, 55-60% less paperwork - came from those calls.

DECISION 05

Commute time is product surface.

Audiobooks and the Podwise Olympiad give students a reason to like it.

Scope beyond safety. A product only the buyer loves churns.

Business model & market

Land via transport. Expand into the school OS.

SAM$4BIndian school market
SOM$250MTier 1–2 reachable
Entry pointTransportHighest-anxiety touchpoint

Per-student monthly subscription bundling hardware and software, or a custom AMC for schools that want to own the hardware.

What that asked of the design: no school sees a capex line, so no surface mentions device cost. Which is why super admin carries an onboarding sequence, not a quoting tool.

Design

The hardest problem wasn't a screen. It was the ecosystem.

The principle: every surface is scoped to one role's job at one moment, while shared semantics stay identical everywhere.

  • One trip-state vocabulary across driver, parent, admin, guard.
  • One alert grammar - a color never changes meaning between surfaces.
  • One student identity - a ticket raised in the parent app is the record the school panel closes.
Surface 01 · Parent app

Designed for 7:45 AM.

A parent at a bus stop wants one answer: where is my child? Track Bus and Camera lead navigation. Bus status is answerable in a glance - no taps.

Notifications fire from hardware, not from a transport manager - trustworthy by construction. Stop-change requests moved from phone calls into a tracked in-app flow.

Parent app - Home
Home
Parent app - Map view
Map view
Surface 02 · Bus app

Three versions to get a driver's attention right.

A tablet in a moving vehicle, used by someone whose eyes belong on the road. Three iterations, each stripping further down to trip states, navigation, and one unmissable SOS with an explicit "Contacting" state.

The alcohol test is a first-class flow, not a setting - the trip can't begin until it resolves. An end-of-trip mood check gives schools a daily pulse on driver wellbeing.

Bus app - Start test
Start test
Bus app - SOS
SOS
Surface 03 · School web panel

An operations console built on primitives.

Seven primitives an admin actually manages - students, drivers, routes, locations, buses, tickets, school - each with list → detail → edit. Bus cards aggregate live status, so the fleet view answers "is everything okay?" before any drill-down.

Parent-raised tickets land here as structured work items - closing the loop the parent app opens.

School web panel - Home page
Home page
School web panel - Bus view
Bus view
The invisible half

Internal tooling is part of the product.

Super admin, sales and support panels were designed alongside the customer-facing surfaces, not after them.

  • Add-school flow - the artifact behind "seamless onboarding". A guided sequence, not a services engagement.
  • Guard app - QR visitor verification on the same identity model as everything else.
  • Support and sales run on the same primitives, so an escalation needs no translation layer.
The signal that became a company

One Phase 1 feature outgrew the product.

Ignition-based alcohol detection pulled inbound from far beyond schools. Spinning it out as SafeIgnite was only possible because Parentalview was built as separable capabilities, not a monolith.

PHASE 2

Roadmapped, not shipped

RFID attendance, library, kiosks, announcements - all reusing student identity. Each names its risk: RFID consent, scope creep against the parent app's calm, an unproven expansion motion.

NEXT

See where it went

SafeIgnite took alcohol detection to fleets, buses and logistics as its own company.

What I learned

Structure for separability, not just scale.

  • Anxiety is a better wedge than a feature list. Transport wasn't the easiest build - it's the highest-emotion daily touchpoint.
  • Internal tooling is part of the product. The onboarding flow is the mechanism behind a claimed differentiator.
  • A roadmap should admit what could break. Naming the risk is what makes it credible.
to move · F for fullscreen