Website templates and starting points

What a template actually is

A template, starter, or boilerplate (the three words get used more or less interchangeably) is a pre-wired project you build on top of instead of starting from an empty folder. Someone already made the decisions you would otherwise make on day one: how the files are organized, which build tool runs the project, which UI library is installed, how routing works, sometimes how authentication or a database connects. You clone it, install the dependencies, and you are looking at a running site before you have written a line of your own code.

That is the entire pitch, and it is a real one. Every project needs the same handful of plumbing decisions made before any actual feature work can start: a build tool, a folder layout, a way to run the thing locally. A good template makes those decisions once, correctly, and lets you skip straight to the part that is actually your project. A bad one makes those decisions for a different project than the one you are building, and you spend your first week undoing them instead of shipping.

What a template does not do is understand your project. It cannot know your content, your brand, or which of its bundled features you will actually use. Every template ships opinions baked in, a folder structure, a state management choice, a CSS approach, and those opinions become yours the moment you build on top of them, whether you agreed with them or not. That is the trade you are making, and it is worth naming before you go looking for one: speed now, in exchange for inheriting someone else's decisions later.

Where the good ones come from

The source of a template matters more than how polished its screenshot looks. Two places consistently produce starters worth trusting: the official examples that ship with a framework, and the CLI tool that framework provides for scaffolding a new project. Both are maintained (or at minimum reviewed) by the same team that maintains the framework itself, so they track breaking changes and stay compatible with the version you are actually installing.

• Framework example galleries. Next.js keeps an official examples directory in its own repository, over a hundred working projects covering things like CMS integrations, auth providers, styling setups, and database connections, each one meant to be pulled down directly with the create-next-app CLI.¹²
• Official CLI templates. Astro's own scaffolding tool, create astro, accepts a --template flag that points at any official example or a specific GitHub repository, so you are never limited to the bare default.³
• Curated showcases linked from the docs. Astro also runs a themes and starters showcase, browsable by category and by tooling. It is a legitimate place to start looking, but read the fine print: the listed themes are built by sponsor developers, not the core Astro team, so they still need the checklist in the next section before you commit to one.⁴

Compare that to the other kind of "template" site: paid theme marketplaces and the first repository a search engine hands you, with no way to tell who maintains it, how many other people are actually using it, or whether it was abandoned the week after it was uploaded. Those are not automatically bad, but they carry none of the built-in trust a framework-maintained example carries, so the burden of checking shifts entirely onto you. Treat them the same way you would treat code from a stranger, because that is exactly what they are, regardless of how good the demo screenshot looks.

Official does not mean skip the checklist, either. Even a framework-maintained example is written to demonstrate one feature clearly, not to be a production base for your specific project, and its dependency versions are frozen at whatever they were when someone last touched that example. "Comes from the framework team" earns a template the benefit of the doubt going in. It does not exempt it from the six checks in the next section.

How to judge a template before you adopt it

Before you run the install command, spend ten minutes actually looking at the project. Six things tell you almost everything you need to know, and all six are visible on the repository page before you clone anything.

The license check is the one people skip most often, and it is the one that can bite hardest later. A missing license file is not a neutral default, it usually means you have no legal right to reuse the code at all, commercial or otherwise. If you are not sure what a given license actually permits, Choose a License lays out the common options in plain language before you have to make a call.⁵

The dependency and bloat checks are really the same question asked twice: how much of this did I not ask for, and how much will it cost me to remove. Open the package.json before you install anything. If you do not recognize a third of the packages listed there, you are about to inherit a third of a codebase you did not choose, along with every future security patch and breaking upgrade those packages ship.

When a template saves time, and when it traps you

A template earns its keep when it solves a problem you would otherwise have to solve yourself and get wrong on the first try: wiring up authentication correctly, configuring a deployment pipeline, setting up a testing harness with sane defaults, or getting a CMS integration talking to your framework. That is real, non-obvious plumbing. Skipping a week of trial and error on it is a legitimate win, especially early on or under a real deadline, and it is the same reasoning covered in how to start building a website: match the tool to what the project actually needs this month.

Take a concrete case: you need billing wired into a small app over a weekend. A well-maintained official example that already talks to a payment provider correctly, handles webhooks, and stores subscription state can save you real, meaningful days, because payment integration is exactly the kind of thing that is easy to get subtly wrong and expensive to get wrong in production. That is a template pulling its weight.

A template becomes a trap the moment its opinions stop matching yours and you keep building on it anyway. Its folder structure fights the mental model you actually want. Its state management library is not one you would have picked, but ripping it out means touching half the files in the project. Its dependencies fall behind and every future upgrade of your framework means also upgrading (or replacing) whatever the template author bundled in, on their schedule, not yours. None of that shows up on day one. It shows up three months in, as the site's structure starts actively working against the features you are trying to add.

Starting clean with an official CLI instead

If nothing on the shelf actually fits, and it often will not once your project has any real shape to it, the safer default is not a template at all. It is the plain scaffolding tool your framework ships. create-next-app with no example flag gives you the current default project: current dependency versions, the framework team's own recommended defaults, and an upgrade path that stays in step with the framework itself because it is written by the same people.¹ Astro's create astro works the same way when you leave off the --template flag.³

npx create-next-app@latest my-site

# or, for an Astro project
npm create astro@latest my-site

Starting clean costs you a little more up front. You wire up your own auth, your own CMS connection, your own testing setup, if and when you actually need them. What you get back is a codebase where every dependency is one you chose on purpose, and every file does something you understand, because you or your framework's own team put it there. For a small brochure site that trade is rarely worth it, the official default template is already close to empty. For anything you plan to still be maintaining a year from now, it usually is.

This is also the safer choice when you are still learning the framework itself. A heavier third-party template hides its decisions inside files you have not read yet, so a bug can come from your code, the template's code, or the seam between them, and you cannot always tell which. Starting from the official minimal scaffold means everything in the project is either something you wrote or something the framework team wrote and documented. When something breaks, you have half as many places to look.