Designer or developer: who should you hire first for your MVP?

You have an idea, a budget of maybe $10,000, and room for one hire. Should it be a designer or a developer? Founders ask this a lot, and the honest answer is: it depends on where your biggest risk is. Here's how I'd think about it, as someone who has designed an MVP with a team, and builds my own apps too.

First, what an MVP is for

A minimum viable product isn't a smaller version of your dream app. It's the smallest thing that answers one question: will people actually use this? Everything in MVP design follows from that. One kind of user. One main journey. Enough polish that people trust it, and not a screen more.

That's why who you hire matters. You're not hiring someone to build features. You're hiring someone to help you get that answer as quickly and cheaply as possible.

Hire a designer first if…

• You're not sure what the product should be yet. A designer can test the idea with sketches and prototypes before a single line of code is written. That's the cheapest way to be wrong.
• Your users aren't technical. The owner of a corner deli, parents, older people. If they don't understand it in the first minute, they leave, and you learn nothing about whether the idea works.
• You're competing on experience. If there are already apps that do this, being clearer and easier is your edge.

Hire a developer first if…

• The hard part is technical. If nobody knows yet whether the thing can even be built, find out first.
• It's a tool for you or your team. Internal tools can look plain. They just need to work.
• You already know exactly what to build. A clear spec, a simple flow, and a template UI might be enough to start.

The hidden cost: the hand-off

When a designer and a developer work separately, a lot of time goes into the space between them. The designer makes screens. The developer builds them, and some things don't quite work. Questions go back and forth. Small details, like what happens when a name is very long, or the list is empty, or the internet drops, get decided by whoever is in a hurry.

In a big company, that cost is worth paying. In an MVP, it can be most of your time. That's why one person who does both can be a good first hire. The person who designs the screen also knows what it costs to build, and can change it on the spot.

What a designer who builds is good at, and not

I design and build my own apps, so I'll be honest about both sides.

Good at:

• Getting a real, working first version in front of users quickly.
• Changing the design after watching someone use it, and shipping the fix the same week.
• Sweating the small states that make an app feel trustworthy: empty, loading, offline, errors.

Not the best fit for:

• Deeply technical products, where the hard work is in the backend, the data or the infrastructure.
• Products that already have scale, where you need specialists who go deep on one thing.

How I'd design an MVP for a startup

1. Write down the one question this MVP needs to answer, and who it needs to answer it for.
2. Map the one journey that answers it, from opening the app to the moment the user gets value.
3. Sketch it, then test the sketch with three or four real people. Change what confuses them.
4. Design it with real content, not placeholder text. Real names, real prices, real messes.
5. Build only that journey, well. Everything else waits.
6. Put it in a few real users' hands and watch. Then decide what's next based on what they do, not what they say.

I go into the design side of this in how to design an app from scratch, and the building side in my Figma to Next.js workflow.

Working in a team still matters

Doing both doesn't mean doing it alone. At Bizz+, I designed the first online version of the marketplace together with the team, and later led design there. Their COO put it like this:

Adil's creativity, attention to detail, and collaborative spirit significantly shaped our MVP launch.

The best MVPs I've worked on had a founder close to the users, and a small team that could change things quickly. One person who designs and builds is just a way of keeping that team small.

So, who first?

If your biggest risk is “can we build it?”, hire a developer. If it's “will people use it?”, and for most startups it is, start with design. And if you can find someone who does both well, they'll often get you to your answer fastest.