Should You Hire a Designer or Developer First?

Whether to hire a designer or developer first comes down to where the biggest risk in your project sits. If you don't yet know what users need, or the experience itself is what you're selling, start with a UX/UI designer. If the hard part is data, integrations, and business logic, start with a developer, and for many MVPs a developer with a good eye, working from an existing design system, can cover both.

I'm a freelance developer based in Denmark, not a designer, so weigh my view with that in mind. I've tried to be as clear about when you need a designer first as about when you can do without one.

The short answer

My rule of thumb: if you can't sketch your three most important screens and say who uses them, start with a designer. If you can sketch them but can't explain how data gets in and out of the system, start with a developer. If you can do both, a developer with design sense is often enough for version one.

What a UX designer, a UI designer, and a developer actually do

Job titles get mixed up, so here's the plain version:

• UX design (user experience) is about how the product works for the person using it: who they are, what they're trying to get done, and which steps they go through. Typical output: user interviews, user flows, wireframes (bare-bones screen layouts without color or styling), and prototype tests.
• UI design (user interface) is about how it looks: layout, typography, color, icons, and the components that buttons and forms are built from. Typical output: finished screens and often a design system.
• Development is building the thing so it works: the database, the logic, users and permissions, integrations with other systems, and the interface itself in code.

Nielsen Norman Group, a usability consultancy, separates the first two firmly. Their definition of user experience points out that a clean, logical interface can still deliver a poor experience if the product doesn't solve the user's actual problem.

In practice the lines blur. Many designers handle both UX and UI, and front-end developers often have a decent feel for layout. For the full picture of developer roles, see my guide to the types of developers and which one your project needs.

What matters to you as the buyer is the split of responsibility. A designer works out what the user should experience. A developer works out how to build it so it runs reliably.

When the designer should go first, and when the developer should

Signs you need a designer first

• You're not sure who your users are or what they'd pay for.
• You sell to consumers or a broad audience, and the experience is what sets you apart.
• The core flows are complex, like a booking, a checkout with many options, or onboarding for new users.
• You need to show the product to investors, customers, or your board before spending on development.
• Your brand matters to the sale, and you don't have a visual identity yet.

In those cases a clickable Figma prototype is the cheapest place to be wrong. Moving a button or deleting a whole screen takes minutes. Once it's built in code with a database behind it, even small changes can take hours. Nielsen Norman Group recommends testing with around five users per round and running several small rounds instead of one big study. A designer can do that on a prototype before a developer starts.

You can also mock up a rough prototype yourself in a no-code tool. That's fine for testing an idea, but it doesn't replace talking to users. I've written more about what no-code and low-code tools can do, and where they stop.

Signs you need a developer first

• The product is used by your own staff or a known group of existing customers.
• The hard part is integrations, for example with an accounting system like Xero or an API nobody on your team knows.
• The interface is mostly lists, forms, filters, and a dashboard: patterns people already know from other tools.
• You already have a design system or brand guidelines from your website that the product can follow.
• You're not sure something is technically possible, like getting the data you need out of a third-party system.

Here the biggest risk isn't that users misread the screens. It's that the system can't do what you promised. Spend the first part of your budget on a technical spike (a short experiment proving the hard part works), not on polished screens of something that might not be buildable.

When one developer with design sense is enough for an MVP

An MVP (minimum viable product) is the smallest version of your product that real users can try, built to find out whether anyone will use it and pay for it. For that job, letting a developer with design sense handle the interface instead of running a separate design phase is often the sensible call.

It works when three things are true:

1. The interface uses familiar patterns: sign-in, lists, forms, a dashboard, and settings.
2. There's an established component library or design system to build on. For Tailwind CSS, which I use, there are free and paid libraries covering most standard screens.
3. You're fine with version one looking clean and professional rather than distinctive.

By design sense I don't mean the developer can create a brand. I mean they keep spacing, typography, and color consistent, think about mobile, empty states, error messages, and loading, and push back when a screen gets cluttered.

What you give up is user research before the code is written, and a look that stands out. For a first version that's usually a fair trade, as long as you plan to bring in a designer once you know your users better.

A good middle ground is hiring a designer for a few days to design the key screens, like the main dashboard and the core flow, and having the developer build the rest in the same style. Whether one person can carry the whole build is a separate question, which I cover in when one full-stack developer is enough.

