DEV Community: Benjamin Touchard

21 questions to ask a SaaS boilerplate before you pay for it

Benjamin Touchard — Thu, 15 Oct 2026 07:09:25 +0000

Feature lists are marketing. These are the twenty-one questions that separate a
boilerplate you can build a business on from a demo with a login screen. They
work on any kit — take them to whichever vendor you are evaluating, including
this one.

Each question is followed by GoVueKit's answer, so the comparison is concrete.

Authentication

1. How are passwords hashed, with what parameters?
Bcrypt with default cost is acceptable; anything home-made is not. GoVueKit:
argon2id, 64 MiB memory, 3 iterations, per-password salt.

2. Do signup, login and password reset reveal whether an account exists?
Different messages or timings are account enumeration. GoVueKit: neutral
responses on all three, and a test that asserts it.

3. Where do sessions live, and what happens on password change?
Stateless JWTs that cannot be revoked are a liability for a product with
billing. GoVueKit: server-side sessions in the database; a password change
terminates every other session.

4. Is there two-factor authentication, and does it cover every sign-in
path? 2FA that guards the password form but not the magic link is theatre.
GoVueKit: TOTP with ten single-use recovery codes, enforced on password,
magic link and OAuth sign-in.

5. What happens when an OAuth email matches an existing account?
Silent merging is an account-takeover vector. GoVueKit: no implicit merge; the
user must sign in and link the provider explicitly.

Multi-tenancy

6. Where is the tenant boundary enforced?
"In the service layer" means "wherever someone remembered". GoVueKit: one
middleware resolves the organization against the caller's memberships, and
every business query filters on organization_id.

7. What does a request for another tenant's resource return?
403 confirms the resource exists. GoVueKit: 404, indistinguishable from a
resource that never existed.

8. Is cross-tenant isolation tested end to end?
Ask to see the test. GoVueKit: a Playwright journey creates two
organizations and asserts the second cannot read the first — plus integration
tests per endpoint.

9. Can roles be bypassed from the frontend?
Every kit hides buttons; the question is what the server does. GoVueKit: RBAC
is server-side middleware, frontend checks are explicitly cosmetic.

10. What protects the last owner of an organization?
Products lose ownership when the last owner leaves. GoVueKit: the last owner
cannot be demoted, removed, or leave without transferring ownership.

Billing

11. Are webhooks idempotent, and how?
"We check if we already processed it" is not enough if the check and the write
are in different transactions. GoVueKit: the event id is inserted with a
primary key and the business write commits in the same transaction —
the full pattern.

12. Is payload data trusted?
A valid signature proves the sender, not that the state is current. GoVueKit:
every object is re-fetched from the provider API by id; nothing beyond the id
is trusted.

13. Who owns the subscription — the user or the organization?
Per-user billing on a team product is a migration you will do later, painfully.
GoVueKit: the organization owns it, and solo mode makes it per-user when that
is what you want.

14. What happens when money leaves the account, and what would a second
provider cost? Most kits handle payment and stop there; refunds and
chargebacks arrive anyway. GoVueKit: Stripe only — charge.refunded stamps
the purchase rather than deleting it (the row reconciles with Stripe), and
charge.dispute.created is logged at Error level so it reaches your error
reporter. Stripe sits behind a five-method billing.Provider interface, so
another provider is a package to write, not a rewrite — but it is an
integration you would write, not a switch you flip.

15. Where do prices live?
An admin UI that can disagree with what the payment provider charges is a bug
generator. GoVueKit: plans are configuration, served to both the pricing page
and the billing screen; the amount charged always comes from the provider.

Operations

16. What must be running in production besides the app and the database?
Every additional service is an on-call surface. GoVueKit: nothing. The job
queue is a table, sessions are rows, files can be on disk.

17. What happens to queued emails when you redeploy?
In-memory queues lose them. GoVueKit: jobs are durable rows, claimed and
retried after a restart.

18. How are errors reported, and can you swap the reporter?
GoVueKit: every Error-level log record reaches a pluggable reporter;
SENTRY_DSN enables the bundled one, and the interface is one method.

19. What does the deployment story look like, in commands?
If the answer is a platform button, ask what self-hosting takes. GoVueKit:
one binary, or docker compose -f docker-compose.prod.yml up -d --build with
Traefik and Let's Encrypt included.

The purchase itself

20. What exactly does the licence allow, and forbid?
The clauses that matter: unlimited end products, client work, whether updates
are perpetual, and the redistribution restriction. GoVueKit: perpetual,
unlimited products including client work, lifetime updates; you may not
republish the source as a competing kit.

21. How are updates delivered, and how do you merge them?
A zip file is a fork you maintain alone. GoVueKit: a private repository you
are invited to, with atomic conventional commits and a changelog — you pull,
read the diff, merge.

The bonus question

Can you read the code before buying?
Most kits publish something: a demo repository, documentation, code excerpts,
a video walkthrough. A vendor that shows nothing is asking you to buy a
promise. GoVueKit publishes excerpts on the landing page and its
guides in the open at docs.govuekit.dev — including the ten-minute tour that
follows one request through every layer, from the chi route to the SQL and
back. The repository adds DECISIONS.md, which is the file to read second:
every non-obvious call, with its reasoning, including the features that were
built and then cut. And the site you are reading is served by the product
itself.

The questions worth asking about what is missing

A serious kit says no to things. Ask what a vendor deliberately left out and
why; "everything is included" is the answer of a product nobody has had to
maintain. GoVueKit: no code generator, no example business module, no second
payment provider, no passkeys, no feature flags — several of those existed and
were removed, and DECISIONS.md explains each cut. If your evaluation is
scored on feature count, that is a column GoVueKit loses on purpose.

How to use this list

Do not send all twenty-one questions to a vendor — you will get a marketing
reply. Pick the five that map to your risk: if you sell to teams, ask 6, 7, 8;
if you charge money, ask 11, 12, 14; if you have no ops team, ask 16, 17, 19.

And ask for the test, not the answer. "Where is the test that proves that?" is
the single most useful sentence in this entire process.

Want the comparison by architecture rather than by feature? Read
choosing a SaaS boilerplate in 2026.

Originally published on govuekit.dev. GoVueKit is a complete Go + Vue 3 SaaS codebase you buy once and own; the whole stack runs on your machine with one docker compose up: https://govuekit.dev/labs

Self-hosted SaaS boilerplate: what \"self-hosted\" has to mean, and a checklist

Benjamin Touchard — Tue, 13 Oct 2026 07:11:19 +0000

"Self-hosted" has become a checkbox on boilerplate landing pages, and the
checkbox is usually true in the narrowest sense: yes, the Node process can
run on your VPS. Then you read the .env.example and find the auth
provider's API key, the managed database URL, the queue service token, the
email API key and the file-storage bucket. The process is yours; the
product is theirs. This article proposes a definition strict enough to be
useful, and turns it into questions you can ask any kit — including ours.

A definition

A SaaS foundation is self-hosted when the product keeps working, for all
its users, with nothing but the servers you operate and the one payment
processor you cannot avoid. Everything else is optional or replaceable
with something you run:

Sign-in works with your database alone. External identity providers are a feature you add, not a dependency you start with.
Email goes out through any SMTP server, including your own; a hosted email API is a configuration, not a requirement.
Background jobs run inside the application, backed by your database, and survive a restart.
Files go to a local directory or to any S3-compatible service you choose, including one you run.
Analytics, error reporting and monitoring are opt-in and can point at self-hosted tools.
The payment processor is the exception, and its failure mode is bounded: with no key configured, the application runs, and billing is simply off.

By that definition most "self-hostable" kits are not. That is not an
accusation; it is a consequence of building on a BaaS. It is worth knowing
before you sign a data-processing agreement that lists sub-processors you
did not choose.

Why it matters, concretely

The bill. A rented stack is five invoices with five floors. A binary on
a server is the server. We priced it in
The rented stack.

The questionnaire. The first enterprise customer sends a security
questionnaire. "Where is the data, who are the sub-processors, how do you
delete a user?" With a self-hosted foundation the answers are one country,
three names and a button. See Keeping a SaaS in the EU
for what self-hosting settles and what it does not.

The exit. When a vendor changes pricing or terms, a self-hosted product
moves by copying a binary and a database dump. A product built on managed
auth moves by re-implementing auth.

The checklist

Ask these of any kit. The honest answers are usually in the .env.example.

Delete every third-party key from the configuration. Does it boot, can a user sign up, sign in, reset a password? If sign-in needs an external provider to exist, it is not self-hosted.
Which database, and can I run it myself? PostgreSQL on your server counts. A vendor's "serverless Postgres" with a connection string does not, unless the kit also runs against a plain instance.
Where do background jobs run? In-process with a database table: yes. A hosted queue with a token: no.
How does email leave? SMTP to any host: yes. Only through one API vendor: no.
Where do uploads go? Local disk or any S3-compatible endpoint: yes. One vendor's bucket API: no.
What happens with no payment key? The app should run and hide billing. A crash, or a checkout button that errors, means the unconfigured path was never tested.
What runs in production? One process you can list is better than a platform-specific build output. Count the runtimes: Node, PHP, Redis, workers.
Can I read all of it? Lines of code you will own, not features advertised. If the answer is "it's a monorepo, you don't need to read the packages", you are renting with extra steps.
Is the licence perpetual, and does it cover client work?
Does the repository come with a way to run everything locally, including the external pieces (identity provider, S3, mail, payment sandbox)? If the vendor's own demo needs their cloud, so will yours.

