There’s a temptation in software to start building immediately. Open a terminal, scaffold a project, start writing components. It feels productive. But I’ve found that the projects I’m most proud of — the ones that hold up over time — are the ones where I spent real time planning before writing a single line of code.
What design-first means
Design-first doesn’t mean creating pixel-perfect mockups in Figma before touching code. It means understanding the structure, the relationships, and the constraints before committing to an implementation.
For a website, that looks like:
- Gather references and inspiration
- Reverse engineer what makes them work
- Define a component system and design tokens
- Plan the build order
- Then build
The value of reverse engineering
Looking at a well-built site and asking “how did they do this?” is one of the best ways to learn. Not to copy — but to understand the systems behind the surface. What are the repeating patterns? How is spacing consistent? What components are reused?
Components over pages
The biggest shift in thinking is from “I need to build a homepage” to “I need to build a system of components that can compose into a homepage.” The homepage is an output, not the unit of work.
When to stop planning
Planning has diminishing returns. The goal is to have enough clarity to build confidently, not to anticipate every edge case. If you can describe the component system, the page structure, and the build order — you’re ready to start.