Opinionated by Design: Why I Chose Sensible Defaults Over Endless Configuration

When people hear about a new project scaffolding tool, one of the first questions they ask is: "Can I choose React Query or TanStack Query?" "What about pnpm instead of Bun?" "Can I use ESLint instead of Biome?" "Can I choose Radix instead of Base UI?" "Can I skip Tailwind?" These are reasonable questions. In fact, I asked myself the same ones while building create-notils . My first instinct was to make everything configurable. The more I thought about it, the more I realized I was about to build something I didn't actually want to use. The Configuration Trap Most project generators start simple. Then someone requests another option. Another package manager. Another ORM. Another authentication provider. Another CSS framework. Another UI library. Eventually the CLI starts looking like this: ? Which package manager? ❯ npm pnpm yarn bun ? Which CSS framework? ? Which ORM? ? Which auth library? ? Which formatter? ? Which icon library? ? Which deployment target? It feels flexible. But every new option creates more combinations to support. Five choices in one prompt don't create five possible projects. They multiply with every other prompt. The complexity grows much faster than the number of features. I Built the Tool I Wanted to Use One thing I've learned from building side projects is this: the first user should always be yourself. Every project I start today uses almost exactly the same stack: Next.js 16 React 19 Bun Tailwind CSS v4 shadcn/ui Base UI Biome TypeScript Turborepo (when needed) I wasn't switching between ten different combinations every week. I was rebuilding the same foundation over and over. So instead of asking twenty questions during scaffolding, I decided to optimize for the workflow I actually have. npx create-notils my-app A few seconds later, I'm writing features instead of answering prompts. Opinionated Doesn't Mean Closed There's an important distinction between opinionated and restrictive . Some tools hide their implementation behind abstraction