Chapter 1 — Free
Why most starters fail you.
You've cloned three boilerplates. You're still not shipping. It's not because you're slow. It's because the starters you used solved the wrong problem.
The graveyard.
Open your projects folder.
You will find half-finished SaaS. You will find a perfectly working sign-in form. You will find a Stripe button that takes a fake card in test mode and never made it past that. You will find a Vercel project with a custom domain you never told anyone about. You will find three different boilerplates you cloned in the last year, each abandoned at a slightly different point.
The shared trait of these projects is not that they were bad ideas. The shared trait is that they all died at the same point: the moment between "the starter is set up" and "I'm building the product."
That gap is where most starters fail you.
Most starters give you the easy parts.
The standard SaaS starter gives you, at most:
- A sign-up form
- A login form
- A "hello, $user" page
- A Stripe checkout button that takes a card
- A theme toggle, if it's feeling generous
That's an afternoon of work. The starter saved you an afternoon.
An afternoon is not what you needed. You needed a month.
The missing month.
Between "I have a working sign-in form" and "I have a real product someone is paying for," here is the work that nobody wrote a starter for:
- Organizations and per-org roles, with invite flows that don't leak data.
- Multi-tenant query patterns that don't accidentally show one customer's rows to another.
- Real-time data sync that doesn't flicker, doesn't miss writes, and doesn't fall over when the user closes their laptop and opens it three days later.
- Stripe webhooks with idempotency, retries, and a way to recover from the time the webhook fired and the database wasn't reachable.
- A customer-facing billing portal where people can see their invoices, change cards, and cancel without emailing you.
- Subscriptions scoped correctly — to the user, the org, or the project, depending on the product.
- A brand system that survives past the first three CSS variables.
- Transactional email that actually delivers, with templates that don't look like they came out of 2009.
- Image and file uploads with sane size limits and a CDN in front.
- Error tracking that tells you when something broke for one customer at 3am.
- Logs you can search, costs you can predict, and a way to know when to scale.
- Migrations you can run without taking the site down.
This list is the missing month. Nobody clones a starter and gets these. They build them by hand, badly, twice, while their motivation drains.
This is where your weekend project dies. Not because you ran out of ideas. Because you ran out of patience for plumbing.
Zero Start is the answer to the missing month.
Zero Start is the philosophy that anchors Brhyt™ Rift. It says: the foundation should be zero work to start, not an afternoon of work. The plumbing should be invisible. Day one should be feature work.
In practice, Zero Start means four things.
One
Auth, database, payments, organizations, brand system, analytics, transactional email — wired, typed, and tested before you clone.
Not stubs. Not "TODO: add Stripe here." Real wiring, with the gotchas already handled. The webhooks are idempotent. The orgs have roles. The brand system has tokens. You can launch on day one if you want to. You probably won't — your idea isn't ready — but the option is there.
Two
Bun runs the dev server. Convex runs the database and the functions. Vercel or Cloudflare runs the edge. You don't operate any of it.
This is not a small thing. The DevOps month is the second-most common reason people stop building. (The first is the missing month above.) Zero Start declines to participate.
Three
Local dev is free. The first deploy is free. The first hundred people you sell to should cost you cents, not hundreds.
The stack we picked has free tiers that fit a real product, not a toy. You will not be paying $400/month before you have a customer. If you ever do start paying, it will be because you have customers — which is the only good reason to pay for infrastructure.
Four
The same code that runs your prototype runs your paid product. You will not be told, eighteen months in, "this won't scale, rewrite it."
This is the rule that excludes the most starters from the conversation. A lot of starters are written for "just to learn" or "just to prototype." They use SQLite locally. They use a single shared file as the database. They have one user account hardcoded. Their auth is a cookie they set themselves. None of that survives contact with a paying customer.
Rift is built so the path from your laptop to a hundred customers is the same path. No fork in the road. No rewrite at month six.
The cost of failing the foundation.
You can ignore Zero Start. People do, every day. Here is what happens when they do.
They spend their first month building auth, instead of building product. They spend their second month wiring Stripe webhooks. They spend their third month figuring out organizations and roles, which they didn't plan for, and which cost them more time than the previous two combined because half their codebase has to change.
By month four they are tired. The idea is not as exciting as it was. They tell themselves they need to step back, regroup, maybe think about whether this is the right project. They never come back.
The opportunity cost of failing the foundation is not the foundation. The opportunity cost is the product you didn't ship because you were too busy wiring Stripe.
That's the trade we're trying to make impossible.
Where the rest of this Manual goes.
Part II — Building with Rift.
Five chapters on the actual work: data layer, auth, billing, the Studio surface, and brand systems. Concrete, opinionated, code-first. Each chapter ends with the part of Rift that does this for you, and the part that's still on you.
Part III — Edge cases we've lived.
Five chapters on the things that bite at month four: migrations under load, webhooks nobody tested, real-time meeting stale data, multi-tenant sneak attacks, and scaling the boring parts. Every one of these is a story we've lived through, with the fix.
Part IV — Working as an entrepreneur.
Four chapters on what to do with all the time you saved. Money, focus, charging from day one, the community-or-distraction question. These chapters don't need Rift to be useful.
The honest disclaimer.
This Manual is opinionated. It picks Convex over Supabase, Clerk over Auth.js, Stripe over Lemonsqueezy, Bun over npm, Vercel and Cloudflare over your own boxes. We are not surveying options. We picked, and we're telling you what we picked and why.
If you need to use Postgres with Drizzle, with self-hosted auth, on your own Kubernetes cluster, the technical chapters of this Manual will be wrong for you. The mindset chapters in Part IV will not.
Either way: stop cloning the starter that gives you a sign-up form. You don't need a sign-up form. You need the missing month done.
Chapter 2 — "The minimum viable backend" — covers what you actually need before you write your first feature. It ships with the rest of the Manual.