How the order affects cost

The order decides where the money goes, and when you find your mistakes:

• Designer first means spending before development starts. In return, development is more predictable because fewer questions are open, which also makes a fixed-price quote easier to get.
• Developer first pushes design to later. It's cheaper up front, but every change to a flow happens in code, which takes longer than changing a sketch.
• One developer with design sense is usually the cheapest route to version one, since nobody has to coordinate between two people. The trade-off is an interface that hasn't been tested with users before launch.

Design cost depends mostly on the number of screens and flows, whether user research is included, whether you already have a visual identity, and how many test rounds you want. As a rough guide, a focused design round for an MVP takes from a few days to a few weeks.

Design can also make development pricier. Custom components, animations, and non-standard layouts take longer to build than library components, so have a developer review the design before it's final. For how design fits into the total budget of a first version, see my breakdown of what an MVP costs and what drives the price.

When each option is the wrong call

Designer first

Designer first is a poor fit when the work is mostly technical and the users are few and known. An internal tool for ten people rarely needs a long research phase. You'll learn more by watching them work for an afternoon.

It's also the wrong call if nobody checks that the design fits your build budget, or you'll pay for screens you can't afford to develop.

Developer first

Developer first is a poor fit when the product has to win on experience. Against well-designed competitors, a developer can build something that works flawlessly and still doesn't get used. It also goes wrong when nobody has talked to users, because then the developer guesses at the flows, and that's an expensive way to guess.

One developer on their own

Skipping the designer is a poor fit when the brand is part of the product, the flows are complex, or there are many user types with different needs. It also fails if you expect the developer to produce a logo, illustrations, and a visual identity. That's a different profession.

If you need design, copy, and development from one place at the same time, an agency may be the better choice. My comparison of freelancers and agencies covers when that pays off.

How I work with designers

When a designer is on the project, I prefer to run design and development in overlapping steps rather than two separate phases:

1. The developer joins at the first wireframes. Saying "this part is expensive to build" or "there's a standard pattern for this" takes a minute and can save weeks.
2. The design is done in Figma, which I also work in, using the same components the code uses. A button in the design is then a button in the code.
3. The designer stays one step ahead. While the first flow is being built, the next one is being designed.
4. The design covers the boring states too: empty lists, errors, loading, mobile, and accessibility basics like contrast and keyboard use. Those are most often missing, which leaves the developer guessing.
5. The design files live in your company's Figma account, for the same reason the code is yours from day one.

Accessibility is also a legal matter in the EU: the European Accessibility Act covers many consumer-facing services, such as online shops and banking. If it applies to you, put it in the design brief from the start.

For larger projects I start with a paid, fixed-price discovery phase, where you and I work out whether you need a designer, how much, and in what order.

Next steps

Four questions will usually tell you who to hire first:

1. Who are your users, and what are the three most important things they need to do?
2. What are you least sure about: the users or the technology?
3. Does the look of the product help sell it?
4. Do you already have a design system or brand guidelines?

If your answers point to users and experience, start with a designer. If they point to data and integrations, start with a developer. If both are fairly simple, one developer with design sense can build version one, and a designer can join later. My page on how I price projects shows how discovery and fixed pricing fit together.

Frequently asked questions

Can a UX designer also write code?+

Some can, but rarely to the standard a live product needs. Plenty of designers know HTML and CSS or build advanced prototypes, which makes collaboration easier. The database, permissions, integrations, and security are developer work. Don't expect a designer to build your back end, or a developer to run your user research.

What should a designer hand over to the developer?+

A Figma file built from components, every screen in desktop and mobile sizes, and the easily forgotten states: empty, error, and loading. Add colors, typography, and spacing defined in one place, font and icon licenses, and a clickable version of the main flows. Anything missing is something the developer will end up guessing.

Can I use a UI kit or template instead of hiring a designer?+

Yes, for a first version that's often a smart choice. Pick a kit that matches the framework your developer uses, and check the license before you buy. Avoid customizing it until it no longer resembles the original. At that point you're paying for design work anyway, just without a designer.

Is a product designer the same as a UX designer?+

Not quite. A product designer usually covers both UX and UI and often helps decide what the product should do and in what order. In small companies the titles overlap so much that the difference is hard to see. Ask for a portfolio that shows the process, not just polished screens, so you can tell whether the person has tested ideas with real users.