Complete blocks. Agent-ready APIs. Product work first.

ds-start came out of repetition. I was building a lot with AI — spinning up Next.js projects, wiring up the same strict TypeScript config, the same oxlint and oxfmt setup, the same pre-commit hooks, the same env validation, the same API route patterns. Every new project started with hours of setup before I could write a product feature.

Worse, every time I started a new AI coding session, I had to re-explain the project conventions, the quality gates, the patterns I wanted followed. The AI assistant had no memory of how I like to work.

So I built the starter I wished I had. One command, and you get a project where the tooling is already wired, the types already flow end-to-end, and your AI assistant already understands the codebase conventions from the first prompt.

Then the starter grew. People wanted auth, email, payments, forms — but not always at scaffold time, and not as raw library dumps. So ds-start became composable: a foundation you start from, plus functional blocks you bolt on later. Same templates, same conventions, whether you scaffold fresh with init or extend an existing app with add.

The latest evolution is the interactive wizard. Instead of passing flags or answering yes/no prompts one by one, you choose a build path — recommended production starter, app with auth, or base app — and the wizard walks you through the rest. Three presets cover the common cases; flags and --base remain for CI and power users.

ds-start is deliberately opinionated. It picks a stack and commits to it. That's not a limitation — it's the point. Opinions eliminate decisions. Decisions slow you down. When everything from your ORM to your commit messages follows a known convention, both you and your AI assistant can move faster.

The stack reflects what I actually build production apps with: