Why I Design in Code
Designing in code eliminates the handoff between mockups and engineering, turning the design phase into the foundation of a production-ready app.

For decades, the software industry has been divided into distinct professions, two of which are designers and developers. Designers would draw pictures of what an app should look like and define the structure and interactions, and engineers translate those pictures into real code.
If you are a startup founder looking to launch a digital product today, there is a better way. The traditional process of wireframing and mockups is slow, prone to translation errors, and ultimately produces a dead-end asset.
I spent decades drawing and designing web applications, and now I design directly in code.
Here is why the old way is dying, how the industry is shifting, and why designing in code is a strong leverage point for a fast-moving startup.
A Brief History of Web Design
If you’ve been in the enterprise web space as long as I have, you’ve lived through every era of this evolution. We used to do things the hard way because it was the only way:
-
The Mockup and Wireframe Era: We drew low-fidelity boxes to focus business stakeholders on function and form without the distraction of colors and typography. We spent days, sometimes weeks, crafting pixel-perfect Photoshop files to sell the "look and feel."
-
The Early Prototype Era: To do early usability testing, we sliced up those mockups in Macromedia Fireworks, stitching them together with image maps just to simulate a button click. We used these as demonstrations and for usability testing with real users.
-
The Golden Age of Prototypes: Tools like Sketch and InVision finally gave us a smoother way to link screens together. Eventually, Figma arrived and replaced them all, becoming the king of the modern design-to-development handoff. But even at its peak, Figma was still a sophisticated tool for drawing pictures.
The Paradigm Shift: Why Code is the Best Canvas
Today, AI code tools allow me to bypass the picture-drawing phase entirely. When a founder gives me a concept, I can picture the solution in my head and immediately start building it in the browser.
Here is why designing in code is a competitive advantage:
-
Speed to Market: We aren't waiting two weeks for a design file to be approved before engineering can start. The design is the engineering.
-
Higher Fidelity and Quality: A picture of a dropdown menu is a poor illusion. A coded dropdown menu handles screen resizing, hover states, and accessibility standards immediately. You see exactly what the user will see, and the same coded interactions you see in the final product can be created during the design phase, saving time.
-
Compound Leverage: When you design in drawing tools, the output is an image. When you design in code, the output is the foundational architecture of your full-stack app. The React or Svelte components generated during the "design" phase are the same components we will wire up to the database to launch the MVP.
-
Infinitely Editable: AI code tools write code fast, and with the right orchestration and validation, we can produce high-quality front-end code and edit it within minutes. We can design the code in components and separate the theme from the functionality, a step beyond merely changing styles; we can apply entirely new skins and switch themes on the fly.
-
Back-end Prototyping: Once the design is solid, the backend can be prototyped, API endpoints added, database schemas explored, and API connections made. The code itself can be transformed into a structure that is extensible and production-ready by simply taking the prototype a step further.
When I began my tech career 30 years ago, I taught myself HTML and CSS by designing in code. I had a small website design and web hosting business in the late 1990s. I had all the drawing tools, but I chose to design in code, so I didn't accidentally draw something I couldn't deliver myself. Today I've come full circle, now delivering designs in the native medium of web applications.
The Elephant in the Room: What About Figma?
I know Figma has a large, loyal following. They are not blind to this industry shift, and they are adapting.
Right now, Figma is rolling out AI features to survive the transition. They’ve introduced tools like First Draft (text-to-UI generation) and Figma Make, which attempt to blur the line by allowing designers to modify production code directly from the Figma canvas. They are pushing developer-centric features like Code Connect and native Dev Mode to keep engineers inside their ecosystem.
But here is my prediction: Figma will eventually lose this battle.
The gravity of native code is strong. As AI coding assistants and visual code-generation tools become more deeply integrated into engineering environments, the need for a separate "canvas" intermediary will evaporate. Ultimately, I believe Figma will either be slowly marginalized by pure AI code tools or acquired by a larger developer-tooling company, not for its drawing canvas, but purely to acquire its user base of product builders.
What This Means for Founders
When you hire a fractional CTO/CPO, or when you are interviewing potential partners like agencies or freelancers, you aren't just hiring people to manage a project; you are hiring a philosophy of execution.
As a founder, you should be aware of these trends because they directly impact your time and money. When you receive bids from potential partners, look closely at their proposed engagement models. If a team is pitching a lengthy, traditional phase of wireframing and static mockups before any code is written, take note. It is a clear indicator to consider whether that model maximizes your runway or relies on an outdated, slow-moving handoff tradition.
By designing in code, I eliminate handoff friction, prevent "lost in translation" errors between design and engineering, and build functional, testable software from day one. I don't waste your runway drawing pictures of an app. I spend it building the app itself.