What your SaaS needs before its first feature, and why you shouldn't pay for it twice

Should you use a SaaS boilerplate for your MVP? If your product has accounts, teams or payments, usually yes. Every SaaS needs the same plumbing before its first real feature, and paying someone to build it again buys you nothing your users will notice. A boilerplate, also called a starter, is a codebase where that plumbing is already built and tested, so the paid work starts at your feature.

This post is for a founder holding a quote, or an app an AI tool built, who wants to know where the money goes. I'll use Seed, the free starter I build MVPs on, as the example. Not a founder? The developer version shows how Seed is built.

Your product is one idea: a smarter invoice, a booking flow, a dashboard nobody else has. Before a single customer can try it, the app needs a pile of parts that have nothing to do with that idea:

• Sign-in, with password resets and a second factor, so one leaked password doesn't open an account.
• Teams, roles and invitations, so a customer can bring colleagues and decide who may change what.
• Billing, with a trial, a price per member and a plan for the day a card payment fails.
• Emails the app sends: sign-in codes, invitations, billing notices.
• An admin area, where you find a customer and fix their problem without calling a developer.
• Deploy, backups and monitoring, so the app stays up and a bad day doesn't lose anyone's data.

A user sees none of it, and all of it has to work. Nobody signs up because your password reset is nice. They just leave when it's broken.

What this layer costs when a quote builds it from scratch, and what drives the rest of the price, is in how much a SaaS MVP costs. This post is about not paying for it twice.

I learned this with my own time. In 2019 I started a starter of my own, also called Seed, and worked on it until the end of 2022. I wanted the foundation perfect before any feature. Of its 134 commits, 52 went to setup: lint and format rules, CI, dependency updates, renames and Docker. Groups, billing and an app that works offline never shipped. After three and a half years, its database had three tables. Past me built a cathedral for a garden shed.

Now imagine that was your budget. Every week spent on plumbing is a week your feature waits, and it's billed at the same rate as the feature. A quote that starts from a blank folder pays for that plumbing one more time, for you.

Seed is that plumbing, built once, tested in CI and kept in one place. I start an MVP from it, so the budget goes to the feature. In plain words, it ships:

• Sign-in with a second factor. Email and password, passkeys, Google and GitHub, or a one-time code by email. An authenticator app adds a second factor, and people can see and end their sessions.
• Teams, roles and invitations. Seed calls a team a group. Everyone gets one at sign-up and can invite others, and each member has a role, from viewer to owner.
• Billing per member, with a trial. Through Stripe: a free plan with limits, a 14-day trial, a price that follows the number of members, and a grace period after a failed payment.
• Emails the app sends. Sign-in codes and the billing mails to a group's owner, in nine languages.
• An admin area. On its own address. You find a person, see how they sign in and which groups they're in, refund a payment and rerun a failed job, and every action goes to an audit log.
• Live updates. A change one person makes reaches a teammate's screen without a reload.
• An app that works offline. It keeps the latest notes and groups on the device and opens with no network. Notes, the example feature Seed ships with, can be written offline and go out when the connection is back; a clash with someone else's change is shown to settle, never silently overwritten.
• File uploads. Images and PDFs, kept in a file store that runs next to the app. Photos are shrunk and their hidden metadata removed.
• Background jobs. A separate worker does the work nobody should wait for, and a failed job can be rerun from the admin area.
• Deploy, backups and monitoring. Everything runs with Docker Compose on a server you control, with Postgres as the database, guides for the first deploy, backups and restores, and dashboards for metrics and logs.

All of it is tested in CI, and most of it runs in the live demo with made-up people. Click through it before you read on.

• An Android or desktop app. Not built yet; both are open issues.
• Your product's own feature. That's the part worth paying for.

If you'd rather have me build your MVP on it, that's my SaaS MVP offer.

The checklist counts how many of the parts you tick Seed already ships, and names the ones it doesn't. With the plumbing from the top of this post and your own feature ticked, Seed ships six of the seven. The seventh is yours.