What a SaaS boilerplate actually is (and is not)

A SaaS boilerplate is a runnable application skeleton sold as source code. You receive files you can clone into your own repo, point at your database, and deploy under your domain. It is not a hosted SaaS you rent. After purchase you hold the bits; the marketplace does not operate your product.

On Twenty, buyers download a frozen archive plus the seller's setup guide. Access lives in your library. You are not waiting on a private GitHub invite that can vanish.

Three labels people mix up

Boilerplate / full starter: auth, billing hooks, app shell, and usually an admin or dashboard path in one package.
Module / kit: one vertical slice (auth only, Stripe webhooks only, admin UI only) meant to merge into an existing app.
UI template: marketing pages and components with little or no durable backend.

Search engines treat “boilerplate” and “starter kit” as near synonyms. Buyers should care about deliverables: env examples, migrations, webhook handlers, and a documented first login - not the marketing noun on the card.

What “production-ready” should mean

Production-ready does not mean “looks finished in a Loom.” It means a careful engineer can take the archive to a staging URL without inventing missing subsystems. At minimum you should see:

Credential storage with a real hash algorithm, not plaintext or reversible encoding.
A payment path that verifies webhook signatures and writes an entitlement or purchase row you can query.
Route protection that fails closed when the session is missing.
Setup copy that lists every required environment variable by name.

Twenty requires setup instructions on every listing. Treat that page as part of the product. If the guide is hand-wavy, the code usually is too.

What you still own after checkout

Your customers, your data, your uptime, your support inbox.
The right to modify the code within the license on the listing.
The responsibility to rotate keys, apply dependency updates, and review security patches.

What a kit will never replace

Positioning and distribution. No archive writes your landing page promise.
Domain logic unique to your category (scheduling rules, inventory quirks, clinical workflows).
Judgment about whether your pricing model needs seats, usage meters, or one-time Checkout.

A useful mental model

Think of a kit as buying the first three months of infrastructure work at a fixed price. You still have to build the product people care about. That trade only works when the kit's stack matches your constraints and the docs survive contact with a clean machine.

Next, use the starter-kit selection guide to turn this definition into a buy/no-buy checklist before you open the marketplace.