Jordan Lord put up a short, dense post on design constraints that earns its keep. It's not language- or stack-specific - it's about how to think about what you're building before you start.
His three constraints:
-
One page or it doesn't get built. If you can't fit the idea on a single page without padding, you're not ready. The one-pager doubles as the communication artifact and the tiebreaker when arguments over scope come up: if something isn't in the one-pager, it's either not worth fighting over, or the one-pager needs to be amended. If it didn't get mentioned, it's not relevant or it should have been included.
-
The core tech must be separable from the product. Build a method, a tool, or a library that supports the product but could survive without it. That piece is what compounds over time, independent of where the product itself ends up going. Build something durable that can outlast the seed idea.
-
One defining constraint must shape the product. Pick a constraint that the user sees and feels everywhere - Lord's examples are Minecraft's blocks and IKEA's flat-pack - and let the rest of the design fall out of it. Without that anchor, the product tries to do everything and doesn't have an identity. The constraint helps keep the project in line.
What makes the post worth pointing at, beyond the constraints themselves, is the layering: scope, leverage, and identity each get their own constraint. That's a useful frame for sanity-checking a new project, and probably more useful for sanity-checking an existing one that's drifting.