What is a starter kit, and when do you actually need one?

What is a starter kit, and when do you actually need one?

A starter kit is a complete, working application that already contains the parts every product needs and no product is about: sign-in, payments, transactional email, background jobs, permissions, and a deployment path. You start from a running app instead of an empty directory. You need one when the distance between "empty directory" and "first screen a customer could actually use" is weeks of work you have done before and learned nothing from.

That is the whole idea. The rest of this is about where the line sits.

The parts that are the same in every product

Sit down to build any product that has customers, and you will write roughly the same first two thousand lines every time:

• Sign-in. Sessions, email verification, password reset or a passwordless flow, social sign-in, and the surprisingly fiddly question of what happens when someone signs in with Google using an email address that already has an account.
• Payments. A checkout, a webhook listener, a subscription record, and the logic that decides whether this account is currently allowed to use the paid feature.
• Email. A sending provider, the domain records that keep your mail out of spam, HTML and plain text versions of every message, and delivery that happens outside the web request.
• Separation between customers. Every query has to be limited to the account that is asking, and every one of them has to be right.
• The safety layer. Rate limiting, a content security policy, data export and deletion, and a way to check that all of it still works.
• Getting it online. A container, a server, TLS, a database, and a command that deploys.

None of that is your product. A customer has never once chosen a product because its session handling was elegant. But all of it has to exist and work correctly before the first customer can do the one thing they came for.

So what is your product, then?

The part nobody else can write. The specific thing your customers cannot get anywhere else.

A good test: if a competitor's engineer read your code, which parts would make them nod because they wrote the same thing last month, and which parts would make them stop and read carefully? The first group is plumbing. The second group is the product. A starter kit is a way of buying the first group so you can spend your attention on the second.

When you should not use one

Being honest about this matters more than the pitch, so here are the cases where starting from scratch is genuinely better.

Your product is the plumbing. If you are building an authentication provider, a payments processor, or a background job system, then the thing a kit hands you pre-built is the thing you are supposed to be building. Start from scratch.

You are learning. If the point is to understand how sessions or webhooks work, a kit removes exactly the work that would have taught you. Build it badly first. That is not wasted time.

The kit is written in something your team cannot maintain. This is the one that actually bites people. A kit is not a black box you install; it is your codebase from day one, and you own every line of it forever. If nobody on your team can read it, you have not saved six weeks, you have bought a permanent dependency on a language you do not speak. Check what a kit is written in before you buy it, not after.

Your requirements are genuinely unusual. Regulated industries, unusual tenancy models, and on-premise deployments all have constraints that a general kit will fight rather than help.

What separates a good kit from a bad one

The market is full of these, and the differences are not cosmetic.

It runs the moment you clone it

This is the single most useful property. A fresh clone should start, let you sign in, and let you complete a purchase before you have registered a single account with a payment provider or an email service.

The way to achieve that is a seam at every external boundary: the real client when credentials are present, a deterministic local stand-in when they are not. This is not a demo mode. It is the same code path with a different implementation behind it, which means the flow you exercise on your laptop is the flow that runs in production.

If a kit requires four vendor accounts before it will boot, you will spend your first afternoon on signup forms rather than on your product.

The tests are real

A kit's test suite is the only evidence you have that the plumbing works. Look specifically for tests of the things that are painful to debug in production: a customer cannot read another customer's data, an unpaid account cannot reach a paid feature, a webhook with a forged signature is rejected.

If a kit ships without tests, then everything it saved you in writing it will hand back the first time you need to change something and cannot tell whether you broke anything.

It is conventional

Clever code is a liability in a codebase you did not write. Heavy abstraction, custom domain-specific languages, and metaprogramming all make a kit harder to read, harder to modify, and much harder for a coding agent to extend correctly. Boring, obvious code is the feature.

It tells you how to extend it

The kits that work best come with a written map: here is the one right way to add a feature, here is the file to copy, here is what must never be broken. That document is worth as much as the code, because it turns "a codebase I inherited" into "a codebase with a grain I can follow".

The coding agent changes the arithmetic

This is the genuinely new part.

When you hand a project to a coding agent, its useful output is bounded by what it can hold in context and by how long it can work before it needs your review. Point it at an empty directory and ask for an app with sign-in, payments, and email, and it will happily build all three. It will spend most of its run doing it. What comes back will be plausible, mostly working, and subtly wrong in the places that are hardest to check by reading: the webhook that does not verify signatures, the query that forgot to filter by account.

Point the same agent at a codebase where all of that already exists and is tested, and the whole run goes into your actual feature. Better still, it can check its own work, because there is a test suite to run.

The kit is not there to save the agent from typing. It is there to keep the agent's attention on the part that is yours, and to give it a way to know when it is done. That is the argument in what your coding agent should never build from scratch.

The honest summary

A starter kit is worth it when three things are true: the plumbing it replaces is genuinely universal, you can read the language it is written in, and you would otherwise be rebuilding something you have already built before.

It is not worth it when you are learning, when the plumbing is the product, or when you cannot maintain what you are handed.

Everything else is detail. If you want the concrete version of this, here is exactly what One Shot gives you on day one.