What it’s like to be a product designer at a seed-stage startup

What being a product designer at a seed-stage startup is really like: wearing many hats, shipping with a system, marketplaces, remote work and owning outcomes.

By · · 5 min read

On this page· 8

In July 2026 I joined Anvara as a Product Designer, working remotely from Mallorca. Anvara is the marketplace for live event sponsorships: it connects brands, leagues and live events. On 14 October 2026 our CEO announced a $2.5M seed extension, bringing the total raised to nearly $7M.

I won’t share anything internal here. What I can share is what being a product designer at a seed-stage startup is like in general, and the principles that help, drawn from years of designing for founders at this stage and now from working inside one.

Seed stage, in plain terms

At seed stage, a startup has raised its first real funding, has a product people use, and is still working out exactly what that product should become. The team is small, the roadmap moves, and every week brings new things to learn from customers.

For a designer, that’s both the challenge and the fun. There’s no thick brand book, no mature design system and no layers of approval. There’s a problem, a team and a lot of room to shape things.

You design the product and the company at the same time

At a large company, a product designer usually owns one area of one product. At a seed-stage startup, the boundaries are much looser. Product screens, the marketing site, emails, sales materials and social graphics can all land on the same desk, and they all shape how the company is seen.

That’s why I think the best early-stage designers are generalists with depth. You need strong UI and UX skills, but brand, typography, motion and a sense for marketing help just as much. My own background in brand identity, motion and product design has been useful for exactly this reason: at this stage, it’s all one brand.

Speed, with a system underneath

Startups need to ship quickly. The trap is shipping quickly without any structure, then spending months later untangling a product where every screen was designed differently.

The answer isn’t a huge design system on day one. It’s a lightweight one that grows with the product:

  • Tokens first: color, type, spacing and radius, defined once and used everywhere.
  • A small set of core components: buttons, inputs, tables, cards, modals, empty states.
  • Patterns for the things you build again and again, like lists, filters and detail pages.
  • Documentation that lives next to the work, short enough that people actually read it.

This is the same thinking behind my SaaS redesign checklist, just applied earlier, so you don’t need a big redesign later.

Consistent components make a product feel like one tool: ChromaAI’s voiceover picker.

Designing for both sides of a marketplace

Marketplaces are a special kind of product, because you’re designing for at least two groups with different goals. In live event sponsorships, that means brands looking for the right audience and the rights holders, like leagues and events, who offer it.

A few principles hold for almost any marketplace:

  • Each side needs to see value fast. Both buyers and sellers should understand within minutes why the product is worth their time.
  • Listings must be easy to compare. Consistent structure, clear key facts and good visuals turn browsing into deciding.
  • Trust goes both ways. Each side needs to know who they’re dealing with and what happens next.
  • Status should always be clear. When a deal involves several steps and several people, everyone should see where it stands.

Close to users, close to engineering

One of the best things about a small team is how short the distance is between a question and an answer. You can talk to customers, show them a prototype and change it the same week. You can sit with an engineer and decide together what’s worth building now and what can wait.

That changes how you design. Instead of polished handoffs, the work becomes a conversation: rough flows early, quick feedback, then detail where it matters. The best results come from designers who understand enough about how things are built to make smart trade-offs.

Working remotely across time zones

Working from Mallorca with a team in New York means a time difference of around six hours. It works well with a few habits:

  • Write things down. Clear written context beats a quick call that half the team missed.
  • Use the overlap well. Keep live time for decisions and discussion, and do focused design work outside it.
  • Share work early. Short recorded walkthroughs and annotated files let people give feedback on their own schedule.
  • Leave things ready for the morning, so the team on the other side can pick them up without waiting.

Owning outcomes, not just screens

At a seed-stage startup, nobody measures a designer by the number of screens. What matters is whether the product gets easier to use, whether customers understand it faster, and whether the team ships the right things.

That means caring about scope as much as pixels: helping decide what not to build, cutting a flow down to its essential steps, and accepting that some things will be good enough for now. You can see how that kind of thinking plays out at a larger scale in my ChromaAI redesign, or browse more case studies.

Frequently asked questions

What does a product designer do at a startup?

They shape how the product works and looks, from user flows and interfaces to the design system. At an early-stage startup, they often also touch the website, emails and other brand materials.

What skills does a seed-stage product designer need?

Strong UI and UX skills, plus a broad range: brand and visual design, a basic understanding of how products are built, comfort with fast-changing priorities and clear written communication.

Can a product designer in Spain work remotely for a US startup?

Yes. With clear written communication and good use of the overlapping hours, working from Spain with a team in the US works well.

When should a startup build a design system?

Earlier than most think, but small. Start with tokens and a handful of core components, and grow the system as the product grows.

Keep reading