The Three-Constraint Filter for Builders

The author proposes three strict constraints—a one-page plan, separable core technology, and a defining product limitation—to filter out bad ideas. These rules are designed to reduce complexity, ensure long-term leverage, and establish a clear product identity. If an idea fails any of these three tests, the author refuses to build it.

Key Points

• A one-page limit for project descriptions ensures clarity, prevents fluff, and manages complexity.
• Core technology should be independent of the product to create compounding value and survive potential pivots.
• A single, defining constraint must shape the user experience and product identity to prevent feature creep.
• Constraints act as enablers for creativity by collapsing the search space and forcing innovative solutions.
• If a project idea fails to meet any of these three criteria, it should be discarded before development begins.

Sentiment

The community is broadly supportive of the framework, particularly the concepts of product primitives and the one-pager discipline. The most enthusiastic engagement comes around extending and enriching the ideas rather than rejecting them. Skepticism is measured and constructive, focused on edge cases and applicability limits rather than fundamental disagreement. The discussion has a thoughtful, collegial tone with commenters building on each other's ideas.

In Agreement

• The concept of 'product primitives' strongly validates the third constraint — the best products have a small number of powerful, composable building blocks that create depth without complexity
• The one-pager constraint is highly valuable: projects that articulate constraints up front succeed far more often than those that wing it and discover constraints painfully during development
• Separating core tech from product is wise, as demonstrated by real examples like Skype separating its P2P backend into a separate company that retained value after the product was sold
• Personal experience confirms the framework — multiple commenters describe independently arriving at similar constraints when building their own businesses
• The framework applies beyond software, with one commenter noting its usefulness for physical design projects like kitchen renovation
• Constraints drive creativity and force clarity of identity, preventing scope creep and feature bloat

Opposed

• Minimizing primitives alone doesn't guarantee good UX — Tana has only two primitives but is devastatingly complex to use, while Google Maps has many primitives but tight UX
• The 'separable core tech' constraint could lead to premature abstraction and over-engineering, and the domain layer will always be tied to the product
• The article's examples for separable tech are questionable — Google/Kubernetes doesn't clearly illustrate the principle, and LLMs blur the line between tech and product
• The one-page limit may be too rigid for complex projects like mars flight control software, which might need hierarchical specifications
• With AI agents, the 'one defining constraint' advice may be outdated — a maximalist approach could now be viable
• The framework likely applies best to small solo projects and may not scale to ambitious team-based efforts