Three constraints a builder uses to kill bad ideas before they ship

A decade-in builder lays out three filters he runs every idea through before committing to build. First: the entire concept must fit on one page. The one-pager becomes the north star for investors, collaborators, and the builder’s own thinking — if you can’t fill it without fluff, you’re not ready; if it overflows, the idea is too complex. Second: the product must contain a separable piece of core technology — a library, language, methodology, or tool — that could survive the product pivoting or dying. Examples cited include git emerging from Linux kernel work, HashiCorp’s HCL, and Kubernetes from Google. The core tech is the compounding asset; the product is disposable.

Third: one defining constraint must shape the user-facing product itself, the way blocks define Minecraft or flat-pack defines IKEA. That constraint is visible everywhere in the UX and forces identity by collapsing the decision space, which in turn prevents feature creep. The closing rule is binary: an idea that fails any of the three doesn’t get built.

The broader thesis is that constraints aren’t limitations but generative — they shrink the search space enough that originality and leverage become tractable. It’s a useful framework for anyone evaluating whether a side project, startup, or internal tool has enough spine to be worth the years it will demand.