Being the sole implementer forces a designer to think more systematically. Instead of designing two bespoke UIs for similar tasks, the implementation overhead encourages creating a single, reusable component that works in both contexts. This leads to a more coherent and maintainable product by necessity.
Related Insights
At Perplexity, the design system lives in the codebase, not Figma. Designers contribute directly to the frontend, creating a single source of truth that eliminates drift between design files and production code, forcing a highly practical and collaborative process.
As a solo builder, you can't afford to perfect every UI element. Instead, identify the 20% of components that drive 80% of user interaction and obsess over their details. For the rest, use libraries and minimal systems to ensure consistency without getting bogged down.
The idea that design systems stifle creativity stems from the high cost of re-coding components after a design change. In a world with a single source of truth, where design changes automatically update the code, this cost disappears, allowing systems to be radically changed without engineering overhead.
Design is often mistaken for aesthetics, like choosing a border radius. Its real function is architectural: defining the simplest possible system with the fewest core concepts to achieve the most for users. Notion's success, for example, comes from being built on just blocks, pages, and databases, not from surface-level UI choices.
Instead of siloing roles, encourage engineers to design and designers to code. This cross-functional approach breaks down artificial barriers and helps the entire team think more holistically about the end-to-end user experience, as a real user does not see these internal divisions.
For individuals who both design and code, finishing a visual design isn't a moment of triumph but one of dread, as they know the lengthy process of coding it from scratch has just begun. This specific emotional pain point is a core motivator for building next-generation tools that eliminate this redundant step.
Building a true platform requires designing components to be general-purpose, not use-case specific. For instance, creating one Kanban board for sales, support, and engineering. This thoughtful approach imposes a ~20% development 'tax' upfront but creates massive speed and leverage in the future.
Inspired by architect Christopher Alexander, a designer's role shifts from building the final "house" to creating the "pattern language." This means designing a system of reusable patterns and principles that empowers users to construct their own solutions tailored to their unique needs.
The co-founder, a designer, learned React to bypass the classic frustration of developers misinterpreting high-fidelity mockups. By designing directly in code, he maintains full control over the final UI, eliminates the handoff process, and saves significant time and back-and-forth.
For complex systems with diverse use cases (like EDI), building a comprehensive UI upfront is a failure path because you can't possibly anticipate all needs. The better approach is to first build a robust set of developer-focused APIs—like Lego blocks—that handle core functions. This allows you (and customers) to later assemble solutions without being trapped by premature UI decisions.
