Turning Phone Photos into Business Portraits: What We Learned Building a Browser-Based Headshot Tool

A studio headshot used to mean booking a photographer, travelling to a studio and waiting days for retouching. For a developer updating a LinkedIn profile before a job search, or a five-person startup that needs a team page, that workflow is out of proportion to the need. They want one good portrait, not a photoshoot.

We built Pro Headshot Generator to collapse that into a single browser session. This post is about the engineering and product decisions behind it — the parts that were harder than expected, and what we would do differently.

The constraint that shaped everything

We fixed two limits early: four input photos, one output session. Not because the model could not take more, but because the user could not supply more. Most people have a handful of usable phone photos. Asking for twenty turns a two-minute task into an afternoon of scrolling through camera roll folders.

Four photos is enough to pin down facial structure while staying inside what someone can find on their phone in under a minute. It also bounds the compute per request, which matters when you price by credits instead of by subscription.

Outfit, scene and pose are separate controls

The first version had one "style" dropdown: business, casual, creative. It tested badly. Users did not want a style, they wanted to fix one specific thing — "the jacket is wrong" or "I want a plain background".

So we split the controls into outfit, scene and pose, each selected independently. The cost is a larger option matrix and more combinations to render. The benefit is that the interaction now matches how people actually describe what they want.

The lesson: when users keep asking for a small variation of a preset, the preset is the wrong abstraction.

Preview before committing

Generation is neither free nor instant, so the flow renders a preview before the final output. Users can re-pick the outfit or scene and preview again without spending a full generation.

This changed perceived speed more than any backend optimisation. Wall-clock time did not drop. The feedback loop did.

Output format is a product decision, not a detail

We ship single images and ZIP archives. The ZIP is not a technical nicety — it is what recruiters and agencies asked for. They process portraits in batches, and downloading forty files one at a time is exactly the friction that sends someone back to a photographer.

Resolution works the same way. A portrait gets used as a 200px avatar and in a printed conference programme. Rendering only for the screen looked fine in demos and failed in real use.

Browser-first, and deliberately unremarkable underneath

Upload, selection, preview, crop and download all run in the browser. No install, no plugin, no desktop app.

We kept the stack boring on purpose. The interesting part of a tool like this is the interaction model, not the framework. The people who benefit most are often in markets where studio photography is expensive or hard to schedule, and they are usually on mid-range hardware and unreliable connections.

What we would do differently

Two things.

First, we priced by credit packs from day one, with no free tier. That was right for unit economics and wrong for discovery: people want to see one output before they pay. We are still working out the right way to offer a sample.

Second, we under-invested in the crop step. Cropping sounds trivial until you watch someone frame the same portrait for three different platforms. It deserves its own pass.

The takeaway

The constraint that helped most was refusing to add a fifth input photo. Every feature request we declined made the core flow shorter.

If you are building something in this space, Pro Headshot Generator is live at proheadshotgenerator.com. Feedback welcome.