Designer First or Engineer First? Getting This Order Backwards Costs a Lot of People Double

There's a certain feeling I've seen in a lot of people right as they're about to start building a website.

They're ready to move. They have a product, an idea, a clear picture in their head — what the site should look like, what color palette, what goes on the homepage. Excited, and certain.

So, step one: find a designer.

They find one, talk it through, and the designer starts sketching. A few weeks later, a polished visual comp shows up on screen, and it feels great — the brand finally has a face.

Then the comp gets handed to an engineer: "Can you build this?"

And that's where the story starts going sideways.

The engineer looks at the comp and goes quiet for a second

"This animation is doable, but it'll take a while." "This checkout flow doesn't match the payment API we planned to use — we'd need a separate integration." "This layout is hard to pull off on mobile. What you're looking at is the desktop comp — where's the mobile version?"

One question after another.

Some can be solved, but the cost of solving them is time, and the cost of time is money. Some can't be solved at all — the underlying logic behind certain effects in the design simply isn't compatible with the tech stack that was chosen. To make it work would mean switching stacks, and switching stacks means starting over.

This isn't the engineer being difficult, and it isn't the designer doing anything wrong.

It's that these two roles never had a conversation in the same room.

Flip the order, and it's still a problem

Once people learn about this trap, some decide to flip the order: find an engineer first, confirm technical feasibility, then bring in a designer to make it look good.

That logic isn't wrong, but it gets stuck in practice too.

The engineer builds out the functionality, the pages run, everything works, no bugs, the logic is clean. But the whole site looks like an uncolored sketch — nothing gives anyone a reason to stay.

By the time the designer comes in, the page structure is already set. The nav bar lives in that exact spot, the sections are arranged for technical reasons, and any change to a section runs into "that touches backend logic." The designer ends up making changes within a shrinking box, and what comes out the other end is a compromise — not a piece of work with a coherent visual intent.

Designer first, and the design gets bounded by technical reality. Engineer first, and the tech gets bounded by design arriving too late.

Both orders come with their own cost.

The problem isn't the order — it's that nothing got clarified first

After watching this play out for years, I've come to think the real problem isn't "who goes first." It's that before bringing anyone in, we never actually nailed down one thing: what problem is this website supposed to solve?

Not "I want an e-commerce site." That's a format, not a problem.

It's: where do our customers come from, what decision are they making on the site, what's the one action that matters most — placing an order, filling out a form, contacting us? How much budget do we have, and how many months until launch?

Think that through, write it down, and bring that document into every conversation with anyone you hire. A designer who reads it knows what to design. An engineer who reads it knows roughly where the technical complexity sits, and can give a far more accurate estimate.

Without that document, you'll take the long way around no matter who you hire.

So if you really have to pick who goes first

If forced to choose, my observation is: in most cases, talking to the engineer first saves more trouble.

The reason is straightforward: technical constraints are objective, design possibilities are open-ended. Understand what's technically feasible first, roughly where the cost range sits, what off-the-shelf tools could save effort — then bring those constraints to the designer, who can make the best choice within a realistic space.

Do it the other way around, and design tends to come first, technical implementation gets found later, and you easily end up "held hostage by a beautiful comp" — the more polished the visual, the harder it is to accept "this can't be done" or "this costs a lot more."

That's not to say design doesn't matter. It matters a great deal — its impact on first impressions and conversion is very real.

It's just that before any of that, we need to know what ground we're standing on.

AI tools have changed some things — but not this one

In 2026, there are plenty of AI tools that can generate a design comp or a chunk of code in a hurry. Some people think this means the designer and engineer roles matter less.

I don't think that's right.

AI tools make prototypes appear faster, and let a first version get validated at lower cost. But they can't do the thinking for you on "what problem this website needs to solve." That question still needs a person to answer.

The cost of getting the order wrong is really about spending your most expensive resource — the decision-maker's time and trust — on a question that was never properly thought through. Whether it's the designer or the engineer, both are there to help turn an idea into reality. But if the idea itself is still vague, whoever goes first will hit the same wall.

So, how to actually start

One very practical suggestion: before hiring anyone, spend an hour or two writing the following on a single page.

• Who is this website for.
• Where will they find us.
• What's the single most important action once they arrive.
• How much time and budget do we have.
• Which features are essential, and which are nice-to-have.

It doesn't need to be exhaustive — rough is fine. That one page will make every conversation after it far more efficient.

Then, with that page in hand, find someone willing to actually listen before touching anything, whether that's a designer or an engineer. Finding someone willing to listen first is already an important filter on its own.

The order was never really the point. Clarity is.

Every time I hear "we found a designer first, and then the engineer said it couldn't be built," I can't help but think: it was never a sequencing problem. It's that the conversation in between never actually happened.