How GoVueKit answers

Boots and signs users up with a database file and nothing else: argon2id passwords, verification, reset, magic links, TOTP, session revocation. Google, GitHub, Microsoft and any OIDC provider are switched on by adding keys; the unconfigured path is tested in CI.
PostgreSQL and SQLite, same migrations, same generated queries, both engines in the test matrix. DB_DRIVER decides.
Jobs are rows in your database, run in-process, retried, surviving redeploys.
SMTP by default; Resend is an option behind the same Mailer interface.
STORAGE=disk or STORAGE=s3 against any endpoint (the labs uses MinIO).
No Stripe key means billing is off and the app is otherwise complete; the tests cover that configuration because it is the one most deployments run.
One static binary, ~27 MB, the Vue app embedded. Traefik for TLS if you want automatic certificates. Nothing else.
About 11 000 lines of Go, 19 packages, one migration file, and a DECISIONS.md that explains the non-obvious choices — public before you buy, at github.com/kOlapsis/govuekit.
€199 once, perpetual, lifetime updates of the major version, unlimited end products including client work.
One compose file, no account:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d   # app + PostgreSQL + Dex (OIDC) + MinIO (S3) + stripe-mock + Mailpit

The tenth question is the one to start with. A kit that can boot its whole
world on your laptop can boot it on your server; one that cannot has
already told you where it really lives.

Embedding a Vue 3 app in a Go binary with go:embed — and keeping SEO without SSR

Benjamin Touchard — Thu, 08 Oct 2026 07:07:04 +0000

"One binary" is easy to say and easy to get half right. Serving dist/ from
Go takes six lines; serving it so that deep links work, real 404s stay 404s,
crawlers see content, canonicals point at the right origin and the build
stays deployment-agnostic takes a few decisions. This is how GoVueKit does
it, with the code, and the reasons.

1. Embed the build

// web/embed.go
package web

import "embed"

//go:embed all:dist
var Dist embed.FS

Two details matter. all: includes dotfiles, so a .gitkeep keeps dist/
present in a fresh clone and the embed directive never fails to match. And
the frontend is built before go build, never at runtime: the
Makefile runs npm ci && vite build first, the Dockerfile has a Node stage
whose only output is web/dist, and the final image is FROM scratch with
the binary in it. Node exists at build time and nowhere else.

2. Serve the SPA without lying about 404s

The naïve handler serves index.html for every unknown path. That is also
how you end up with /blog/does-not-exist returning a 200 with an empty
shell, which search engines index as duplicate content. GoVueKit mounts
routes in this order:

/api/... — JSON handlers; an unknown API path answers a JSON 404.
Server-rendered pages that must be real files to crawlers: /blog, /blog/{slug}, /blog/feed.xml, /sitemap.xml, /robots.txt. An unknown slug renders the blog's own 404 page with status 404.
Everything else — the SPA handler: a static asset if the path exists in dist/, the prerendered HTML if the route was captured (below), the shell otherwise.

The shell is the fallback for application routes (/dashboard,
/orgs/…), where the router owns the URL and a guest gets bounced to
/login. Nothing indexable relies on it.

3. Prerender the public pages at build time

SSR would solve SEO and cost a Node process in production, which defeats
the binary. Prerendering solves it at build time instead: the public pages
are static enough (landing, pricing, legal, contact) that the HTML a crawler
needs is the HTML an anonymous first visit renders.

web/scripts/prerender.mjs runs after vite build:

