What Founding Design Actually Means

I've been the founding designer twice now — at Recepto, and now at Aurora. The title looks great on a profile and tells you almost nothing about the actual work. Here's what the words are hiding, written mostly for the version of me who accepted the first one without asking enough questions.

You own everything and nothing

There is no design team, so there is no design lane. You own the brand, the product, the marketing site, the pitch-deck typography, the onboarding emails, the empty states nobody remembers to spec, and the favicon at 11pm before a launch. You also own none of it exclusively, because at five people every decision is everyone's decision and the CEO has opinions about the button.

Learning to hold both facts at once is the whole job. The trap on one side is becoming a service desk that renders other people's ideas. The trap on the other is defending a lane that doesn't exist yet. What works is being the person with the clearest, most repeatable point of view — one the rest of the company can pick up and use when you're not in the room, because most of the time you won't be.

Speed is a design constraint

At a startup the most expensive thing you can produce is a beautiful design for the wrong product. The market moves under you weekly. So the craft shifts from making it perfect to making it clear fast — enough fidelity to learn something true, not so much that you fall in love with a thing you'll delete on Friday.

This was the hardest unlearning for me. I came out of school and open-source work believing polish was the point. Polish is the reward. You only get to collect it on the ideas that survive contact with real users, and most ideas don't.

The practical version: match fidelity to the question. A flow question gets boxes and arrows in twenty minutes. A comprehension question gets real copy in a real screen, because comprehension lives in the words. A feel question gets built in the browser, because feel cannot be evaluated in a static frame. Anything more than the question needs is procrastination with good taste.

Ship it yourself

The founding designers I admire don't hand off. They build. Not because engineers can't be trusted — because at that size there is nobody to hand off to, and the fastest path from an idea to something a user can touch is your own two hands.

• Prototype in production, not in a mockup nobody can click.
• Write the copy. You understand the product better than anyone with time to write it.
• Instrument what you ship, so the next decision is informed by something other than taste.
• Fix your own bugs. Nothing teaches you the true cost of a design decision like maintaining it.

It's why I stopped thinking of myself as a designer who codes and started treating the two as one motion. The alternative — a queue of tickets and a two-week lag between an idea and its evidence — is fatal at a stage where the whole advantage is that you can turn around in a day.

Saying no is most of the job

At five people you are frequently the only person in the room whose job is to represent the user, and the user is not in the room. That means saying no on their behalf — to the enterprise prospect who wants a toggle, to the founder who saw a competitor ship something shiny, occasionally to yourself at 2am.

The version of no that works isn't a veto, it's a trade. We can ship that this sprint if the export flow slips two weeks — here's what each looks like a month from now. Making the cost visible turns you from the person blocking the roadmap into the person pricing it, and those two people have wildly different amounts of influence.

Founding design is less about making things beautiful and more about making the team certain.

Build the smallest system that survives you

There is a moment — usually around the fifth or sixth engineer — where the company starts producing interface faster than you can review it. If you haven't built a system by then, you spend the next six months as a bottleneck, and the product develops a stutter you can hear in every new screen.

But a full design system at ten people is a vanity project. What you need is the smallest set of decisions that stops the drift: a type scale, a spacing rhythm, one radius, a colour set with real names, and about a dozen components that exist as code rather than as a library file. Everything else can stay improvised until it hurts.

The test isn't whether it's comprehensive. It's whether an engineer who has never spoken to you can build a new screen at 6pm and have it look like it belongs. If yes, the system is done for now. Go back to designing the product.

Brand is a product decision at this size

At a big company, brand is a department and product is a different department, and they meet quarterly to be disappointed in each other. At six people they are the same decision made twice a day, and pretending otherwise produces a product that feels like it was assembled from two companies.

The practical consequence: the marketing site and the app should be built from the same tokens, in the same repo, by the same person, or they will drift within a month. Every founding-designer job I've taken had a moment where the homepage promised something calm and considered, and the product delivered something dense and default-styled. The gap between those two is the most expensive thing on the site, because it's the first thing every prospect experiences and the only thing they'll remember if they bounce.

It also means resisting the urge to design a brand before you have a product. A logo and a colour palette derived from nothing are a costume. Ship the product, watch what it turns out to be good at, then let the identity make an argument about that — the second version will be better, cheaper, and defensible in a way the first one never was.

The first ninety days, in order

Both times, the temptation on day one was to redesign something. Both times, that would have been wrong. What actually worked, in this sequence:

1. Weeks 1–2: watch. Sit in on sales calls and support threads before you open a design tool. You are trying to learn the vocabulary customers use, which is almost never the vocabulary the team uses.
2. Weeks 3–4: ship something small and visible. A fixed empty state, a rewritten onboarding email, a real loading state. Credibility comes from shipped things, and you'll need it before you propose anything structural.
3. Weeks 5–8: name the product's point of view. One page. What it is, who it's for, what it refuses to do. Argue about it until the founders would write the same page.
4. Weeks 9–12: build the smallest system. Only now, once you know what the product is, is it safe to fix the vocabulary in code.

The order matters more than the content. Every founding designer I've watched struggle did steps three and four first, produced something beautiful and internally coherent, and then discovered it was answering a question the company had already moved past.

Why I keep doing it

It's exhausting, the surface area never shrinks, and there is always a version of the job with a clearer scope and a better title. But there's nothing like watching a product go from a sentence to something thousands of people use, knowing your fingerprints are on every pixel and half the decisions.

I don't think I could go back to owning one lane. Ask me again after the third one.