Design Every App Before You Code

Key takeaways

Vibe coding is fast to start and slow to finish: every prompt patches the last one.
Make every design decision before the first file is touched, then hand the AI a spec.
Design every screen in four states: empty, loading, populated and error.
An hour of design saves two to three hours of building and fixing.

Vibe coding is everywhere right now, and plenty of business owners are trying it.

The idea is simple: describe what you want, let the AI build it, iterate on vibes. No spec, no design, no plan. Just prompt and ship.

I get the appeal. It's fast to start. You can have something on screen in 20 minutes. It feels productive.

It isn't.

What you're actually building when you vibe code is a house of cards. Each prompt patches something the last prompt broke. The AI has no context for why decisions were made, so it makes new ones that conflict with old ones.

Dead code accumulates. Security gaps appear in places you never thought to check. The codebase has no center of gravity because no one ever gave it one.

You can feel it in the output:

Inconsistent spacing.
Components that almost look the same but not quite.
Five different ways to handle a loading state.
A mobile layout that was clearly an afterthought.
An error state that surfaces a raw stack trace.

The product works, technically. It just doesn't feel right. And by the time you notice, you're too deep to rebuild cleanly.

There's a better way. It's not slower - it's actually faster. And the output is in a different league. It's the same process behind every system I build in AI OS.

The Vibe Coding Trap

Here's what happens when you start coding without a design:

You're making a hundred small decisions under pressure with no reference point:

Where does this button go?
What happens when the table is empty?
How does this transition feel?
What does the mobile nav look like at 375px?

These aren't code questions. They're design questions. And when you answer them in the middle of a build, you answer them inconsistently. Page 3 gets a different answer than page 1 because you've forgotten what you decided in week one, the AI certainly hasn't retained it, and the path of least resistance is just to make something work right now.

The result ships. But the codebase is carrying every one of those rushed decisions as dead weight.

Security holes open up because no one thought through the data model before it was built. Unused variables and abandoned branches pile up because every iteration left residue. The component library fragments because the AI rebuilt something from scratch instead of using what existed.

Testing becomes a nightmare because there's no spec to test against. QA finds edge cases the AI never considered because no one considered them upfront. Bugs get patched rather than fixed because the root cause is architectural, not syntactic.

This is the house of cards. It stands until it doesn't.

What Design-First Actually Means

I'm not talking about making pretty mockups. I'm talking about making every significant decision before the first file is touched.

That means:

What does every page look like with data, without data, loading, and in an error state?
What happens on a 375px mobile screen - explicitly, not just "it's responsive"?
Where do the primary actions live and what hierarchy do they carry?
What's the exact type scale, color token, and spacing unit - sourced from the design system, not invented inline?
What does the empty state say and what action does it offer?

These questions sound obvious. Most developers skip them anyway because answering them upfront feels slow. What actually feels slow is answering them after you've already built the wrong thing - or watching an AI patch over the gap with something that doesn't match anything else on the screen.

When you do this work first, you hand the AI a spec. Not a vibe. A spec. And an AI coding tool with a spec produces something dramatically better than the same tool without one.

The Workflow I Use

I run two paths depending on what the project needs.

Path A - a design tool. I take a snapshot of the current app - screenshots, page docs, component inventory - zip it, and bring it into a design environment. We work through the layouts together.

The output is an artboard with all four states designed at desktop and mobile. I annotate the functionality inline. When it's approved, that artboard becomes the design brief.

Path B - Figma. For anything complex - multi-step flows, component libraries, team collaboration - I use Figma with the app's actual design tokens loaded. Same colors, same type scale, same spacing the code will use.

No invented hex values. No made-up fonts. The design is built with the production system so the handoff is exact.

Both paths produce the same output: a design brief. Every state designed. Every decision made and annotated with why. That brief is what gets handed to the coding tool.

The Handoff Package

This is the part that separates structured development from vibe coding.

Before any code gets written, the coding tool gets:

The approved design brief - all states, all annotated decisions, all edge cases
The app's design system contract - every token, every rule, every banned pattern
The component inventory - what already exists and must be reused, not reinvented
An architecture plan - a specialist pass maps the brief to the code structure before a line is written

The coding tool doesn't guess. It executes against a spec. The code it produces is tighter, more consistent, and requires dramatically less revision.

A build gate catches any file that compiles wrong. A validation pass checks the result against the brief before anything ships.

No dead code because nothing gets built that wasn't in the spec. No security gaps from unconsidered data flows because the data model was designed upfront. No inconsistency because every component was built against the same brief, the same tokens, the same system.

Why This Is Actually Faster

The counterintuitive result is that design-first ships faster than vibe coding.

Every hour spent in the design phase saves two to three hours in the build phase - not because you're writing less code but because you're writing it once, in the right direction, against a clear target.

When I hand a vague request to an AI coding tool, I get something that needs three rounds of revision and a QA pass to catch edge cases. When I hand it a crisp brief with all four states designed, I usually get something shippable in the first pass.

The testing burden drops to near zero because the spec covered the edge cases before they became bugs. The QA pass becomes a quick check against the brief rather than an open-ended hunt for broken states. The codebase stays clean because the AI had a clear answer to every question before it had to ask.

The diff between the two approaches compounds. One build cycle of vibe coding leaves a manageable mess. Ten build cycles leaves a codebase that no one wants to touch.

The Standard I Hold Every Screen To

Every page in my apps has to be designed in four states before any code ships:

Every screen, four states

State	What the user sees	The rule
Empty	No data yet, and what to do next	Always offer the next action
Loading	The populated layout with a skeleton over it	Never a blank white screen
Populated	All real states: long text, short text, overflow	Design the edge cases, not just the happy path
Error	A clear message and a way to recover	Never a raw error string

If a state is not designed, the AI invents it, and every page invents it differently.

Every page has to be explicitly designed at 375px mobile and 1280px desktop - not just "make it responsive."

These requirements live in the design contract of every app. They're not suggestions. They're gates. Nothing ships that doesn't clear them.

Build It Right From the Ground Up

The vibe coding crowd will tell you structure slows you down. It doesn't. Rework slows you down.

Debugging code you can't reason about slows you down. Explaining to a client why their app has a security hole because no one thought through the auth flow slows you down.

The operators building the best products right now are the ones who do the uncomfortable work at the front. They spend more time than feels natural making decisions on paper before making them in code. They resist the urge to just start.

The payoff is a product with a center of gravity. One that feels intentional because it was. One where every page feels like it belongs to the same app because every decision was made against the same brief, the same tokens, the same design system.

That's what design-first builds. A foundation, not a house of cards. For where this fits in your first month with an AI system, see Your First 30 Days With an AI System.

Want to see how I'd structure this process for your specific build? Book a consulting call and we can map it out.

Questions people ask

What is vibe coding?

Describing what you want to an AI and iterating on feel, with no spec, no design and no plan. It gets something on screen fast and gets harder to change every round.

Does designing first slow the build down?

No. Rework slows you down. With a clear brief the AI usually produces something shippable on the first pass.

What goes to the AI before it writes code?

The approved design brief, the design system rules, the list of components that already exist, and an architecture plan.

Sources

Next: Your First 30 Days With an AI System → ← Back to Writing