it serves dist/ through vite preview and drives each route from prerender.routes.json (English and French twins) with the Playwright Chromium;
every request to another origin is aborted — an analytics script must not record a build as a visit, and the build must not depend on a third-party host being up;
/api/** is stubbed (/api/auth/me → 401, anything else → 404), so the captured page is exactly what an anonymous visitor sees;
it fails loudly: a route that rendered under 500 characters, or that has no canonical tag, breaks the build instead of embedding an empty shell;
the captured HTML lands in dist/prerendered/<route>/index.html.

The Go server loads that directory at startup into a map from route to
bytes. A route present in the map is served before the shell; a build
without the directory gets an empty map and behaves as a plain SPA. The
whole feature is one build flag (PRERENDER=1 in the Docker build).

4. The origin problem, and the placeholder

Canonicals and hreflang links are absolute URLs. At build time the app
runs on http://localhost:4173; in production it runs on whatever
BASE_URL the operator configured. Baking the production origin into the
build would make the image deployment-specific, which is exactly what a
signed, published image must not be.

So the prerenderer rewrites its own origin to a placeholder,
__BASE_URL__, and the server substitutes it once at startup while
loading the pages:

pages[route] = bytes.ReplaceAll(b, []byte("__BASE_URL__"), []byte(baseURL))

The same image serves https://govuekit.dev and https://demo.example.com
with correct canonicals on both. The e2e suite asserts that no
__BASE_URL__ survives in a served page.

5. Hydration, hreflang and the sitemap

The Vue app mounts on top of the prerendered DOM, so a browser gets content
first and interactivity a moment later; the head tags the app manages
(title, description, canonical, the hreflang pair for /x and /fr/x,
x-default on English) are written by a small useSeoHead composable and
captured with the page. The sitemap is derived from the set of prerendered
routes plus the blog posts with their lastmod, so a route added to
prerender.routes.json is indexed without touching Go.

6. What this does not do

It does not render per-user or per-request content for crawlers: the
dashboard is not prerendered, and should not be. It does not replace a
content-heavy marketing site with thousands of pages; for that, a static
site generator next to the binary is the right tool. And it does not
prerender the blog, because the blog is already server-rendered by Go from
embedded markdown — the other half of the "content in the binary" story.

Try it

GoVueKit's own sales site is built this way: curl -sI https://govuekit.dev/fr
shows a real HTML document with a canonical and two hreflang links before
any JavaScript runs. The mechanism, the knobs and the reasons live in
docs/SEO.md of the kit, and the whole product runs locally from one file:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d

Idempotent billing webhooks: exactly-once fulfilment with Stripe

Benjamin Touchard — Tue, 06 Oct 2026 07:05:40 +0000

Payment providers deliver webhooks at least once. That is not a bug in their
systems, it is the only guarantee a network can offer: if your endpoint is
slow, times out, or answers 500 after committing, the event comes back. Twice.
Sometimes days later.

Everything that follows exists to make the second delivery boring.

The three ways this goes wrong

Double fulfilment. The event arrives twice, you grant credits twice. The
customer notices only when it goes the other way.

Lost fulfilment. You verify the signature, start work, and time out. The
provider retries, your handler crashes on a half-written state, and the
subscription never activates. The customer paid; your database disagrees.

Trusting the payload. The webhook body says the subscription is active.
Between the event being generated and your handler running, the payment was
disputed and the subscription cancelled. A valid signature proves who sent the
message, not that the world still looks like that.

The pattern

Four rules, in order.

1. Read the raw body and verify the signature

The signature is computed over the exact bytes sent. Any middleware that
parses and re-serialises JSON before you check it will break verification, so
the webhook route must read the body before anything touches it.

Stripe's tolerance window (300 seconds by default in GoVueKit) also matters:
it is what stops an attacker from replaying a captured, still-valid request
next month.

2. Answer fast, work after

Providers treat a slow endpoint as a failed one. The handler acknowledges as
soon as the event is durably recorded, and the actual work happens in the
background worker — which, because the queue is a database table, survives the
redeploy that happens three seconds later.

3. Deduplicate with a primary key, in the same transaction as the write

This is the part that people get almost right. The failure mode of "check if
processed, then process, then mark processed" is a crash between steps two and
three — or two deliveries racing.

The fix is not a lock. It is a single transaction:

BEGIN
  INSERT INTO processed_events (id, ...) VALUES ($1, ...)   -- primary key
  -- unique violation → this event is already done, ROLLBACK and answer 200
  UPDATE subscriptions SET ... WHERE organization_id = $2
COMMIT

Either both happen or neither does. A duplicate delivery hits the primary key
and becomes a no-op. A crash mid-way rolls back and the provider's retry
replays it cleanly. There is no window in which the event is marked done but
the business write is missing.

4. Re-fetch the object by id; never trust the payload

The handler takes exactly one thing from the payload: the object id. Then it
asks the provider's API what that object looks like now, and writes that.

event → id → provider.Resolve(ctx, ev) → authoritative state → write

This costs one API call per event and removes a whole class of race
conditions. It also means a replayed six-day-old event cannot resurrect a
cancelled subscription: the re-fetch returns the current state.

It has a second benefit that only shows up in production: because nothing is
read from the payload beyond the id, the API release train stamped on the
envelope stops mattering. Verification checks the signature and the timestamp,
deliberately not the version, and every re-fetch sends the SDK's own
Stripe-Version — so a dashboard that upgrades under you does not turn every
delivery into a 400.

The same rule forbids fetching URLs found in a payload — a webhook body is
attacker-influenced input, and following its links is how SSRF starts. Any
outbound call in GoVueKit that is not to a hardcoded host goes through the
hardened safehttp client, which validates the IP at dial time and refuses
private ranges.

One provider, behind a seam

GoVueKit sells through Stripe. A store has one merchant of record, so a second
provider is not a feature the kit switches between — but it is a package
away rather than a rewrite, because the billing page, the admin metrics and
the subscription row talk to an interface, not to Stripe:

type Provider interface {
    Name() string
    Checkout(ctx context.Context, org sqlcgen.Organization, actorEmail string, plan Plan) (string, error)
    Portal(ctx context.Context, org sqlcgen.Organization, actorEmail string) (string, error)
    VerifyWebhook(body []byte, header http.Header) (Event, error)
    Resolve(ctx context.Context, ev Event) (Change, error)
}

Five methods. If you need Paddle, Lemon Squeezy or a local PSP, that is what
you implement, and nothing above the seam changes. Be honest with yourself
about the size of that job: it is a real integration, not a config switch, and
the kit does not ship it.

What the seam does buy you is that the guarantee travels. The shape of the
dedup — one row, one primary key, one transaction — does not depend on what
the key is made of. Stripe hands you a unique event id; providers that do not
force you to build the key from the pair (event name, object id) instead. The
pattern survives the substitution, which is the whole point of writing it
against an interface.

Money leaving the account counts too

Eight event types cover money arriving. Two more cover it leaving, and they
are the ones that get forgotten:

charge.refunded stamps the purchase rather than deleting it. The row stays because it is what reconciles with the provider's own records.
charge.dispute.created is logged at Error level, so it reaches your error reporter rather than a log file nobody greps. A chargeback has a deadline; it should behave like an incident.

The three checkout.session.* events matter together, not individually. A
card pays inside the checkout, so completed already reports
payment_status=paid. A deferred method — SEPA direct debit, which Stripe
enables readily on a EUR checkout — completes unpaid and settles days
later as async_payment_succeeded, or bounces as async_payment_failed.
Subscribe to completed alone and those sales are never fulfilled, silently.

What to test

Three tests, and they are quick:

Bad signature → 400, nothing written. The most common configuration error in production is a mismatched signing secret; you want it loud.
The same event delivered twice → one business write. Send the identical payload twice and assert the subscription row changed once.
Unknown event type → 200. Providers add event types; your endpoint must ignore them without erroring, or their dashboard will start disabling your webhook.

GoVueKit ships all three as integration tests, plus a Playwright journey that
posts a signed duplicate through the real binary. The unconfigured path is
tested too: with no Stripe key — which is the default, and what most
deployments run — the endpoints answer a deliberate 501 and nothing is
written.

Operational notes

Point Stripe at /api/billing/webhook, and subscribe the eight events the README lists rather than "all events": an endpoint that receives everything is an endpoint whose logs tell you nothing.
Local testing: stripe listen --forward-to localhost:8080/api/billing/webhook.
Log the event id on every branch. When a customer says "I paid and nothing happened", the id is what turns a conversation into a query.
Keep processed_events forever, or at least well past the provider's retry window. It is small, and it is your proof.

The rule underneath all of this is the same one that governs
tenancy: make the safe path the only
convenient path, then write the test that fails when someone finds a shortcut.

See how billing fits in the kit.

Row-level multi-tenancy in Go: the rule, the middleware and the test that proves it

Benjamin Touchard — Thu, 01 Oct 2026 07:07:03 +0000

Multi-tenancy has three common implementations: a database per tenant, a
schema per tenant, and a column on every row. For a SaaS that starts small and
must stay operable by one person, the column wins — provided the rule is
enforced in one place rather than remembered in fifty.

Here is the whole design, as implemented in GoVueKit, and the reasoning behind
each choice.

The rule

Every business table has an organization_id. Every query filters on it.
The value comes from the request context, never from the client.

Three sentences, and they are the entire security model for tenancy. The
implementation exists to make violating them awkward.

Step 1: the route carries the tenant

Tenant-scoped routes live under /api/orgs/{orgID}/…. That is deliberate: the
tenant is part of the URL, so it is visible in logs, in tests, and in the
router itself. The alternative — an implicit "current organization" in the
session — makes every request depend on hidden state, and makes tab-switching
users a bug report.

Step 2: one middleware resolves membership

// Context loads the organization and the caller's membership. Non-members
// get a 404 — indistinguishable from a nonexistent org, so org IDs never
// leak across tenants. Must be mounted after RequireAuth.
func (o *Org) Context(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        u, ok := UserFrom(r.Context())
        if !ok {
            writeError(w, http.StatusUnauthorized, "authentication required")
            return
        }
        orgID := chi.URLParam(r, "orgID")
        m, err := o.Q.GetOrgMember(r.Context(), sqlcgen.GetOrgMemberParams{
            OrganizationID: orgID, UserID: u.ID,
        })
        if errors.Is(err, sql.ErrNoRows) {
            writeError(w, http.StatusNotFound, "not found")
            return
        }
        // ... load the organization, put {Org, Role} in the context
    })
}

The membership lookup is the authorisation check. If the caller is not a
member, the request dies here — before any handler, before any query, before
any chance to forget.

Step 3: 404, not 403

A 403 says: this organization exists, and you are not in it. That is an
information leak, and a useful one for an attacker enumerating ids. A 404 says
nothing at all.

The same reasoning applies inside a tenant: a resource that belongs to another
organization is not "forbidden", it is not found, because from the caller's
point of view it does not exist.

The exception is roles inside an organization the caller is a member of.
There, 403 is correct: the member knows the organization exists, they can see
the button is disabled, and hiding the difference would only confuse them.

Step 4: the queries cannot be called wrong

sqlc generates a function per SQL statement. Write the statement with the
tenant in the WHERE clause and the generated signature demands it:

-- name: DeleteOrgInvitation :exec
DELETE FROM org_invitations WHERE id = $1 AND organization_id = $2;

err := q.DeleteOrgInvitation(ctx, sqlcgen.DeleteOrgInvitationParams{
    ID: invID, OrganizationID: orgCtx.Org.ID,
})

A developer who wants to bypass tenancy has to write a new SQL statement,
which shows up in review as a file change in internal/db/queries/. That is
the property you want: the unsafe path is visible, not convenient.

This is also why the kit uses sqlc rather than an ORM. With a query builder,
Invitation.find(id) compiles, runs, and returns another tenant's row. There
is no equivalent of that mistake here, because there is no generic finder.

Step 5: roles are checked server-side

one.With(middleware.RequireOrgRole(org.RoleOwner)).Delete("/", orgsH.Delete)

The frontend also hides the delete button, and that check is explicitly
cosmetic. Anyone can open the console and call the endpoint; the middleware is
what answers.

One rule that is easy to miss: the last owner of an organization cannot be
demoted, removed, or leave. Without it, organizations become unadministrable
and support tickets become database surgery.

Step 6: the test that keeps it true

Every one of the above can be undone by a well-meaning refactor. So the
property gets a test at the level where it actually matters — through HTTP,
against a real database:

1. Create user A and organization A.
2. Create user B and organization B.
3. As B,   GET   /api/orgs/{orgA}                       → 404
4. As B,   GET   /api/orgs/{orgA}/members               → 404
5. As a member (not owner) of A,
           PATCH /api/orgs/{orgA}/members/{userID}      → 403

Steps 3 and 4 are the ones that matter. They are cheap to write once and they
fail loudly the day someone adds a query without the tenant.

In GoVueKit this exists twice: as integration tests run against both database
engines in CI, and as a Playwright journey against the production binary.
Write it at the same time as the resource, never afterwards — a test you must
remember to add later is a test that gets added after the incident.

What this design does not give you

Be clear about the limits before you adopt it:

No physical isolation. A bug in a query can, in principle, return another tenant's row. The mitigations are structural, not physical. If your compliance requirement is literally separate databases, this is not the model you need.
No per-tenant backup/restore. Restoring one customer's data means selective export, not a file copy.
Noisy neighbours share resources. One tenant's heavy query can slow others; you handle that with indexes, pagination and limits.

In exchange you get one database to operate, migrations that run once, and the
ability to answer "how many organizations are on the paid plan?" with a single
GROUP BY. For the overwhelming majority of SaaS products, that trade is
correct — and if you outgrow it, you outgrow it with revenue.

The five-line summary for your own codebase

Put organization_id on every business table, with a cascade and an index.
Resolve membership in one middleware, from the URL, after authentication.
Answer 404 to outsiders, 403 only inside an organization the caller belongs to.
Write queries that take the tenant, so the generated code refuses to be called without it.
Write the cross-tenant test once per resource, and run it in CI.

See it in the code excerpts on the landing page, or read how the
same discipline applies to billing webhooks.

SQLite or PostgreSQL: one codebase, two engines, one env var

Benjamin Touchard — Tue, 29 Sep 2026 07:12:02 +0000

Most boilerplates pick one database and bake it in. GoVueKit supports both,
selected by DB_DRIVER, and the same SQL runs on either. This post explains
how that is done, what it costs, and — the part that actually matters — when
SQLite is a legitimate production choice rather than a toy.

Why bother supporting both

Development. SQLite means make dev works on a fresh laptop with no
service to install, no container to start, no credentials to invent. The file
is created and migrated on first run.

Small production. A single-server product with a few thousand users and
read-heavy traffic runs perfectly on SQLite, with backups that are a file
copy.

Tests that mean something. CI runs the entire Go suite twice, once per
engine. Bugs that only appear on one engine are found by the machine, not by
a customer.

Optionality. If you grow into concurrent writes, you change one variable
instead of rewriting queries.

How portability is actually achieved

Four rules, and they are less restrictive than they sound.

1. Portable types only. TEXT for ids (UUIDs generated in Go, never
SERIAL), TIMESTAMP for time, BOOLEAN, INTEGER. No engine-specific
column types, no JSONB, no arrays.

2. RETURNING is allowed. Both engines support it, which removes the
last-insert-id dance and keeps inserts to one round trip.

3. One code generation. sqlc generates against the PostgreSQL dialect with
$1 placeholders — and the pure-Go SQLite driver (modernc.org/sqlite)
accepts $N natively. So one set of generated Go types serves both engines
instead of two divergent packages.

4. No CGO. modernc.org/sqlite is SQLite translated to Go. That is what
keeps go build cross-compiling to a static binary with no C toolchain, and
it is the reason the "one file to deploy" story holds on both engines.

What you give up: JSONB operators, PostgreSQL full-text search, array
columns, materialised views, LISTEN/NOTIFY. If your product's core feature
needs one of those, use PostgreSQL from day one — the kit runs on it natively
and you simply stop caring about the SQLite path.

When SQLite is enough in production

SQLite's limit is concurrent writes: one writer at a time, serialised. In
practice, with WAL mode, that supports far more than people assume — thousands
of writes per second on decent hardware, because each write is short.

It is a good fit when:

one application server is enough (SQLite is a file, not a network service);
traffic is read-heavy, which describes most B2B SaaS;
you value operational simplicity over horizontal scaling;
your backup story can be "copy the file, plus the WAL".

Switch to PostgreSQL when:

you need more than one application instance sharing state;
writes are sustained and concurrent (event ingestion, chat, telemetry);
you want managed backups, replicas, point-in-time recovery;
your queries need what only PostgreSQL offers, per the list above.

The honest summary: SQLite scales further than its reputation, and the moment
you need two application servers, none of that matters — the file cannot be
shared, and you move.

Moving from one to the other

The schema is the same; only the data has to travel. The path is a dump and a
load, done during a maintenance window:

Stop the app.
Export each table from SQLite (CSV or INSERT statements).
Start with DB_DRIVER=postgres and AUTO_MIGRATE=true so goose creates the schema.
Load the data, then check row counts per table and re-run the test suite against the new database.
Start the app.

There is no ORM-generated schema drift to reconcile, because the migrations
are the same files. Do it early — moving 50,000 rows is an evening, moving 50
million is a project.

The rules you must keep if you edit the SQL

The portability is a discipline, not a library. Three habits keep it:

Write the query in internal/db/queries/*.sql, never inline in Go, so every statement is reviewable in one place.
Run make test before committing. CI runs both engines; your laptop runs SQLite by default, and TEST_DB_DRIVER=postgres (with TEST_POSTGRES_DSN pointing at a server) runs the same suite locally.
Avoid the tempting extension. The moment you write JSONB, decide explicitly that PostgreSQL is now required, and note it in DECISIONS.md.

That last one is the real trade-off. Portability costs you the fancy features
of both engines; in exchange, development has no dependencies and production
has an escape hatch.

The uncomfortable question

Is supporting two engines worth it for your product? If you know you will
run PostgreSQL, you could delete the SQLite path and use JSONB freely. The
kit does not stop you — it is your source code.

What you would lose is the property that makes a first run cheap: clone the
repository, start the server, and the database is a file that did not exist a
second ago. That is also what makes the test suite fast enough to run on every
save.

Keep both while you are small. Drop one deliberately, with a line in
DECISIONS.md, if your product outgrows the compromise.

See how the data layer fits together, or read
the deployment guide for the production
setup on either engine.

GoVueKit vs supastarter vs SaaS Pegasus vs ShipFast: an architecture comparison

Benjamin Touchard — Thu, 24 Sep 2026 07:13:03 +0000

People searching for "ShipFast alternative" or "supastarter vs" are rarely
asking which kit has more checkboxes. They are asking which architecture
they want to live with. This is a comparison of four kits that each
represent a family, written by the people who sell one of them (GoVueKit),
with every price linked to the page it came from so you can verify it the
day you read this.

The four, in one line each

ShipFast — Next.js on managed services (MongoDB or Supabase, Google OAuth and magic links, Stripe or Lemon Squeezy, Mailgun or Resend). The fastest path from zero to a landing page with a checkout. Built for solo makers shipping many small products.
supastarter — a full-stack TypeScript kit for Next.js, Nuxt or TanStack Start: better-auth, Prisma or Drizzle, five payment providers, organizations with seat billing, i18n, an admin UI, serverless-friendly. Built for TypeScript teams shipping a B2B product.
SaaS Pegasus — a Django monolith with React or HTMX on the front (a Vue example too), Celery for background work, teams with roles, 2FA, i18n, feature flags, impersonation, Wagtail CMS. Built for Python teams, and the most mature of the four.
GoVueKit — a Go API (chi, sqlc) with a Vue 3 + TypeScript SPA embedded in one binary, PostgreSQL or SQLite, accounts with OIDC and TOTP, organizations with row-level tenancy, Stripe with idempotent webhooks, a durable email queue, an admin backoffice. Built for teams who want to own and self-host one artefact.

The table

	ShipFast	supastarter	SaaS Pegasus	GoVueKit
Backend	Next.js API routes	Nuxt/Next server + Hono	Django	Go (chi + sqlc)
Frontend	React (Next.js)	Vue (Nuxt) or React	React or HTMX	Vue 3 SPA, embedded
Database	MongoDB or Supabase	Prisma/Drizzle (PostgreSQL…)	PostgreSQL (Django ORM)	PostgreSQL or SQLite
Teams / tenancy	no	organizations, seat billing	teams, roles	organizations, roles, row-level isolation
Payments	Stripe or Lemon Squeezy	Stripe, Lemon Squeezy, Polar, Creem, Dodo	Stripe (subs, per-seat, e-commerce)	Stripe (subs, one-time), idempotent webhooks
Background jobs	—	trigger.dev / QStash (external)	Celery (+ broker)	in-process, DB-backed
Email	Mailgun / Resend	transactional templates	templates	FR/EN templates, durable queue, SMTP or Resend
Admin	—	admin UI	Django admin + impersonation	backoffice: MRR, ARPU, churn, audit, impersonation
i18n	—	yes, incl. emails	yes	FR/EN UI + emails, parity tested
Runs in production	Node (Vercel-shaped)	Node / serverless	Python + Celery + broker	one static binary
Tests shipped	—	Playwright e2e	yes	234 tests on both DBs + 14 Playwright journeys
Price (time of writing)	$199–$299	€299–€1,499	$449 (1 project) / $649	€199 (launch) / €249
Refund	none after access	see site	7 days	14 days until the code is claimed

Cells report what each product states on its own pages; where a page
does not say, the cell is empty rather than guessed.

What each architecture assumes

ShipFast assumes you will not need a backend. That is a feature, not a
gap: a landing page, a checkout, a login and a database-as-a-service is
the right shape for a $9/month micro-SaaS, and nothing ships faster. It
stops being the right shape when a customer asks for teams, an audit log
or a data-processing agreement listing your sub-processors. Its
non-refundable policy is worth knowing before you buy.

supastarter assumes TypeScript end to end and a Node host. If your
team writes TypeScript on both sides and deploys on Vercel or a Node
runtime, it is the most complete kit in the Vue and React worlds: real
organizations, seat billing, i18n down to the emails. The cost is
structural: background jobs run on an external service, and production
means a JavaScript runtime plus whatever the serverless target adds. The
top tiers are priced for agencies.

SaaS Pegasus assumes Python and a team that will run Celery. It is the
most mature product here, with features the others lack (feature flags,
Wagtail, async channels) and a per-project licence at the lower tier. A
Django monolith is a fine place to live; it also means a Python runtime, a
worker, a broker and, usually, a Node build for the React front. If your
backend team is Python, this is the serious choice.

GoVueKit assumes you want one artefact you can read. The Vue app is
compiled into the Go binary; the public pages are prerendered for SEO; the
database is PostgreSQL or SQLite from the same generated queries; jobs and
the email queue are tables in that database. Production is one ~27 MB
file on any VPS, no Node, no broker, no platform. The cost is a Go backend
— a feature for Go teams, a wall for others — and a smaller ecosystem of
add-ons than Django or Next.js. It is also deliberately a core: a blog
engine, a code generator and a second payment provider were built and then
removed to keep the codebase readable in an afternoon, and
DECISIONS.md
says why.

Five questions that decide it

Which language is your backend team fluent in? This settles it more often than any feature. TypeScript → supastarter. Python → Pegasus. Go → GoVueKit. None yet, solo, shipping a small product → ShipFast.
Do you need organizations on day one? ShipFast does not have them. The other three do; only GoVueKit and Pegasus test the cross-tenant boundary in an end-to-end suite that you can read.
Where will it run, and who signs the data-processing agreement? Managed services mean sub-processors; a binary or a monolith on your VPS means your hosting provider and Stripe. European customers ask.
What is the exit? A binary and a database dump move anywhere. A product built on a BaaS moves by re-implementing what the BaaS did.
How much code will you own? Ask each vendor for the line count. Owning more is not better; owning what you can read is.

Try the one you can try without paying

ShipFast and supastarter have demos on their sites; Pegasus has an
open-source tier. GoVueKit runs its entire stack locally from one file,
no account, no licence — the app, PostgreSQL, single sign-on through Dex,
MinIO for S3, a Stripe double and a mail inbox:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d

Whatever you pick, read its tenancy code and its webhook handler before
you bill through it. That hour is the whole evaluation.

If a cell above misstates your product, open an issue on
github.com/kOlapsis/govuekit
and it will be corrected with attribution.

Multi-tenant SaaS in Go with chi and sqlc: the whole tenancy layer

Benjamin Touchard — Tue, 22 Sep 2026 07:04:03 +0000

Row-level multi-tenancy is the least glamorous security boundary in a B2B
SaaS and the one most often broken by a Tuesday afternoon commit: a new
query, a missing WHERE organization_id = $1, and one customer reads
another's data. Row-level multi-tenancy in Go
explained the design; this is the layer itself, as it ships in GoVueKit,
file by file.

The model

Three tables carry tenancy: organizations, org_members (organization,
user, role) and every business table, which carries organization_id.
Identifiers are TEXT, generated in Go (UUIDs), so the schema is identical
on PostgreSQL and SQLite and nothing depends on a sequence.

Roles are three strings with an order: owner > admin > member. There is
no permission matrix, because a boilerplate that ships one ships a
maintenance burden; a product that needs one adds it next to
RoleAtLeast.

The query that decides everything

-- name: GetOrgMember :one
SELECT * FROM org_members WHERE organization_id = $1 AND user_id = $2;

sqlc turns it into a typed Go method. Every request that names an
organization goes through it, once, before any handler runs.

The middleware

func (o *Org) Context(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        u, ok := UserFrom(r.Context())
        if !ok {
            writeError(w, http.StatusUnauthorized, "authentication required")
            return
        }
        orgID := chi.URLParam(r, "orgID")
        m, err := o.Q.GetOrgMember(r.Context(), sqlcgen.GetOrgMemberParams{
            OrganizationID: orgID, UserID: u.ID,
        })
        if errors.Is(err, sql.ErrNoRows) {
            writeError(w, http.StatusNotFound, "not found")
            return
        }
        if err != nil {
            o.Log.Error("org middleware: load membership", "error", err)
            writeError(w, http.StatusInternalServerError, "internal error")
            return
        }
        organization, err := o.Q.GetOrganization(r.Context(), orgID)
        if err != nil {
            writeError(w, http.StatusNotFound, "not found")
            return
        }
        ctx := context.WithValue(r.Context(), orgKey, OrgCtx{Org: organization, Role: m.Role})
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

Three things to notice.

404, not 403, for a non-member. A 403 says "this exists and you may
not see it", which is exactly the enumeration oracle an attacker wants
when guessing organization ids. To an outsider, the organization does not
exist. The same status is returned whether the id is wrong or the
membership is missing, so the two cases are indistinguishable from
outside.

The membership row is the tenant context. The handler downstream
never re-derives who the user is or what they may do; it reads
OrgFrom(ctx) and gets the organization and the role. There is one place
to get tenancy wrong, and it is thirty lines long.

Errors are boring on purpose. A database failure is a 500 with a log
line, never a 404 that would make an outage look like a permission
problem.

The role check, after the tenant check

func RequireOrgRole(minRole string) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            oc, ok := OrgFrom(r.Context())
            if !ok || !org.RoleAtLeast(oc.Role, minRole) {
                writeError(w, http.StatusForbidden, "insufficient permissions")
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

Here a 403 is correct: the caller is a member, the organization is not a
secret to them, they simply lack the role. The order matters — membership
first (404), then role (403) — and the router enforces it structurally.

The route group

api.Route("/orgs", func(or chi.Router) {
    or.Route("/{orgID}", func(one chi.Router) {
        one.Use(orgMW.Context)
        one.With(middleware.RequireOrgRole(org.RoleAdmin)).Patch("/", orgsH.Update)
        one.With(middleware.RequireOrgRole(org.RoleOwner)).Delete("/", orgsH.Delete)
        one.With(middleware.RequireOrgRole(org.RoleOwner)).Patch("/members/{userID}", orgsH.ChangeRole)
        one.With(middleware.RequireOrgRole(org.RoleAdmin)).Delete("/members/{userID}", orgsH.RemoveMember)
        one.With(middleware.RequireOrgRole(org.RoleOwner)).Post("/billing/checkout", billingH.Checkout)
        // ...
    })
})

Everything under /api/orgs/{orgID} inherits orgMW.Context. A new
tenant-scoped endpoint cannot be mounted outside the group by accident,
because the group is where {orgID} is defined. The role requirement sits
on the route line, next to the verb, where a reviewer sees it.

The convention for business tables

When you add your first resource — the ten-minute tour
walks a projects table through every layer — the queries take this
shape:

-- name: GetProject :one
SELECT * FROM projects WHERE organization_id = $1 AND id = $2;

-- name: ListProjects :many
SELECT * FROM projects WHERE organization_id = $1 ORDER BY created_at DESC;

The handler passes OrgFrom(ctx).Org.ID as the first argument, always.
Because sqlc generates a typed parameter struct per query, a query that
lacks the tenant column also lacks the parameter, which is visible in the
generated signature and in review. It is not a guarantee; it is a
convention that is hard to violate silently, which is what a small
codebase can afford.

Lists of organizations themselves go through membership too: GET /api/orgs returns the organizations the user belongs to, nothing else,
so an outsider does not even learn that an id exists.

The test that keeps it true

Unit tests on the middleware are cheap and exist. The one that matters
runs against the production binary in Playwright, with three real
browsers:

// RBAC: the member hits an admin-only route → 403, server-side.
const patch = await member.request.patch(`/api/orgs/${orgId}`, {
  data: { name: 'Hacked' },
  headers: { 'X-CSRF-Token': await csrf(member) },
})
expect(patch.status()).toBe(403)

// Cross-tenant isolation: an unrelated user gets 404 on the org, and
// never sees it in their list.
const probe = await stranger.request.get(`/api/orgs/${orgId}`)
expect(probe.status()).toBe(404)
const list = await (await stranger.request.get('/api/orgs')).json()
expect(list.organizations).toHaveLength(0)

An owner creates the organization and invites a member; the member
accepts from the email and gets a 403 on an admin action; a stranger gets
a 404 and an empty list. Remove the WHERE clause, or mount a route
outside the group, and CI goes red on both database engines.

What this does not cover, and why

No PostgreSQL row-level security policies: they would make the SQLite
target a second-class citizen and hide the boundary in the database, where
a Go reviewer does not look. No per-tenant schemas or databases: at the
scale a boilerplate targets, one schema with an indexed organization_id
is faster to operate and to back up. The 404-for-outsiders rule itself is
recorded in the kit's DECISIONS.md, which is public.

See it run, three browsers included, in the labs:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d

Stripe webhooks in Go: the complete idempotent handler, line by line

Benjamin Touchard — Thu, 17 Sep 2026 07:12:31 +0000

Every Stripe tutorial in Go shows the same forty lines: read the body, call
ConstructEvent, switch on the type, update the database. Those forty lines
double-charge on a retry, lose a payment on a restart, trust a payload an
attacker can shape, and time out under a burst. This is the handler
GoVueKit ships instead — the actual code, then each design choice and the
failure it closes. It is the pattern we described in
Idempotent billing webhooks; this
article is the implementation.

The shape: receive fast, process later, once

Two moving parts and one table.

CREATE TABLE processed_events (
    event_id     TEXT PRIMARY KEY,
    event_type   TEXT NOT NULL,
    object_id    TEXT NOT NULL DEFAULT '',
    status       TEXT NOT NULL DEFAULT 'pending',
    attempts     BIGINT NOT NULL DEFAULT 0,
    received_at  TIMESTAMP NOT NULL,
    processed_at TIMESTAMP
);
CREATE INDEX processed_events_status_idx ON processed_events (status, received_at);

Portable SQL on purpose: TEXT ids, TIMESTAMP, no engine-specific type, so
the same migration runs on PostgreSQL and SQLite.

Part one: the HTTP handler

func (h *Billing) Webhook(w http.ResponseWriter, r *http.Request) {
    if !h.requireEnabled(w) {
        return
    }
    payload, err := io.ReadAll(io.LimitReader(r.Body, 1<<20))
    if err != nil {
        Error(w, http.StatusBadRequest, "cannot read body")
        return
    }
    event, err := h.Svc.VerifyWebhook(payload, r.Header)
    if err != nil {
        h.Log.Warn("webhook signature rejected", "error", err)
        Error(w, http.StatusBadRequest, "invalid signature")
        return
    }
    fresh, err := h.Svc.Enqueue(r.Context(), event)
    if err != nil {
        h.Log.Error("webhook enqueue", "error", err)
        Error(w, http.StatusInternalServerError, "internal error")
        return
    }
    if !fresh {
        h.Log.Info("webhook duplicate ignored", "event", event.ID)
    }
    JSON(w, http.StatusOK, map[string]string{"received": "ok"})
}

Five decisions in twenty lines.

requireEnabled. With no STRIPE_SECRET_KEY the route answers 501,
not a panic. Most deployments start without billing; the unconfigured path
is a first-class, tested state.

io.LimitReader(r.Body, 1<<20). Signature verification hashes the
body. Without a cap, a 2 GB POST is a free CPU bill. One mebibyte is an
order of magnitude above any Stripe event.

Signature over the raw bytes. VerifyWebhook hands the untouched body
to Stripe's webhook.ConstructEventWithOptions with the endpoint secret;
the library checks the HMAC and rejects timestamps older than five
minutes. Decode the JSON first and re-serialize it and the signature will
never match — a classic.

event, err := webhook.ConstructEventWithOptions(body, header.Get("Stripe-Signature"), p.WebhookSecret,
    webhook.ConstructEventOptions{IgnoreAPIVersionMismatch: true})

IgnoreAPIVersionMismatch is deliberate: the dashboard lets you pick any
release train for the endpoint, and nothing in the payload is read beyond
identifiers, so the envelope version is irrelevant. Refusing it would turn
a dashboard setting into a silent outage.

Enqueue and the primary key. The handler writes one row and nothing
else:

-- name: InsertEvent :execrows
INSERT INTO processed_events (event_id, event_type, object_id, status, received_at)
VALUES ($1, $2, $3, 'pending', $4)
ON CONFLICT (event_id) DO NOTHING;

:execrows returns the number of rows inserted. Zero means Stripe
delivered this event before; the handler logs it and still answers 200,
because a duplicate is not an error, it is the retry policy working.
Dedup is the database's job, not a SELECT followed by an INSERT that
two concurrent deliveries can both pass.

200 in a millisecond. No Stripe API call, no email, no business write
in the request. Stripe retries anything slower than its timeout, and a
burst of a hundred events during an outage recovery must not take a hundred
round-trips to survive.

Part two: the worker

A goroutine runs ProcessPending on an interval. It lists pending events
(oldest first, at most 20, fewer than 8 attempts) and hands each to
processEvent:

func (s *Service) processEvent(ctx context.Context, ev sqlcgen.ProcessedEvent) error {
    change, err := s.Provider.Resolve(ctx, Event{
        ID: ev.EventID, Type: ev.EventType, ObjectID: ev.ObjectID,
    })
    switch {
    case errors.Is(err, ErrUnknownEvent):
        change = Change{} // acknowledged, nothing to write
    case err != nil:
        return err
    }
    if change.Buyer != nil {
        return fmt.Errorf("payment from unknown customer %s (%s): no organization to credit",
            change.Buyer.CustomerID, change.Buyer.Email)
    }

    tx, err := s.DB.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("begin: %w", err)
    }
    defer func() { _ = tx.Rollback() }()
    qtx := s.Q.WithTx(tx)

    if change.Subscription != nil {
        if err := qtx.UpdateSubscriptionState(ctx, *change.Subscription); err != nil {
            return fmt.Errorf("apply subscription: %w", err)
        }
    }
    if change.Purchase != nil {
        if _, err := qtx.InsertPurchase(ctx, *change.Purchase); err != nil {
            return fmt.Errorf("apply purchase: %w", err)
        }
    }
    if change.RefundedPaymentRef != "" {
        if _, err := qtx.MarkPurchaseRefunded(ctx, sqlcgen.MarkPurchaseRefundedParams{
            RefundedAt: sql.NullTime{Time: now(), Valid: true},
            PaymentRef: change.RefundedPaymentRef,
        }); err != nil {
            return fmt.Errorf("apply refund: %w", err)
        }
    }
    if err := qtx.MarkEventDone(ctx, sqlcgen.MarkEventDoneParams{
        EventID: ev.EventID, ProcessedAt: sql.NullTime{Time: now(), Valid: true},
    }); err != nil {
        return fmt.Errorf("mark done: %w", err)
    }
    if err := tx.Commit(); err != nil {
        return err
    }
    if change.PaymentFailedCustomer != "" {
        s.notifyPaymentFailed(ctx, change.PaymentFailedCustomer)
    }
    if change.DisputedCharge != "" {
        s.Log.Error("billing: chargeback opened", "charge", change.DisputedCharge)
    }
    return nil
}

Resolve re-fetches by ID. The provider takes the event's object id
and asks Stripe for the current subscription or checkout session. The
payload is never the source of truth: it may be stale (two events about the
same subscription arrive out of order), and it is attacker-shaped input by
definition even when the signature is valid. What comes back is a small
Change struct — subscription state, a purchase, a refund reference, a
failed-payment customer, a disputed charge — translated from Stripe's
vocabulary into ours. That translation is the billing.Provider interface,
which is also the seam for a second processor.

Business write and MarkEventDone in one transaction. Either both
land or neither does. A crash between "wrote the purchase" and "marked the
event done" would otherwise replay the purchase on restart; here the replay
finds the event still pending, re-fetches, and the INSERT … ON CONFLICT (checkout_id) DO NOTHING on purchases makes the second application a
no-op anyway. Two layers of idempotency, each cheap.

Unknown customer stays pending. A payment from a customer this
database has never seen has nowhere to land. Dropping it would be silent
data loss about money; the event stays visible with its attempts count
rising until a human decides. After eight attempts the worker stops
retrying and the row remains for inspection.

Zero rows on refund is fine. A refund can reference a payment this
deployment never recorded (a test-mode leftover, a migration). The event
must complete rather than retry forever.

Side effects after the commit. The failed-payment email to the
organization's owners goes out only once the state is durable; an email is
not worth losing a fulfilled payment. A chargeback logs at error level on
purpose, because that reaches the configured error reporter, and a dispute
ignored until the deadline is lost money.

Two events every subscription integration forgets

Subscribe the endpoint to checkout.session.async_payment_succeeded and
checkout.session.async_payment_failed next to
checkout.session.completed. A card completes paid; a deferred method
(SEPA debit, which Stripe enables readily on euro prices) completes
unpaid and settles days later as the second event. Listen to the first
alone and every SEPA sale is lost in silence.

What the tests cover

The suite drives the service with a Stripe double and asserts the failure
modes above, on PostgreSQL and SQLite in CI:

a duplicate delivery is a no-op: the second Enqueue inserts nothing and the object is fetched once;
a replayed fulfilment leaves exactly one purchase;
a deferred payment (SEPA) is not fulfilled until it settles, and its failure emails the organization's owners;
a payment from an unknown customer fails the event and leaves it pending, visible;
a refund marks the purchase once and its replay is acknowledged; a refund of a payment this database never saw, a dispute and an unknown event type are acknowledged without a write;
with no Stripe key the billing routes answer 501, because the unconfigured deployment is the one most people run.

Locally, stripe listen --forward-to localhost:8080/api/billing/webhook
against the labs stack replays real events against the real binary.

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d

The labs runs stripe-mock, which answers the API but emits no webhook; put
real test keys in a .env next to the compose file and the path above
runs end to end.

Vibe coding on a boilerplate: stop your agent from rebuilding what it already has

Benjamin Touchard — Tue, 15 Sep 2026 07:13:31 +0000

Point a coding agent at a SaaS boilerplate and ask for "premium plans with a
14-day trial". If the agent does not know that internal/billing exists,
what you get back is impressive, plausible — and wrong: a second Stripe
client, a second webhook route, a plans table that duplicates one already
served by configuration. Everything compiles. Half of it is untested. You
now own two billing systems.

This is not a hallucination problem in the usual sense. The agent did not
invent an API; it invented work. And it invented it because nothing told
it the work was already done.

Why prompts do not fix it

The reflex is to prompt harder: "use the existing billing code". It helps
once. It does not survive the tenth session, the second agent, or the
teammate who forgot the incantation. Instructions that live in chat
history die with the chat.

What survives is a file in the repository that every agent reads before
writing — if, and only if, that file cannot rot.

The map

GoVueKit ships AGENTS.md at the repository root — the file Codex, Cursor
and their kind read natively; CLAUDE.md imports it, so Claude Code reads
the same one. It is not prose about being careful. It is a table:

capability	package	extend through
payments	`internal/billing`	`billing.Provider`
email	`internal/email`	`email.Mailer`
files	`internal/storage`	`storage.Storage`
background jobs	`internal/jobs`	`Queue.Register`
signup side effects	`internal/auth`	`OnUserCreated`
roles & tenancy	`internal/http`	`RequireOrgRole`

with one instruction above it: before writing anything, find it here.
"Premium plans" now resolves to configuration plus the existing provider
seam, because the map says so in the place the agent looks.

The map also carries the rules the codebase enforces (portable SQL,
organization_id on every business query, webhooks idempotent, French and
English in step) and the chain a new feature follows — migration, queries,
domain package, handler, route, store, view, tests. An agent that knows
the chain produces a diff shaped like the codebase instead of a framework
of its own.

A map that cannot rot

Documentation drifts; that is why agents ignore it. GoVueKit's map is held
by a test, cmd/server/agents_test.go, and the suite goes red when:

an internal/ package exists that AGENTS.md does not mention — you added code, you map it, or CI fails;
AGENTS.md references a path that no longer exists;
a named seam is renamed — the seams are compile-time references, so billing.Provider cannot silently become something else.

The consequence is worth stating plainly: if make test is green, what
the map says is true. That is a property most documentation cannot claim,
and it is the property that makes an agent's trust in the file rational.

The rest of the harness

The map narrows what the agent writes; the suites judge it. 186 Go tests
run on both PostgreSQL and SQLite, 48 frontend tests include a check that
the French and English catalogues define exactly the same keys, and 14
Playwright journeys drive the real production binary — including the
cross-tenant request that must 404. An agent's diff that leaks tenant data
or forgets a translation fails before you read it.

For the final look, the labs boots the whole product locally — SSO,
uploads, checkout, email — from one file, with nothing to configure:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d

What this does not solve

Three concessions, because a harness is not magic.

First, the map keeps an agent from rebuilding the foundation; it does not
make your feature idea good. An agent will faithfully implement a workflow
your users never asked for, tests green all the way.

Second, an agent can still write a worse version of something inside the
right file. The seams tell it where; they do not guarantee elegance.
Review stays your job — the harness only shrinks what needs reviewing.

Third, this works partly because the kit is small: 19 Go packages, a
schema in one migration file, an architecture that walks in ten minutes.
A map over a sprawling framework would be a book, and agents do not read
books. If you evaluate another starter for agent work, ask how much of it
fits in a context window — and whether anything fails the build when its
documentation lies.

Vue 3 SaaS starter kits in 2026: Nuxt kits, Vue on another backend, and one Go binary

Benjamin Touchard — Thu, 10 Sep 2026 07:07:36 +0000

Every "best SaaS boilerplate" list is a Next.js list with a Vue footnote. If
you want Vue, you are choosing between three families that are not really
comparable: Nuxt full-stack kits (JavaScript end to end), Vue on a
non-JavaScript backend (Laravel, .NET, Go), and UI templates that look
like kits and are not. We sell a kit in the second family (GoVueKit), so it
is in the table under the same questions as everyone else, with links to
each project's own page.

The table

Kit	Family	Backend	Database	Teams	Billing	i18n	Licence / price
supastarter for Nuxt	Nuxt full-stack	Nuxt 3 server + Hono API	Prisma or Drizzle (PostgreSQL…)	yes, orgs + seat billing	Stripe, Lemon Squeezy, Polar, Creem, Dodo	yes, incl. emails	commercial, from €299
NuxSaaS	Nuxt full-stack	Nuxt (v4-ready)	PostgreSQL + Drizzle	see repo	Stripe / Polar	see repo	open source
SupaNuxt SaaS	Nuxt + BaaS	Nuxt 3 + Supabase + tRPC	Supabase (Prisma)	yes	Stripe	—	open source
Nuxt UI SaaS template	UI template	none (pages only)	none	no	no	—	free (Nuxt UI + Nuxt Content)
Laravel + Inertia + Vue kits (e.g. Larafast VILT)	Vue on PHP	Laravel	MySQL / PostgreSQL	varies	Stripe / Lemon Squeezy via Cashier	varies	commercial
Brick Starter	Vue on .NET	ASP.NET Core	SQL Server / PostgreSQL	yes, multi-tenant	Stripe	see site	commercial
GoVueKit	Vue on Go	Go (chi, sqlc)	PostgreSQL and SQLite	yes, RBAC + row-level	Stripe: subscriptions + one-time, idempotent webhooks	yes, FR/EN UI + emails	commercial, €199 one-time

Cells report what each project advertises on its own pages at the time of
writing; where a page did not say, the cell says so.

Family one: Nuxt full-stack kits

supastarter is the reference here and priced like it: Nuxt 3, better-auth
(passwords, passkeys, magic links, OAuth, 2FA), Prisma or Drizzle, five
payment providers, organizations with seat-based billing,
internationalization down to the emails, an admin UI, S3 storage,
background jobs through trigger.dev or QStash, Playwright tests, and
serverless-friendly deployment. If your team is TypeScript end to end and
you deploy on Vercel or a Node host, this is the most complete option in
the Vue world. What you are buying is also what you are committing to: the
Nuxt server, an external job runner, and a JavaScript runtime in production.

NuxSaaS is the free alternative that has kept up: Nuxt with Better Auth,
PostgreSQL through Drizzle, Stripe or Polar. It is the right first look if
budget is the constraint; check organizations and admin against your needs
before you assume they are there.

SupaNuxt SaaS predates both and shows the 2023 shape of the market:
Supabase for auth and data, tRPC, Prisma, teams and plans, an OpenAI helper.
Fine to learn from; the Supabase dependency is a decision you make on day
one and unmake with a rewrite.

Family two: Vue on a backend that is not JavaScript

This is the family for teams whose backend language is already chosen. The
Vue app is a real SPA with its own build; the backend is whatever your team
is good at.

Laravel + Inertia + Vue is the largest branch. Inertia lets Laravel
controllers render Vue pages without an API layer; Cashier handles Stripe.
Several commercial kits ship a VILT flavour (Larafast is the best-known),
and the Laravel ecosystem gives you queues, mail and Nova/Filament for
admin. You get PHP hosting economics and a huge hiring pool; you run a PHP
runtime, a Node build and, usually, Redis and a queue worker.

.NET + Vue exists for shops that live in C#. Brick Starter ships one
ASP.NET Core backend with multi-tenancy and Stripe, and a choice of
frontends including Vue; evaluate it as you would any .NET template, with
the licence terms in front of you.

Go + Vue is the smallest branch, and it is where GoVueKit sits. The
pitch is operational: vite build output is embedded in the Go binary with
go:embed, the public pages are prerendered to static HTML at build time
(canonical, hreflang, sitemap, no SSR server), and the result is one
~27 MB static file that runs on any VPS with no Node, no PHP, no runtime
to patch. Inside: Vue 3 with TypeScript and the Composition API, Pinia, Vue
Router, Tailwind, dark mode, FR/EN with a test that fails when the two
catalogues drift, and a typed fetch client over a Go API built with chi and
sqlc. The SaaS parts are the ones the Nuxt kits have — accounts with TOTP
and OIDC, organizations with row-level tenancy, Stripe with idempotent
webhooks, a durable email queue, an admin backoffice — with the difference
that the whole thing is ~11 000 lines of Go you can read in an afternoon
and runs on PostgreSQL or SQLite from the same generated queries.

Family three: templates that are not kits

The Nuxt UI SaaS template, the Vuexy and Vuestic admin themes, the
Tailwind UI application shells: beautiful pages with no backend, no auth
model, no billing, no tenancy. They are a design purchase. Buying one and
believing you bought a SaaS foundation is the most common mistake on the
Vue side of this market, because the screenshots look identical to the real
thing.

How to choose

Do you want JavaScript in production? If yes, Nuxt kits are the natural
home and supastarter is the safe choice. If no — because your backend team
writes Go, PHP or C#, or because you want a single deployable artefact — the
second family is the only one that fits, and the comparison becomes a
backend comparison.

Where will it run? Serverless and Vercel favour Nuxt. One VPS, an
on-prem install at a customer, a European host with a data-residency
clause: favour a binary or a PHP app you fully control.

Who reads the code? Every kit above says "you own the code". Owning
40 000 lines of someone else's TypeScript across a monorepo is a different
ownership from 11 000 lines of Go plus a Vue app you can grep end to end.
Ask for the count.

What is the licence's restriction clause? Seats, client work, and
whether "lifetime" means the product's lifetime or the major version's.

Try before you decide

supastarter has a demo and a documentation site. NuxSaaS and SupaNuxt clone
and run. GoVueKit runs its full stack — app, PostgreSQL, single sign-on,
S3, a Stripe double and a mail inbox — from one file, no account, no
licence:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d

Then open the Vue source of whichever kit you liked and look for three
things: how a page gets its data (typed client, tRPC, Inertia props), how a
route decides you are allowed there (server-side, always), and how a
missing translation is caught (a test, or a user).

If a cell above is wrong about your project, open an issue on
github.com/kOlapsis/govuekit
and it will be corrected with attribution.

Go SaaS boilerplates in 2026: the honest list

Benjamin Touchard — Tue, 08 Sep 2026 07:07:41 +0000

Search "Go SaaS boilerplate" and you get directory pages that list three
Next.js kits and a Laravel one, because the Go entries do not exist or are
buried. This is the list I wanted when I started: what runs in Go today,
what each kit really includes, and what it commits you to. We sell one of
them (GoVueKit), so it sits in the same table under the same questions, and
the links go to every project's own page so you can check.

What counts

A SaaS boilerplate is not "a Go web starter". A starter gives you a router,
a template layer and a session cookie. A SaaS foundation gives you the five
things every product rewrites and nobody wants to: accounts (with the
unglamorous flows — reset, verification, two-factor, revocation),
organizations (roles and tenant isolation), billing (a webhook
handler you can bill through), transactional email (durable, not
fire-and-forget) and an admin surface. Kits below are judged on those
five, plus the questions that matter in month six: which database, which
licence, how it deploys.

Excluded on purpose: go-blueprint
and gowebly (generators for a project
skeleton, excellent, not SaaS kits), PocketBase
(a backend-in-one-file you build a SaaS on, not a SaaS), and the dozens
of "Go + HTMX + templ starter" repositories that stop at a login form.

The table

Kit	Frontend	Database	Teams / tenancy	Billing	Email	Admin	Licence
goilerplate	templ + HTMX (or Datastar), server-rendered	SQLite or PostgreSQL	not advertised	Polar / Stripe subscriptions	Resend / SMTP	—	free tier + paid
Pagoda	Gomponents + HTMX + Alpine	SQLite (Ent; Postgres swappable)	no	no	skeleton only	yes, entity admin	MIT
LastSaaS	React 19 SPA	MongoDB	yes, RBAC	Stripe: subscriptions, per-seat, trials, credits	Resend	yes	MIT
SaaS Boost Kit	SvelteKit	PocketBase	see site	Stripe, guest checkout	see site	PocketBase admin	commercial
Go SaaS Startup Kit	server-rendered Go templates	PostgreSQL (AWS-oriented)	yes	Stripe	AWS SES	yes	open source, older
go-saas/kit	React + Ant Design admin	PostgreSQL / MySQL	yes	Stripe	—	yes	Apache-2.0, microservices
GoVueKit	Vue 3 + TypeScript SPA, embedded	PostgreSQL and SQLite	yes, RBAC + row-level	Stripe: subscriptions + one-time, idempotent webhooks, refunds	FR/EN templates, durable DB queue	yes, MRR/churn/audit	commercial, one-time

Cells say what each project advertises. Where a page did not say, the cell
says so rather than guessing; every name links to the source.

One paragraph each

goilerplate is the most polished of the server-rendered kits, from the
author of templUI, and the free tier is genuinely usable: Go, templ, SQLite,
SMTP, auth, security headers, tests and CI. The paid tier adds the SaaS
parts (subscriptions through Polar or Stripe, S3 uploads, analytics, legal
pages). If you want no JavaScript build step and are happy with HTMX or
Datastar as your interactivity model, start here. What to check before
paying: how organizations and roles are modelled, because "SaaS" on the
landing mostly means "individual subscriptions".

Pagoda is a starter kit, and says so: "not a framework". Echo, Ent,
type-safe HTML in Go, HTMX, a task queue with a monitoring UI, an admin
panel generated from your entities, caching, CSRF, sessions. No payments,
and email is a skeleton you finish. It has the largest community of the
list (over 3 000 GitHub stars) and the cleanest code to learn from. Pick it
when you want to build your SaaS layer yourself on good foundations.

LastSaaS is the newest and the most feature-dense: multi-tenant RBAC,
Stripe with per-seat pricing and credit bundles, outgoing webhooks, API keys,
white-label theming, an analytics dashboard, even an MCP server for
AI-driven admin — MIT-licensed, deployed as one small container on Fly.io.
Two things to weigh: the database is MongoDB (fine, but it is the one
non-relational choice on this list, and multi-tenant reporting in SQL is a
different life), and the README states it was built entirely through
conversation with Claude Code. That is not a criticism; it means you should
read the tenancy and webhook code before you bill through it, which is true
of every kit here.

SaaS Boost Kit pairs a Go API with SvelteKit and PocketBase for the
database and admin, with Stripe subscriptions, webhooks and a guest checkout
for one-off sales, unit and Playwright tests, and a configurable landing.
It is commercial (pricing on the site). The PocketBase choice gives you an
admin UI for free and a SQLite file for a database; it also means part of
your backend is a framework you extend by hooks rather than code you own.

Go SaaS Startup Kit is the veteran: a set of libraries and a working
multi-tenant example aimed at AWS (SES, ECS). It is open source and
complete for its era, but check the commit history before committing your
own; it predates most of what the Go ecosystem now takes for granted.

go-saas/kit is the outlier: a microservice architecture (Kratos-style)
with tenant management, Stripe plans and a React/Ant Design admin. If you
already run services and need a SaaS control plane, it is the only kit on
the list shaped for that. For a product team of one to five, it is an
architecture to grow into, not start from.

GoVueKit — ours — is the only one of the list built around a real SPA
embedded in the binary: Vue 3 with TypeScript, Pinia and a typed fetch
client, compiled by Vite and served with go:embed, prerendered to static
HTML for the public pages so SEO does not need SSR. Go with chi and sqlc on
the back, no ORM. Accounts include argon2id, magic links, OAuth/OIDC and
TOTP; organizations have owner/admin/member roles and row-level tenancy
(non-members get a 404, and a Playwright test proves it cross-tenant);
Stripe covers subscriptions and one-time products with idempotent webhooks,
refunds and chargebacks; email is a durable queue with French and English
templates; the backoffice computes MRR, ARPU and churn from your own tables.
Both PostgreSQL and SQLite are first-class: one migration file, the same
generated queries, both engines in CI. It is commercial (€199 one-time,
perpetual, unlimited projects) and it is a core: a blog, a code generator
and a second payment provider were built and then removed, and
DECISIONS.md
says why.

How to choose

By frontend philosophy. This is the real fork in the Go world. HTMX and
templ (goilerplate, Pagoda) give you one language, no Node in the build,
and pages that are HTML first; the cost is that anything app-like (an
editor, a dashboard with live filters, offline) gets awkward. An SPA
(LastSaaS with React, GoVueKit with Vue) costs a second toolchain and gives
you a typed contract between front and back and a frontend team can work
in. Nobody is wrong here; be honest about what your product's screens look
like in year two.

By database. If you may ever want SQLite in production (single-node
SaaS, on-prem installs, a customer who wants "just a binary and a file"),
only goilerplate and GoVueKit treat it as a target rather than a dev
convenience, and only GoVueKit runs the whole test suite on both. If your
world is PostgreSQL forever, that stops mattering.

By licence. MIT (Pagoda, LastSaaS) means you can fork and never pay, and
also that nobody owes you the next security fix. Commercial with source
delivered (goilerplate paid tier, SaaS Boost Kit, GoVueKit) means you pay
once and own a repository, with updates for as long as the vendor lasts.
Read the restrictions clause: the one that matters is whether client work
is allowed.

By what you must read. Count the lines you will own. A kit is not
"more" when it contains more; it is more when you can hold it in your head.
Ask each vendor for the line count and the migration count; the honest ones
will tell you.

Try before you decide

The fastest way to compare is to run them. Pagoda and LastSaaS clone and
start in minutes. goilerplate's free tier is a GitHub sign-in away. GoVueKit
runs its entire stack from one file, no account, no licence:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d      # app + PostgreSQL + Dex (SSO) + MinIO + stripe-mock + Mailpit

Sign in through SSO, create an organization, invite a teammate, read the
invitation in the inbox, open the backoffice. Then read the code of whichever
kit you liked — that is the only review that counts.

Corrections welcome: if a cell above is wrong about your project, open an
issue on github.com/kOlapsis/govuekit
and it will be fixed with attribution.