A few days ago, I published my open source npm package: starter-structure-cli.
It’s a Node.js CLI that scaffolds production-ready starter projects from simple stack tokens.
You can run something like:
npx starter-structure-cli my-app react vite ts tailwind express prisma postgres
and get a structured project generated for you instead of spending hours wiring everything manually.
Since publishing it, I’ve been improving it quickly, and today I shipped v0.3.0.
What made this update especially exciting for me is that the package also started getting real usage.
From March 3, 2026 to March 9, 2026, it got 480 downloads.
In the following week, it got 35 more downloads.
That brings it to 515 total downloads across the last two weeks.
It’s still early, but seeing people actually try something I built has been genuinely motivating.
What starter-structure-cli does
The goal is simple:
Start coding faster without repeating the same setup work again and again.
Instead of manually creating folder structures, wiring frontend and backend pieces together, setting up ORM config, styling, auth, and other repetitive boilerplate, the CLI gives you a working baseline from the stack you choose.
It currently supports technologies like:
- React
- Next.js
- Vue
- Vite
- Tailwind CSS
- shadcn/ui
- Express
- NestJS
- Prisma
- Mongoose
- Sequelize
- MongoDB
- MySQL
- PostgreSQL
- JWT
- NextAuth
And it organizes templates across these project types:
- Single App
- Frontend-only
- Backend-only
- Fullstack
- Monorepo
- Turbo Monorepo
With v0.3.0, the catalog now supports 36 production-ready starter templates.
What’s new in v0.3.0
This release focused on three things:
- expanding the template catalog
- cleaning up the CLI internally
- strengthening release quality
New starters added
I added several new templates, including:
- Fastify + Prisma + PostgreSQL backend starter
- Next.js + TypeScript + shadcn/ui + Tailwind starter
- React/Vite + Prisma + PostgreSQL fullstack starter
- Vue/Vite + Prisma + PostgreSQL fullstack starter
- additional backend, single-app, and fullstack combinations
That pushed the catalog to 36 starter templates.
A cleaner CLI internally
One of the biggest improvements in this release was refactoring the CLI into smaller, more maintainable modules.
I split the logic into separate parts for things like:
- argument parsing
- catalog discovery
- template matching
- prompts
- scaffolding
- constants and aliases
This made the codebase easier to understand and easier to extend as the number of templates keeps growing.
That cleanup mattered a lot, because once a scaffolding tool starts supporting many combinations, the matching and discovery flow can become messy very quickly.
I wanted to improve that before continuing to add more starters.
Stronger validation before release
I also improved the validation and release checks.
The project now verifies things like:
- referenced bases and layers actually exist
- built template outputs are valid
- expected files are present
- template integrity is preserved before publishing
- release quality is more consistent
That gave me much more confidence when shipping updates to npm.
When a project becomes template-driven and composable, validation stops being optional very quickly.
Why I’m building this
I built this because I kept running into the same problem:
Every time I started a new project, I spent too much time on setup before I could start building the real thing.
Not just creating folders, but also:
- organizing frontend and backend structure
- connecting stack pieces together
- configuring database tooling
- choosing a maintainable baseline
- reusing and cleaning up old boilerplate
I wanted a tool that could take simple stack words and give me a serious starting point.
Not a toy template.
Not an empty folder structure.
A real baseline that someone could actually continue building on.
Example usage
Interactive mode:
npx starter-structure-cli my-app
Natural stack-token mode:
npx starter-structure-cli my-app react vite ts tailwind express prisma postgres
List available templates:
npx starter-structure-cli --list
What I learned from shipping this
A few things became very clear while working on this release.
1. Template quality matters more than template count
Adding more starters is useful, but only if the generated output actually feels worth building on.
2. Validation becomes essential very quickly
As soon as templates become composable, release-time checks become necessary.
3. Internal cleanup is part of shipping
Adding features is exciting, but maintainability work is what keeps the project from collapsing under growth.
4. Real users change how you think
Once people start downloading a package, small details start to matter more:
- naming
- docs
- consistency
- output quality
- error handling
- discoverability
What’s next
I want to keep improving:
- template coverage
- matching quality
- documentation
- generated project quality
- the contributor experience for adding new starters
I also want to make template authoring easier over time so the project can grow in a cleaner way.
Try it
npx starter-structure-cli my-app
GitHub: https://github.com/mohosin2126/starter-structure-cli
npm: https://www.npmjs.com/package/starter-structure-cli
If you try it, I’d genuinely love feedback on:
- which stacks you want next
- how useful the generated structure feels
- what would make a tool like this part of your workflow
Top comments (0)