ShipFast Docs: Beyond the Framework Stack

If you searched for "ShipFast docs," you were probably trying to answer one question: can a boilerplate actually get me from idea to revenue faster? ShipFast built its reputation on that promise for Next.js — "launch in days, not weeks." It's a good product. But the promise hides an assumption worth challenging: that the framework and UI scaffolding are what stand between you and a shipped product.

They aren't. The stack is the easy part. The plumbing between the pieces is the project. This article walks through what a SaaS starter actually needs to do — and where an AI-native approach changes the math.

The Real Cost of SaaS Setup: Why Stack Choice Isn't Your Bottleneck

The myth: "pick the right framework and you're done"

Ask ten founders how to ship fast and you get ten stack arguments — Next vs Nuxt, Postgres vs a hosted DB, Stripe vs Paddle. Pick whatever you already know and the debate is over in an afternoon. Framework choice is a days-long decision at most.

What actually kills shipping velocity

Authentication with real session handling. Billing webhooks that survive retries. Database schemas with access control. Email that doesn't land in spam. Multi-currency display. Refund flows. This is the plumbing that eats your launch, and it doesn't show up in a demo. It shows up three weeks in, when a webhook fires twice and you've charged someone twice.

Why Next.js boilerplates miss the actual problem

Most boilerplates, ShipFast included, give you a landing page, auth scaffolding, and UI components. That's genuinely useful. But the hard integration — making Stripe the source of truth, wiring idempotent webhooks, enforcing row-level security — is often left as an exercise for the reader. You still write the part that's actually hard.

Solving for the real constraint

BoiledPlate takes a different angle: your coding agent doesn't just write code, it provisions the services. Stripe products and webhooks, a Supabase database with RLS, Google sign-in — configured in one session, not copied from a docs page you follow by hand.

From Idea to Production: What "5 Minutes" Actually Means

The honest timeline

Five minutes gets you a running local app. It does not get you correct Stripe webhook handling — that historically takes weeks to get right. Anyone promising both in the same sentence is selling you the clone step and hiding the wiring step.

What you get immediately

A Nuxt codebase, a Supabase schema with policies, Google sign-in, real Stripe products and price IDs, a prerendered Markdown blog, and i18n across four languages. That's the plumbing pre-solved.

What still requires your thought

Your business logic. Your domain data model. Your pricing strategy. Your actual features. A boilerplate can't ship those, and it shouldn't pretend to. What it can do is stop you spending 80% of your effort on integration work — the real indie-builder killer.

Billing Done Right: Webhook Architecture That Survives Reality

Missed or mishandled webhooks mean lost refunds, corrupted subscription state, and angry customers. This is non-negotiable, and it's where most DIY setups quietly rot.

Idempotent webhook design

Stripe will send the same event more than once. Your handler must process a replayed event ten times and produce the same result as processing it once. If replaying invoice.paid can charge or provision twice, your billing is broken by design.

Making the webhook the source of truth

The single most important billing decision: your checkout success page should not touch your billing state. The success page is a redirect the user might never see. The webhook is the fact. BoiledPlate's implementation verifies the Stripe signature, applies deterministic state transitions, and handles failure explicitly — some failures throw and retry, some must never throw. Knowing which is which is the whole game.

For a full walkthrough of the ordering — plans in config, checkout, webhook, RLS-gated access, customer portal — see how to set up Stripe subscriptions in a Nuxt + Supabase app.

Database Security Without the Headaches: Row-Level Security

What RLS actually does

Row-level security enforces access at query time, in the database, not in your application code. Even if an API route forgets a WHERE user_id = check, Postgres refuses to return rows the caller shouldn't see.

Why it matters for multi-tenant SaaS

Application-level checks fail the moment someone adds an endpoint and forgets the guard. RLS makes data leakage a database-level impossibility, not a code-review hope. BoiledPlate ships policies for users, subscriptions, and audit logs, with JWT claims from Supabase auth feeding the policies directly.

The gotchas nobody mentions

