Build products on simple, foundational concepts rather than complex, rigid features. These core building blocks can then be combined and layered, leading to emergent complexity that allows the product to scale and serve diverse needs without being overwhelming by default.

Related Insights

To introduce powerful features without overwhelming users, design interactions that reveal functionality contextually. For instance, instead of a tutorial on zooming, have the UI automatically zoom out when space becomes limited. This makes the feature discoverable and its purpose immediately obvious.

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.

Square's product development is guided by the principle that "a seller should never outgrow Square." This forces them to build a platform that serves businesses from their first sale at a farmer's market all the way to operating in a large stadium, continuously adding capabilities to manage growing complexity.

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.

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.

Out of ten principles, the most crucial are solving real user needs, releasing value in slices for quick feedback, and simplifying to avoid dependencies. These directly address the greatest wastes of development capacity: building unwanted features and getting stalled by others.

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.

To build a successful product, prioritize roadmap capacity using the "50/40/10" rule: 50% for "low delight" (essential functionality), 40% for "deep delight" (blending function and emotion), and only 10% for "surface delight" (aesthetic touches). This structure ensures a solid base while strategically investing in differentiation.

Creating feature "modes" (e.g., "uphill mode") instead of exposing core mechanics (e.g., gears) creates a "nightmare bicycle." It prevents users from developing a general framework, limiting their ability to handle novel situations or repair the system.

To avoid the customization vs. scalability trap, SaaS companies should build a flexible, standard product that users never outgrow, like Lego or Notion. The only areas for customization should be at the edges: building any data source connector (ingestion) or data destination (egress) a client needs.

Design Principle: Build on Simple Cores That Layer into Emergent Complexity | RiffOn