A 10-year builder distills three hard filters: one-pager or don’t build, separable core tech, and one defining product constraint.
Key Takeaways
The one-pager rule is binary: if you can’t fill a page without fluff, you’re not ready to build – iterate until you can.
“Separable core tech” means the underlying method, library, or tool must survive a product pivot; it compounds independently of any single product direction.
Examples given: Linus Torvalds built git to serve Linux kernel workflow; HashiCorp has HCL; Google open-sourced Kubernetes.
The third constraint is a visible, user-facing product primitive – like Minecraft’s blocks or IKEA’s flat-pack – that collapses decision space and prevents bloat.
All three gates are applied together: if an idea fails any one, it doesn’t get built.
Hacker News Comment Review
The “defining constraint” concept maps closely to what some call product primitives: Notion blocks, Figma frames, Excel cells, Twitter tweets – the atomic unit that permeates every interaction and drives design decisions downstream.
The separable-core-tech rule drew the sharpest pushback: critics noted it risks premature abstraction and that a domain layer will always be tied to the product regardless of how cleanly it’s extracted.
Commenters who have shipped products validated the one-pager most strongly – the consensus is that skipping alignment upfront leads to discovering wrong-direction flaws mid-build, not just bugs.
Notable Comments
@csallen: Extends the third constraint with a taxonomy of product primitives across Notion, Figma, Telegram, Excel, and Photoshop – argues good product design falls out of a well-chosen primitive.
@codethief: “Won’t this lead to premature abstraction” – flags that domain layers are inherently product-coupled regardless of separation intent.