RLS interacts with JWT custom claims, foreign-key constraints, and query performance in ways that surprise people. Correct policies can still block valid queries or slow them down under load. These aren't reasons to skip RLS — they're reasons to start from patterns that have already hit those walls. The Supabase docs on RLS are the canonical reference worth bookmarking.

Deterministic Patches: How AI Agents Customize Your Codebase

Templating scatters {{variables}} across your entire tree and leaves you to clean up. BoiledPlate uses deterministic patches instead: the agent interviews you once — pricing tiers, email provider, theme, domain, languages — then applies surgical, idempotent edits to known code.

AGENTS.md: the contract for consistent output

The reason patches stay coherent is a shipped AGENTS.md contract that documents one correct way to do data access and secrets. Writing conventions for the agent, not the next hire is what keeps AI output from drifting into three different patterns for the same task. Adding a subscription tier becomes one flow: interview → migration → Stripe product → webhook handler → email template, all consistent.

Currency handling breaks late — tax rates, rounding, Stripe's integer-cents precision. And regulation is worse. EU law grants a 14-day withdrawal right (Widerrufsrecht) that affects how you handle digital-goods subscriptions. Encoding that correctly means wiring a withdrawal waiver into the checkout button via Stripe's consent_collection — not a hardcoded checkbox you bolt on later.

The rule: don't hardcode policy. Make consent flows, retention, and pricing display configurable from day one, tied to user locale via the built-in i18n.

SEO and Metadata Without the Crashes

The subtle bugs that kill SEO aren't glamorous. A JSON-LD hydration mismatch can make a page return 200 from curl and 500 in the browser. A misconfigured canonical can tell Google your site lives at localhost:3000. BoiledPlate ships a prerendered Markdown blog, JSON-LD product and organization schema, and og:url canonicals that point at the right domain — because these were debugged in production, not assumed.

Instant GitHub Delivery: The Product Isn't Code, It's Provisioned Services

Sending a zip file is a 2010 delivery model. You don't just need the repo — you need Stripe products created, a Supabase database initialized with policies, and Google OAuth configured. BoiledPlate Pro delivers via webhook: you pay, GitHub access is granted automatically, and you get a repo ready to be provisioned by your agent. Instant, auditable, and repeatable if you need a fresh copy.

Lite vs. Pro: Fork the Template or Buy Instant Setup

BoiledPlate Lite is free and MIT-licensed. Clone it from GitHub, wire the services yourself, keep full control — everything a paid product needs, minus the automation.

BoiledPlate Pro is €159 one-time, with lifetime updates and instant GitHub delivery. You get the agent-driven interview, deterministic patches, provisioned services, and update paths that don't devolve into merge hell.

The calculation is simple: if the paid tier saves you two weeks of plumbing, €159 is not the expensive part of your launch. Your time is.

Comparing to ShipFast and Other Boilerplates: Honest Trade-Offs

ShipFast is a Next.js boilerplate with a large community and a proven track record. If your whole world is React and Next, that ecosystem depth is real value. Nuxt vs Next is a framework preference, not a capability gap.

The honest trade-offs cut both ways:

Open-source forks are free but often unmaintained — you're not saving time if you're debugging someone's two-year-old code.
Building from scratch gives maximum flexibility and zero velocity; most indie builders shouldn't.
A Nuxt-based starter means a smaller community than Next and fewer niche libraries — but a stack where every piece's demands are already handled.

The real difference isn't framework. It's that most boilerplates ship the stack and leave the plumbing to you, while that was never the hard part.

Getting Started: A Practical Walkthrough

Decide Lite or Pro. Fork the free MIT version, or pay €159 for the provisioned setup.
Interview. Your agent asks about pricing, languages, branding, and email provider.
Infrastructure lives. Stripe products exist, the Supabase database is initialized with RLS, Google sign-in works.
Customize and ship. Add your business logic, deploy, collect customers.
Iterate with agent help. The agent reads AGENTS.md, applies patches, you review and merge.

The stack was always the easy decision. The plumbing was the project. That's the part worth automating — and the reason to look past the framework debate entirely. Read more on the BoiledPlate blog.