I've done this twice. Once at CogniCor Technologies, where I joined before the product existed and had 3 months to design a platform that would close a $1M ARR deal. And again at Zenskar, where as founding designer I had to rebuild the entire product experience while 40 demos a week were happening and enterprise pilots were losing confidence.

The contexts were very different. The pattern was identical.

Founding design roles are a specific category of hard. You're not walking into a mature product org with runbooks and Figma libraries and a head of design who can orient you. You're walking into a team that's moving at the speed of a Series A raise, where the founders have opinions about everything, where the engineers are brilliant and opinionated, and where "ship it fast" is the operating mode.

Here's what I learned — what to do, what to avoid, and the mental model that held it together.

The 90-day structure

Days 1–30: make the problem legible

Here's the mistake I see founding designers make in the first month: they open Figma. They feel pressure to ship, to show velocity, to justify the hire. So they start designing screens before they understand the system.

Don't. Your most valuable contribution in the first 30 days is translation. Take the founder's mental model — scattered across Notion docs, investor decks, and late-night Slack messages — and convert it into something spatial and arguable. A user journey. A system diagram. A conceptual model that shows how the product's nouns relate to each other.

At Zenskar, one of the first things I did was map the billing conceptual model from a user's perspective: Products contain Prices, Prices go into Contracts, Contracts generate Invoices. Four objects. Four relationships. It took four hours to draw and validate with the engineering team. But it became the foundation for every design decision that followed — what to name things, how to sequence the onboarding, what the empty states should explain.

Find the user who will tell you the truth. In every product, there's one person on the customer side who will be brutally honest about what's broken. Find them in week one. Not through formal interviews — through Slack, through sitting in on a customer onboarding call, through asking the sales team who gives them the hardest time. That person is your compass for the next 90 days.

Days 31–60: ship something real

By week five, you should have shipped something. Not a polished feature. Not a complete flow. Something real enough that a customer can use it and react to it.

This matters because of trust. Founding designers are expensive hires at a stage where every hire has to prove itself. The founders need to see that you can translate insight into output. The engineers need to see that your designs are buildable. The customers need to see that the product is getting better.

The trap in this period is building what's impressive rather than what's needed. Founders love features. Sales teams love features. You need to be the person who asks: what's the smallest version of this that would tell us if we're right?

Days 61–90: build for the team you'll become

By month three, you should be thinking about your successor — even if you'll be at this company for five years. What would a second designer need to understand to join without losing the thread of what you've built?

This isn't about building a design system. At Series A, a full design system is usually premature — I'll make that case in another essay. But you do need three artefacts:

• 01
  A decision log. A running document (Notion works, Figma works) that captures the major design decisions you made and why. Not a beautiful record — a searchable one. When a founder asks "why did we design it this way?" six months from now, you need to be able to answer.
• 02
  A lean token system. Colours, spacing scale, type scale, border radii — documented and applied consistently. Not a full component library. Just the foundation that makes the next 10 screens feel intentional rather than improvised.
• 03
  A one-page design principles doc. Three to five principles specific to this product, this user, this context. Not "we value simplicity" — that means nothing. "We assume users understand their business but not our system. Every screen must meet them where they are." That means something.

The thing nobody tells you

Founding design is a leadership role disguised as a craft role. You are not just making screens. You are making decisions about what problems matter, which users to prioritise, how much complexity to expose, what to defer. These are business decisions that happen to manifest in pixels.

The founders hired you because they believe design can be a competitive advantage. Your job is to prove them right — not by making things beautiful, but by making things legible, trustworthy, and fast to evolve. Beauty is a consequence of that, not a starting point.