Selected work

Two software prototypes built from different behavioural problems.

Relay and OFFLINE were built independently from insight through working prototype. They are not presented as validated businesses.

01

Relay

AI conversation studioBUILT

Can a meeting leave behind its decisions, owners and next actions instead of another transcript?

The problem

Meeting tools optimise for transcription, which preserves the words and discards the outcome. What someone actually needs afterwards changes with what they have to do next: a decision log, a study note, a follow-up email. The raw material is identical; only the editorial judgement differs.

The build

A multi-screen prototype that runs a live model call end to end — upload, analysis, intent-driven output selection, a review step, then a library of saved outputs.

Decisions
Intent selects the output, not the file type.
The same recording becomes a different artefact depending on who will act on it. Asking for intent up front is the only question that changes the answer.
Nothing publishes without a human edit.
The review screen cannot be skipped. The model drafts; the person keeps the editorial decision.
Output is stored, not consumed.
A library turns one recording into a compounding set of working assets rather than a result that is read once and lost.
What remains unvalidated

Whether stated intent is a better selector than document type once real users are choosing under time pressure.

Working prototype. User validation not yet run.

Tools
Lovable, Replit
building and iterating the prototype
ChatGPT, Claude
product logic, flows, output architecture, edge cases
02

OFFLINE

Real-world social discoveryBUILT

A product that optimises toward real-world interaction, not time spent in-app.

The problem

A match on a dating app opens a long digital runway — opening lines, days of messaging, scheduling — and often no meeting. Meanwhile people are already out in the same room with no way of knowing who is compatible, who is interested back, or whether it is alright to walk over. Three kinds of uncertainty, none of them solved by more messaging.

The build

A multi-screen prototype covering the two contexts the product runs in: a persistent discovery layer outside venues, and Tonight Mode, activated when the user is physically out. Tonight Mode covers temporary venue check-in, a compatibility count rather than a catalogue, a small curated batch, mutual interest, one active connection with minimal coordination, and a 'We've met' confirmation.

Decisions
One active connection at a time.
Several mutual likes in one venue would otherwise become several parallel chats and no conversation. Mutual interest becomes a sequenced opportunity with a short window, so the night is spent on one person rather than a phone.
A curated batch, never an endless queue.
'37 checked in · 12 compatible' orients without displaying everyone. Showing all twelve at once turns a room into a feed and puts the product in competition with the night.
Approachable Mode is recognition, not permission.
An optional current-outfit selfie answers 'what do you look like right now', which is a different job from the profile photo. It is contextual, temporary and revocable, and it never overrides an ordinary boundary.
Expiry is contextual, not punitive.
An unmet connection ends with the night — 'not tonight' rather than a loss. If two people do meet, both confirm it and the connection is kept.
What remains unvalidated

Whether people want to know which compatible singles are in the room, or whether that reads as intrusive — and whether a deliberately limited batch feels refreshing or restrictive. Both have to be answered before venue density is worth engineering for.

Working prototype. User validation not yet run.

Tools
Lovable, Replit
building and iterating the prototype
ChatGPT, Claude
behavioural problem definition, product architecture, flows, trust and safety logic