Design that grows: how I think about design for early-stage startups

Design at an early-stage startup is a different job from design at a large company. There are fewer users, less data, and much less time. The work still matters a lot, but what "good" means changes.

I have worked on both sides: inside a large edtech company at Ruangguru, on the product team at Intellect (YC S21), and as the founding designer at Dearflow (Techstars '24). Today I work with early-stage teams through my studio. This post covers the three things I focus on when designing for a startup that is still finding its footing: clarity, conversion, and shipping fast.

Clarity first

The most common problem I see on early products is not that they look bad. It is that people can't tell what the product does.

Founders live inside their idea every day, so the value seems obvious to them. A visitor arriving from a link has about five seconds and no context. If the headline is clever but vague, or the first screen of the app asks for setup before showing anything useful, that visitor leaves.

So the first thing I do on almost any project is rewrite and restructure before I touch visuals. What is this, who is it for, and why should they care now? If I can't answer that in one sentence from the first screen, no amount of polish will fix it.

At Dearflow, an AI assistant product, a lot of my early work was exactly this: finding a way to explain a capable but abstract product so that people understood it on first contact. The visual design came after the explanation worked.

Design for the next step, not the whole journey

At a large company you design entire systems. At an early-stage startup you usually need to get one person to take one next step: sign up, book a call, connect an account, invite a teammate.

I design each screen around that single step. One primary action per screen. Everything else is either supporting that action or removed. It is a simple rule, but it cuts through a lot of debate about what belongs on a page.

This is also where design and growth overlap. A landing page is not just a brand piece; it is a conversion tool. An onboarding flow is not just UX; it decides how many signups become active users. I find it useful to think of these as the same job.

Conversion is a design problem

When numbers are low, founders often reach for more marketing. Sometimes that is right. But often the leak is in the product or the page itself.

A few patterns I check early:

• Is the call to action clear and specific? "Get started" is weaker than saying what will happen next.
• Is there proof? Real customer quotes, recognisable logos, or a concrete result reduce doubt more than adjectives do.
• Does pricing answer the obvious questions? Unclear pricing pages lose people who were ready to pay.
• How long until the first moment of value? In onboarding, every step before a user sees something useful costs signups.

None of this needs a big analytics setup at first. Watching a handful of people try the product, or reading support messages, is often enough to find the biggest problem.

Ship fast, then improve

Early-stage teams learn by putting things in front of users. A perfect design that ships in six weeks teaches you less than a good one that ships tomorrow and gets fixed next week.

That shapes how I work. I would rather deliver a solid first version quickly and iterate than disappear for a month and return with something polished but untested. At Intellect, a mental health product, working closely with engineers and shipping in small increments meant we could learn from real users quickly and adjust.

Shipping fast does not mean skipping craft. It means choosing where craft matters most right now. Usually that is the first impression, the core action, and anything that affects trust. Edge cases and secondary screens can be good enough until they are not.

Lessons from a larger company

Ruangguru taught me the value of systems: consistent components, clear writing guidelines, and research before big changes. Early-stage startups don't need a full design system on day one, but they benefit from a small version of that discipline.

I usually set up a light foundation early: a type scale, a small set of colours, and a handful of reusable components. It costs very little and saves a lot of time later, when the product grows and new screens need to look like they belong.

What I bring to an early team

When I join a startup, through my subscription or otherwise, I try to act like a founding designer rather than a vendor. That means asking about the business goal behind each request, pushing back when a design won't move the number we care about, and shipping work that engineers can build without guesswork.

Design that grows is not a style. It is a habit of asking whether each piece of work makes the product clearer, makes the next step easier, or helps the team learn faster. If it does none of those, it can probably wait.