Most AI face analysis products begin with a simple architecture: upload a photo, send it to an API, run a model on a server, and return a score.
That approach is convenient, but it creates a data problem. A face photo is personal data, and many people do not want to upload it just to learn about visible proportions or face shape. When I built LookBlueprint, I started with a different constraint:
The useful first result should be possible without sending the original photo to a server.
This constraint shaped almost every technical decision in the product.
Running the first analysis locally
The free analysis runs in the browser using MediaPipe Face Landmarker and a bundled WebAssembly runtime. The model and runtime are shipped with the application, and the analysis work runs in a Web Worker so the interface remains responsive while landmarks are being detected.
The flow is roughly:
- The user selects one clear, front-facing photo.
- The browser validates and prepares the image for analysis.
- The worker detects facial landmarks and basic image-quality signals.
- Pure TypeScript analysis functions convert those landmarks into a versioned face-analysis snapshot.
- The UI renders the snapshot into focused results and educational explanations.
The original image is not uploaded for the free result. There is no login requirement for that workflow, and the result is kept temporarily in the browser session.
This is a practical privacy improvement, but it also changes the engineering trade-offs. The model must load reliably on a range of devices, image processing must fit within browser memory limits, and errors must be understandable to a person who is not debugging a machine-learning pipeline.
Measuring structure instead of pretending to measure beauty
A face-analysis score can sound more objective than it really is. I wanted the product to expose measurable references without presenting them as a universal ranking of people.
LookBlueprint separates several types of output:
- Visible left-to-right symmetry and pair differences.
- Face-shape candidates with confidence percentages.
- Vertical thirds and horizontal fifths.
- Face length-to-width and facial width-to-height ratios.
- Eye-shape references and canthal tilt.
- Jawline and lower-face structure.
- A separate photo-reliability signal.
The overall rating is not treated as a scientific truth. It combines selected structural signals, while camera reliability remains separate. Natural asymmetry, lighting, head rotation, expression, lens distortion, and landmark quality all affect what can be measured in one photo.
That distinction matters. A result should help someone understand the image in front of them, not tell them what they are worth or reduce a complex person to a number.
The hardest part is measurement quality
Face landmarks are not the same thing as ground truth. A small change in camera angle can change the apparent proportions. Hair can hide the jawline. Low light can reduce landmark stability. A wide-angle selfie can exaggerate the center of the face.
Because of that, the interface explains limitations next to the result instead of hiding them in a legal page. It reports confidence, identifies the photo conditions that affect interpretation, and encourages users to treat the output as a reference from that image.
This also makes the error states important. If a photo does not contain a usable face, the user needs a clear next step: try a brighter, more front-facing image with the face unobstructed. A generic "analysis failed" message is technically accurate but not useful.
A small architecture with explicit boundaries
The application uses a Next.js frontend, a Web Worker for the browser analysis pipeline, and pure analysis modules that transform landmarks into a typed, versioned FaceAnalysisSnapshot.
That snapshot is the boundary between detection and presentation. The worker does not need to know how a result card is rendered, and the UI does not need to know how the model locates landmarks. This keeps the core calculations testable and makes it possible to add focused tools without duplicating the detection pipeline.
The product currently includes focused views for rating, symmetry, face shape, proportions, canthal tilt, jawline, eye shape, and a neutral structure view. It also includes guides covering methodology, research references, accuracy, bias, limitations, privacy, and practical style questions.
What happens when a user wants a report?
The free analysis stays in the browser. For the optional personalized Face Blueprint report, the browser prepares a constrained analysis copy for the report workflow rather than sending the original source file. The copy is limited in size and dimensions, and the report can be delivered as an on-page result, a multi-page PDF, and a keepsake image.
The important product decision is to make that boundary visible. Users should know which workflow is local, which workflow is optional, and what kind of image copy is involved.
Why build it this way?
The first-principles answer is simple: if the product only needs facial landmarks and ratios for its free result, uploading the original photo is not a necessary starting assumption.
Local processing does not solve every privacy or accuracy problem. It does, however, reduce unnecessary transmission, give users a clearer mental model, and force the product to be honest about what one photo can and cannot tell us.
You can try the free browser-based analyzer at lookblueprint.com. The goal is not to produce a definitive judgment. It is to give people a private, understandable way to explore the visible patterns in a photograph.
Top comments (0)