# Do you need a designer before you build?

*By Roberto Lazar, founder of Dock30 · Published 2026-07-18 · Updated 2026-07-18 · 7 min read*

A founder's rule for when to hire a designer before development, when a component library is enough, and what building first quietly costs you later.

You need a dedicated designer before you build when the interface is the product: a consumer app, a conversion-critical marketing site, a payment or onboarding flow with real branching, anything on mobile. You can skip one when a component library already answers the design questions for you: internal tools, simple CRUD apps, an MVP whose only job is to find out whether anyone will pay. The rule we give clients is short. **Design earns its place when a wrong screen costs you a customer, and it does not when a wrong screen costs you a five-minute edit.**

The reason this is even a live question in 2026, and not the automatic yes it was a decade ago, is that the floor has moved. Component libraries like [shadcn/ui](https://ui.shadcn.com/) hand you accessible, well-spaced buttons, forms, tables, dialogs, and navigation for free. A developer with taste and a good kit can now produce something that looks intentional without a designer ever opening Figma. That does not make designers optional across the board. It means the set of projects where you can honestly skip one got bigger, and knowing which side of that line you are on saves real money.

## When you can skip the designer

Skip dedicated design when the product has an established pattern and an audience that will forgive a rough edge. Four cases come up again and again.

Internal tools and dashboards are the clearest. Your own team is the user, the layout is tables and forms and charts, and nobody churns because the filter dropdown is a shade off. A component library covers the whole surface. We build a lot of [dashboards and internal tools](/services/custom-development) this way, and paying for custom design on most of them would be spending the client's money to impress the client's own staff.

Simple CRUD apps sit in the same bucket. If the app is create, read, update, delete over some records, with auth and a settings page, the design decisions are mostly solved problems. A kit gives you a coherent look, and the hours you would have spent on design go into the parts that are actually specific to the business.

An MVP built to test demand is the case founders most often get wrong in the expensive direction. The goal of that build is one answer: will anyone pay, sign up, or use this. A polished interface does not change that answer, and if the idea does not land you have spent design budget on a product you are about to throw away. Ship the plain version, watch what happens, then design once the market has told you the thing is worth polishing.

The fourth case is a strong existing design system. If you already have defined tokens, components, and patterns, whether from a previous product or a mature kit your team has extended, a competent developer can assemble new screens inside those rails without a designer in the loop for each one. The design work was done; you are just spending it.

## When skipping is a mistake

The other side of the line is where I have watched founders lose the most, usually because the build looked cheaper up front.

Anything consumer-facing needs design before code. When a stranger with no obligation to you lands on the product and decides in seconds whether to stay, the interface is not decoration, it is the pitch. This is where the ROI numbers earn their reputation: the often-cited Forrester figure is that every dollar put into UX returns around 100, and well-executed UX has been tied to conversion lifts of up to 400% in [roundups of UX research](https://userpilot.com/blog/ux-statistics/). Treat those as directional rather than gospel, but the direction is not in doubt.

Conversion-critical marketing sites are the same argument with a sharper edge, because the entire point of the page is to turn attention into a signup or a sale. A component library will make it tidy. It will not make the argument, choose what the eye hits first, or earn the click. That is design work, and skimping on it on the one page whose job is revenue is a strange place to save.

Complex or novel flows are where a component library runs out of patterns. Multi-step onboarding, a checkout with edge cases, a scheduling or permissions flow with real branching: the library has no pre-built answer, so someone is designing it whether you hired a designer or not. The only question is whether that someone is a designer thinking about the user or a developer improvising between tickets. On flows that carry money or data, that difference shows up in support load for years.

Mobile apps belong here too. The interaction rules are stricter, the platform conventions are unforgiving, and a web-shaped layout on a phone reads as broken to users who live in well-designed apps all day. We treat design as a real phase on every [mobile app](/services/mobile-apps) we build, and the cost of getting it right up front is documented in our [mobile app cost breakdown](/blog/mobile-app-cost-2026).

Here is the same decision in a table.

| Situation | Designer first? | Why |
|---|---|---|
| Internal tool or admin dashboard | No | Your team is the user; a kit covers it |
| Simple CRUD app | No | Design decisions are solved patterns |
| MVP to test demand | No | Polish does not change the yes-or-no answer |
| Consumer-facing product | Yes | The interface is the pitch |
| Conversion-critical marketing site | Yes | The page's whole job is the click |
| Complex or branching flow | Yes | The library has no pattern for it |
| Mobile app | Yes | Platform conventions are unforgiving |

## The hidden cost of building first and designing later

The build-now-design-later plan looks like the cheap option because you defer a cost. You do not remove it. You move it to the most expensive place it can land.

Software teams have measured this for decades, and the shape is always the same: a problem caught early is a fraction of the cost of the same problem caught late. Analyses of defect cost across the development lifecycle put the multiplier between catching an issue in design and catching it in production at roughly two orders of magnitude, the old IBM "rule of 100" that QA teams still quote in [current cost-of-defect breakdowns](https://contextqa.com/blog/cost-of-defects-in-software-testing/). A design flaw is a defect. When it lives in a Figma file, fixing it is dragging a box. When it lives in shipped code, fixing it is an engineering ticket, a review, a QA pass, and a redeploy, and if users already learned the broken flow, a migration and a support burden on top.

There is a quieter cost that does not show up on any invoice. When you build first, the first working version becomes the default, and defaults are sticky. The team gets used to it, sunk cost sets in, and the redesign that should have been the starting point turns into a fight nobody wants to have. Plenty of products limp along for years on an interface everyone privately knows is wrong, because rebuilding it now costs more than designing it right would have at the start. That is not a design problem anymore. It is a business one.

None of this is an argument that every project needs a designer. It is an argument that the projects that do need one need the design before the code, not bolted on after.

## How we decide it with clients

Because we do design and development [under one roof](/services/design), we have no incentive to sell you a phase you do not need. On an internal tool or a demand-test MVP, we will tell you to skip dedicated design and let a component library carry the interface, and we will put those saved hours into the build. On a consumer product, a revenue page, or a mobile app, we will push to design the core flows first, because we are the ones who inherit the rework if we do not, and rework is the most expensive way to build anything.

Whichever side you land on, the commercial terms are the same. Fixed-scope projects start at **EUR 350**, with the exact price and delivery date in writing before any work begins ([how project pricing works](/pricing/project)). If the honest answer is that you do not need us to design anything yet, that is a fine call to end. If you are not sure which side of the line your project sits on, that is exactly the kind of thing worth ten minutes: grab a [free 15-minute call](https://calendly.com/dock30/15min) or [tell us what you are building](/contact), and I will tell you straight whether a designer earns their place on your project or whether a good kit and a developer will do.

## Frequently asked questions

**Do I need a designer before I start building my app?**

You need a dedicated designer when the interface is the product: a consumer app, a conversion-critical marketing site, or any flow with real branching. You can skip one when a component library already answers most of the design questions, which is the case for internal tools, simple CRUD apps, and MVPs built only to test demand. The deciding question is whether a wrong screen costs you a customer or a five-minute edit.

**Can I build a product with just shadcn/ui or a Tailwind kit and no designer?**

Often yes, for the first version. A component library like shadcn/ui gives you accessible, sensible defaults for buttons, forms, tables, and layout, which covers most of what an internal tool or a straightforward SaaS dashboard needs. It stops being enough the moment you need a distinct brand, a custom flow the library has no pattern for, or a page whose entire job is conversion.

**Is it cheaper to design first or fix the design after building?**

Designing first is cheaper for anything non-trivial. Rework compounds: a change that is a quick edit in a design file becomes an engineering ticket, a QA pass, and a redeploy once it is built in code. Studies of defect cost put the gap between catching a problem in design versus in production at roughly two orders of magnitude.

**What does a designer actually prevent that a developer does not?**

A designer prevents flows that make sense to the person who built them and no one else. That includes confusing navigation, forms that ask for the wrong things in the wrong order, and screens that technically work but quietly lose users. Developers are good at making a design real; they are not a substitute for someone whose job is deciding what the design should be.

**When is hiring a designer a waste of money?**

When the thing you are building has an established pattern and a small, tolerant audience. An admin panel your own team uses, a CRUD tool, or a rough MVP whose only goal is to see if anyone will pay does not need bespoke design. Spend that budget on shipping and learning, then design once you know the product is worth polishing.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact