Roadify

Prototype in active development. Interface studies and architecture work explore the intended experience; reliable sensing, coaching and road-use safety still require validation.

My contribution covers product requirements, interaction design, safety and privacy constraints, and AI-assisted prototyping. I use coding assistants to develop and iterate on the implementation while shaping the product's scope and priorities.

Roadify began as a driving-awareness utility: parked-car protection, road hazards ahead, anonymous driver-to-driver alerts, incident capture. Useful, but a category — the kind of product that competes on feature count and loses.

What changed it was moving the centre. The dashcam stopped being the product and became the evidence layer underneath one. In its place sits Roadie: an AI road companion aimed first at the person who needs a calm voice most, a new or anxious driver learning between formal lessons.

That reframing turned a utility into a relationship, and made every design question harder in a productive way.

A phone on a windshield is a hostile design surface. Every element competes with the road, and the cost of a badly placed control is not a bounced session.

Drive Mode is designed around a glance budget. Ambient state sits in a single band, navigation holds one instruction rather than a full route, and hazard concepts pair a distance with a short label. A large central assist control anchors the interface. These are design choices to test, not established claims about safe or eyes-free use.

The design language followed from the constraint rather than from a mood board: high-contrast type on true black, one accent colour carrying all urgency, and no decorative motion anywhere in the driving surface.

It is easy to write what a product does. The harder and more revealing document is what it refuses to do — and for anything that speaks to a person while they are driving, that document is the actual product.

Roadify's brief states its limits before its features. It is a supervised practice companion, not a driving school. It is not an examiner and issues no certification. It does not control a vehicle. It never declares a road, a manoeuvre or a clearance safe — a single forward-facing phone camera cannot validate rear clearance, so parallel parking, the most requested lesson, stays a parked exercise until the sensor coverage exists to teach it honestly.

That last one costs the product its best demo. Keeping it is the point.

Roadify carries a constitution. Not a policy page bolted on for an app store review — a working document that binds the product's own AI assistants, with two load-bearing clauses: an attention ethic, and a surveillance line that says what the cameras will never be turned into.

It exists because the product's raw materials are a live camera, a location trail and a voice channel into a car. Those are the ingredients of something genuinely useful and something genuinely invasive, and the difference is entirely in constraints written down early enough to be inconvenient.

Every proposed feature is checked against it. Several have failed.

The project explores an iOS application, on-device models, a Supabase community-alert layer, an edge worker for voice and a web prototyping surface. Its architecture documents cover vision, event understanding, network observation, an action engine and privacy-preserving vehicle identity. Those documents express design intent; they are not evidence that all components are complete.

Web prototypes support fast interaction experiments alongside native development. A working screen is an intermediate result, not proof of reliable sensing, safe guidance or readiness for a public release.