Pre-launch. Build in progress as of May 2026.
TL;DR
- Role: Product and Design Lead, Simple Cortex engagement
- Timeframe: May 2026 to present (pre-launch, in development)
- Business problem: A selfie-based AI consultation could drive bookings, but only if it earned trust and reduced risk. A tool that kept photos, overclaimed, or ignored skin-of-color patients would do the opposite.
- What I changed: Simple Cortex designed an ephemeral assessment flow that analyzes a photo, maps concerns to the real treatment catalog, and clears the riskiest data from the system. I led the engagement and owned product, design, and AI behavior end to end.
- Proof: Takes a selfie, maps concerns to real treatments, redirects to booking. No database record. No auth. No stored photo.
The result step · anatomy of one concern
3 points
Moderate, set conservatively for deeper skin. The severity sits next to the concern, never framed as a diagnosis.
The problem was not AI accuracy
Accuracy matters, but trust comes first.
The tool asks for a sensitive image: a person's face. The first design decision was not which model to use. It was whether this product deserved to keep the photo at all.
The answer was no. So the tool became ephemeral by architecture, not by policy. Take the image, analyze it, return useful guidance, map results to services the practice actually offers, then get out of the way. A privacy policy saying "we delete photos later" was not good enough. The product promise is stronger when there is no stored photo to delete.
The second constraint was clinical: the line between patient education and medical advice can blur quickly in a medspa context. A tool that casually overclaims, or one that treats Fitzpatrick I as the default and applies the same confidence to Fitzpatrick V, damages trust before the consultation starts. Simple Cortex designed around both risks from the first conversation.
What I did
- Designed a selfie-based consultation flow with no persistent photo storage. The image travels in the request, passes through the model, and the result returns to the browser. No write to disk, no row in a table.
- Mapped concerns to the actual treatment catalog rather than generic advice. AI can describe a concern. The recommendation has to come from what Kintsu actually offers. The service catalog acts as a guardrail.
- Created a plain-language result screen that educates without pretending to diagnose. The tool says what it notices and what people with similar concerns often explore. It does not say what condition a patient has.
- Built guardrails into the system prompt itself: no diagnostic language, Fitzpatrick-aware behavior required, recommendations limited to the vetted catalog. The system prompt is the design artifact.
- Framed the tool as a conversion bridge to booking, not a replacement for clinical judgment. The booking handoff carries the patient's shortlist of concerns and services, never patient identifiers.
- Isolated the AI image simulation behind a feature flag. The useful consultation flow ships without waiting on the legally exposed feature to clear review.
Wizard · Five Steps · Nothing Stored
What changed
The concept moved from risky AI novelty to a bounded product experience.
- The site gains a middle step between curiosity and booking. A visitor leaves with a shortlist of concerns and services to ask about, and a clearer reason to schedule.
- The user gets a useful next step. The business gets a lead path. The clinician keeps authority. The system avoids keeping sensitive data it does not need.
- Fitzpatrick III through VI patients are designed for explicitly, not covered by a disclaimer after the fact.
- The booking handoff carries intent without carrying patient identifiers.
- The simulation stays off until legal and clinical review clear it, without blocking the rest of the product.
The product strategy: useful enough to convert, restrained enough to trust.
Educational overlay · rendered client-side
3 points
The region is tinted by severity in soft gold, not clinical red. The visual language stays calm and educational.
Ephemeral pipeline · nothing persisted
Model Output
Server-Side Filter
Client
Phone-first · the primary surface
Three screens
Nothing leaves the device until you consent.
A reading, never a diagnosis.
The shortlist travels in the URL. The person does not.
Reflection
The power of this case is restraint. The product earns trust by refusing to keep data, refusing to diagnose, and refusing to recommend anything outside the real service model. That constraint is not a limitation. It is what makes the tool safe to launch and worth trusting.