Every developer has a "starter project." Some keep a GitHub template. Some duplicate their previous SaaS project. Some run create-next-app and spend the next two hours installing the same dependencies, configuring the same tools, and recreating the same folder structure.
I was in the second group. Every new project started the same way.
bun create next-app
Then came the checklist.
- Install Tailwind CSS.
- Configure Biome.
- Add shadcn/ui.
- Organize folders.
- Set up a UI library.
- Configure TypeScript.
- Add environment files.
- Set up a monorepo.
- Copy utility functions.
- Configure path aliases.
- Install development tools.
None of these tasks were difficult. They were just repetitive. After starting enough projects, I realized something:
I wasn't building products. I was rebuilding the same foundation over and over again.
The Starter Kit Trap
Like many developers, I created a "starter repository." Whenever I wanted to build something new, I'd clone it. It worked... until it didn't.
Eventually I had multiple starter repositories.
- One for a monorepo.
- One for a standalone project.
- One with authentication.
- One without authentication.
- One for experiments.
- One that was already outdated.
Keeping them synchronized became its own maintenance project. Fix a bug in one. Forget to fix it in another. Upgrade Next.js in one repository. Forget the rest.
The more starters I created, the less useful they became.
Why Existing Starters Didn't Quite Fit
There are already fantastic starter kits in the ecosystem. Some focus on minimalism. Others include every feature imaginable. The problem wasn't that they were bad. The problem was that they optimized for someone else's workflow.
Every project I build starts with almost the same stack.
- Next.js
- TypeScript
- Bun/pnpm
- Tailwind CSS v4
- shadcn/ui
- Biome
- Production-ready project structure
I didn't want to answer twenty configuration questions every time I scaffolded a project.
I wanted one command.
npx create-notils my-app
…and be ready to start building.
Opinionated Doesn't Mean Inflexible
One thing I've learned is that being opinionated is often a strength. Frameworks like Laravel, Rails, and even Next.js provide sensible defaults. You can always change them later. The important thing is that you're productive on day one.
That's the philosophy I'm following. Instead of trying to support every possible technology combination, I picked a stack that I genuinely enjoy using every day.
Everything generated by the CLI lives inside your repository.
- Nothing is hidden.
- Nothing is hosted.
- Nothing prevents you from changing it.
The starter gives you a foundation—not a cage.
Building for Myself First
A question I've been asked is:
"Why not make everything configurable from the beginning?"
Because I'm the first user. The goal wasn't to build the most flexible scaffolding tool. The goal was to eliminate repetitive work from my own workflow. Once something proves useful in real projects, it can become configurable.
Until then, I'd rather spend my time building products than building configuration screens.
The Beginning of create-notils
That idea eventually became create-notils.
Right now, it focuses on doing one thing well:
- Scaffold a modern Next.js project.
- Support both standalone and monorepo layouts.
- Configure a shared shadcn/ui setup.
- Use Bun, Biome, Tailwind CSS v4, and TypeScript out of the box.
It's intentionally small.
Future releases will add authentication, database integration, API clients, Docker support, and more—but only after those features have been battle-tested in my own projects.
What's Next?
One design decision turned out to be far more interesting than I expected. I wanted to support both standalone projects and monorepos. Most tools solve this by maintaining two different templates.
I chose a different approach: The monorepo is the single source of truth, and the standalone project is generated from it through a deterministic transform.
That means I only maintain one project while generating two different project shapes.
In the next article, I'll dive into how that architecture works, why I chose it, and how it avoids template duplication.
I'd love to hear how you start new projects.
Do you use GitHub templates, starter repositories, scaffolding tools, or something completely different?
