How I work: the deliverable is something running

What a fractional design lead should hand you in the first month is a working prototype, not a deck. Something you can open, click, put in front of an engineer, and disagree with. If the first month produces a slide called "Design Principles," you have bought the wrong thing.

This is how I run engagements, so read it as interested testimony — I'm describing my own practice and there are cases at the end where it's the wrong one. But the underlying claim isn't about me: a prototype settles arguments that a document can only host.

Why the artefact matters more than it used to

Two things changed, and they compound.

The first is that production stopped being the expensive part. Once a design system is specified well enough for a model to read it, building a plausible screen is hours, not weeks. That collapses the old reason for decks — you drew a picture because building the real thing was too costly to risk on an unsettled idea. When building is cheap, a picture of the idea is a strictly worse version of the idea.

The second is that AI products can't be specified in static frames at all. The behaviour is probabilistic; the same input gives a different answer tomorrow. A flat mockup shows one draw from a distribution and quietly implies it's the product. You cannot evaluate what happens when the model is wrong by looking at a screenshot of it being right.

So the question a first month should answer isn't "what should this look like" but "what should this do, and does it hold when it misbehaves". That question needs something running.

Three kinds of prototype, three different jobs

"Prototype" is doing a lot of work in that sentence, and conflating these is how teams waste a month building the wrong fidelity.

Most engagements need all three, in that order, and the discipline is refusing to skip to the third. A production slice built before the shape is settled is the most expensive way to discover you were wrong.

The sketch layer is where most of the value is, and it's the one teams are most reluctant to fund, because throwing work away feels like waste. It isn't. Three sketches killed in a week is the cheapest month you will ever spend.

What this looks like in practice

Two examples, both real, neither of them tidy.

On EarthWonders — a 0→1 marketplace for fine-mineral collectors — the constraint turned out not to be design at all. It was iteration speed: the loop between deciding something and seeing it running was too slow to learn from. So I took GitHub access and contributed production UI directly. That is not a flex about writing code; it's an admission that the design work was blocked by a delivery bottleneck, and the fastest way through it was to stop handing off.

The second is this site's own design pipeline. The case studies here aren't drawn — they're authored as code, composed from a frozen token contract, and rendered to shipping pixels. That exists because I wanted the prototype and the system to be the same artefact, so that changing a token changes every screen rather than starting a re-draw.

Alongside those, I keep four small apps running — a character builder, a teaching assistant, a marketplace, a fleet tracker — built fast to try a technique before I recommend it to anyone. It's cheaper to be wrong on my own time.

What you should have at day 30

Concretely, and this is the bar I'd hold any fractional lead to:

• Something running that a stranger can open and form an opinion about.
• The two or three decisions that were actually blocking the team, made and written down — not surfaced, made.
• A statement of what "good" means for this product, specific enough to settle a future argument without me in the room.

Note what's absent: a roadmap, a competitive audit, and a set of principles. Those aren't worthless, but none of them is the constraint in month one, and all of them are easier to produce than a decision.

When this is the wrong approach

Three cases, honestly.

If the real problem is organisational — the team can't ship because ownership is unclear or two directors disagree — a prototype won't fix it and may paper over it. That's an advisory engagement, not a build.

If you're in a regulated or safety-critical domain where the research has to come first, prototyping early anchors people on the first plausible idea, and anchoring is expensive to undo. Slow down deliberately.

And if you already know exactly what to build and just need it drawn, you don't need this. That's a production problem, and a marketplace contractor is the cheaper instrument.

If a running prototype in the first month is what you're missing, here's how engagements work and what they cost.