Product Design & Gen AI Development

The usual arrangement splits a product across a researcher, a designer, a front-end developer and whoever owns the deploy. Every boundary is a place where intent gets restated and something gets lost — usually the reason behind a decision, which is the part that mattered.

I do the whole path instead. The person who chose the interaction writes the component. The person who designed the empty state is the one who finds out it never renders. That is faster, and more importantly it is more accurate.

A call, then a written scope with a number in it before anything starts. Then short cycles, each ending in something you can open — a URL, not a screenshot. Async by default, with calls when a decision needs a conversation.

I don't publish a day rate. A two-week design pass and a six-month build are different conversations, and quoting before I understand the scope would only be a number I'd have to revise.

Fintech, healthcare and pharma, across fifteen years. Those are domains where the constraints shape the interface rather than decorate it — approval gates, audit trails, compliance review, the fields you are not allowed to pre-fill, the disclosure that has to appear before the action and not after.

Designing inside those rules is a different job from designing around them, and it is most of what I have done.

I don't publish a rate. It would be a number I'd have to revise the moment I understood the work, and a page that quotes a figure before hearing the problem is advertising, not pricing.

What I do instead: a call, then a written scope that names the deliverables, the sequence and the number. If the scope changes mid-project — and it usually does, because building something teaches you what it should have been — we change it deliberately, in writing, rather than absorbing it quietly on either side.

Two things make a project cheaper. Knowing what you are trying to learn, so research answers a question rather than surveying a field. And having someone who can decide — a project with three stakeholders and no decision-maker spends most of its budget on rework.

Generating screens and generating code are both close to free now. That changed which parts of this job are hard, and it did not change the hard parts themselves.

What it speeds up: first drafts, boilerplate, the fiftieth variation of a component, reading an unfamiliar codebase. What it does not do is tell you which four of those fifty screens to delete, notice that the flow contradicts how the business actually works, or catch the bug it wrote two files away. I use it heavily for the first list and do not trust it with the second.

The practical effect for you is throughput, not a discount on judgement. More options explored, faster; the same care spent deciding between them.

I am one person, so I am not the answer for work that needs several people in parallel on a deadline. I don't do brand identity or marketing campaigns. I don't take projects where the design is settled and the job is only to push pixels — that work is better and more cheaply done by someone else.

Saying that on a services page costs me some enquiries. It costs both of us less than finding out on the second call.