Build projects faster with a scaffolder that asks what you’re actually building

Developers spend too much time copy-pasting boilerplate, rewriting the same folders, and deleting placeholder content after every create-x-app run. A project scaffolder that asks what you’re building, like project-cli, breaks that loop — mapping the scaffold to your actual intent instead of just your tech stack. This isn’t just a UX flourish; it delivers a starter codebase that’s tailored to the project, not just the framework banner. For anyone shipping marketing sites, dashboards, or chat apps, that distinction is the difference between 40 minutes of cleanup and 4 minutes to code. Here’s how intent-driven scaffolding works, how to use it, and what it enables for serious projects.

What is a project scaffolder that asks what you’re building?

Traditional project scaffolders, from the original create-react-app to create-next-app, start by asking you what framework or stack you want. Answer the stack question, and you get a generic starter — same folders, same "Welcome to my app" page, same junk you spend the next forty minutes deleting or rewriting.

A project scaffolder that asks what you're building, like project-cli, flips that script. The first question isn’t "React, Vue, or Svelte?" — it’s "Are you building a marketing site, a SaaS dashboard, or a chat app?" That one bit of intent powers the entire downstream scaffold: routes, folder structure, starter content, dependencies, and sensible defaults tailored to the actual outcome, not just the framework. As the Medium article makes explicit, the focus is intent first, framework second.

This makes project-cli more than a create-x-app alternative. It’s a scaffolder for different project types — “what are you actually building?” comes first, producing a codebase that fits the project from the start.

Why traditional boilerplate setup slows development

Every developer who’s ever shipped more than one project knows the pattern. You run create-x-app, you get a fresh repo with placeholder copy and demo pages — then the real work begins. Delete the starter page, set up the folders you always need, add routine dependencies, write your .env.example, and remove the “Welcome to my app” that was never meant to ship.

According to the article, for each project this process burns about 40 minutes before a single line of meaningful code is written. Multiply that by team members or frequent prototyping, and it’s a material productivity drag.

The pain points are consistent:

• Deleting placeholder pages and assets
• Redoing folder structure to fit the real project domain
• Reinstalling or adding common dependencies (linting, UI kits, analytics, CI/CD)
• Setting up .env files and reconfiguring build scripts for each use case
• Rewriting generic content that’s only ever meant as a template

Boilerplate code automation misses the mark when it never asks the higher-level question about what you're building. If all you pick is a framework, you get a shell — not a starter for your actual workflow.

How project-cli tailors starter projects to your specific needs

project-cli attacks the root cause by starting from user intent. Instead of immediately asking for a framework, it launches with a question that determines everything downstream: what blueprint are you building?

You run:

$ npx --package=@supunkalharajayasinghe/project-cli project-cli create

The prompts walk through your intent, not your stack:

✔ Project name: my-app
✔ Choose a project blueprint: Website -- landing page, portfolio, business site, documentation
✔ What type of website? One-page landing page
✔ Which sections do you want? Hero, Features, Contact
✔ Add SEO starter files? Yes
✔ Add contact form placeholder? Yes
✔ Add Docker files? No
✔ Add GitHub Actions CI? Yes
✔ Install dependencies after generation? No

The impact: a Next.js project on disk, but shaped around the actual answers you gave — with only the sections you plan to ship, out-of-the-box SEO and contact form wiring, and real starter content that fits. Not a generic “Welcome” app.

It’s not just cosmetic. Project-cli supports three high-level blueprints today:

• Website: Landing pages, portfolios, documentation. Pick single/multi-page, exactly which sections you need (Hero, Features, About, Pricing, FAQ, Contact). SEO files and contact logic set up by default.
• Full-stack Product: SaaS, dashboards; ships with product-focused sections, persistent navigation, auth, and sensible prod/dev builds.
• Chat App: Pre-wired layouts and state, ready for real-time features or bot integrations.

The scaffolded result is closer to a first commit on a real repo than a demo shell. You shape the output by declarative intent, getting boilerplate code automation that fits the way you actually work.

How do I use project-cli today to build my project? Step-by-step guide

Turning this process into a first build is direct. Here’s the minimum reproducible workflow.

1. Install and run project-cli

   No global install. Use npx for the latest version:

   npx --package=@supunkalharajayasinghe/project-cli project-cli create

2. Answer prompts about your project intent

   The CLI session guides you through:

   • Project name (e.g. my-new-site)
   • Project blueprint: Website, Full-stack Product, Chat App
   • For Website: type (one-page, multi-page), and specific sections (Hero, Features, FAQ, Contact, etc.)
   • Whether to include scaffolds for things like SEO, contact forms, CI/CD (GitHub Actions), Docker files

   Example session:

   ✔ Project name: saas-landing
   ✔ Choose a project blueprint: Website
   ✔ What type of website? One-page landing page
   ✔ Which sections do you want? Hero, Pricing, Contact
   ✔ Add SEO starter files? Yes
   ✔ Add contact form placeholder? Yes
   ✔ Add Docker files? No
   ✔ Add GitHub Actions CI? Yes
   ✔ Install dependencies after generation? No

3. Review and customize the generated project

   On disk, you now have a folder matching your answers:

   • Only the sections (pages/components) you selected
   • Starter SEO and .env setup tailored to those sections
   • Optional CI/CD and Docker assets pre-wired — or not, based on your choices

   The difference: minimal dead code. Almost no “delete this before launch” busywork. You jump right into features, design, and logic.

4. Iterate or extend

   The generated project uses modern Next.js conventions. Modify page content, scaffold additional features, or wire up APIs — but the foundation is intent-fit. No need to clean up framework scaffolding before real work starts.

For full details or source, check the package at @supunkalharajayasinghe/project-cli.

What are the benefits of an intent-driven scaffolder over traditional tools?

Intent-driven scaffolders like project-cli short-circuit the classic pain cycle:

• Time saved: Setup time collapses from the 40-minute “clean, rewire, install, rewrite” treadmill to a guided config that writes what you need. No placeholder deletion, less editing wasted.
• Project-fit structure: You choose sections and starter content up front. The folder tree and files reflect your blueprint, not a generic “demo app” that’s meant for deletion.
• Fewer errors and less fatigue: Less manual editing means lower risk of breakage — stray files and unused code don’t pile up in source control.
• Accelerates feature work: Teams get a repo that’s ready for the first feature, not the first cleanup commit. Iteration starts in real context.
• Modern workflows out of the gate: Optional CI/CD, SEO, and common tooling included at scaffold-time if relevant — fitting the full-stack or frontend workflow without post-hoc surgery.

For developers prototyping frequently (internal tools, SaaS products, landing pages), that process advantage compounds over time.

What’s next: the future of scaffolding and boilerplate automation?

Project scaffolding is trending toward higher-level automation and intelligence. Tools like project-cli point to a future where intent, not just stack, drives setup. Contextual project creation — “what am I trying to ship?” — becomes the new baseline, not just “what language am I writing?”

The next wave: more granular blueprints, built-in support for common architectures (multi-tenant SaaS, content sites, AI agent backends), and likely AI-driven customization for even finer project fit.

Project-cli is a real example of this evolution: intent-driven, editable, and closer to production code than old-school demo shells.

Project scaffolders that start from intent enable real speed

A project scaffolder that asks what you’re actually building—rather than what stack you’re using—delivers real time savings, cleaner starter code, and less friction from idea to first deploy. Tools like project-cli make boilerplate setup almost automatic, giving teams a head-start on real features instead of cleanup chores. Try an intent-driven scaffolder the next time you need a project shell that’s fit for purpose, not just framework — and watch the dead time drop out of your workflow.