Choosing a SaaS boilerplate in 2026: a comparison by architecture

July 22, 2026

Every SaaS boilerplate sells the same list: authentication, teams, payments, an admin panel, emails. The list is not the decision. What you are actually choosing is an architecture and an operating model you will live with for years — and those differ far more than the feature tables suggest.

The market splits into five families. Here is what each one is good at, what it quietly commits you to, and where GoVueKit sits.

The five families

Nobody is wrong in that table. A Rails shop shipping a marketplace with a generated admin will beat a Go team writing handlers by hand. A solo founder who wants a landing page and Stripe live tonight is right to take a Next.js kit on a platform with a free tier.

The question is which trade-offs you want to own.

Trade-off 1: what you operate at 3 a.m.

A compiled backend is one process. It holds sessions in the database, runs the job queue as a table, serves the frontend from its own binary, and terminates when you send it a signal. When something breaks, the search space is one program and one database.

A batteries-included framework in production is usually an app server, a worker, a scheduler, a cache and a database — five things that can be individually down, individually misconfigured, individually upgraded.

A BaaS-based starter is one process on your side and three vendors on the other. Your incident review sometimes ends with "the provider had an incident", which is either a relief or a career-limiting sentence depending on your customers.

None of these is a moral failing. But the number of moving parts is chosen once, at the boilerplate stage, and rarely revisited.

Trade-off 2: where your data lives, and who can move it

Ask the question that matters in month six: if this vendor doubles its price or changes its terms, how long does it take me to leave?

• Postgres behind an ORM: days.
• Postgres behind a vendor's client SDK, with row-level policies written in their dialect and auth living in their tables: weeks, and a data migration you will schedule three times before doing it.
• Auth as a service, once you have users with sessions, MFA enrolments and OAuth links: painful, because you cannot export password hashes from most vendors.

Self-hosting is not a virtue in itself. It is an insurance policy whose premium is that you configure a server. If you sell to European companies who ask where the data sits, that premium is negative — you were going to answer that question anyway. What self-hosting actually buys you goes through the bill line by line.

Trade-off 3: type safety across the wire

Meta-framework kits give you one language across the stack, which is a real advantage: shared types, shared validation, server actions that look like function calls. The price is a Node runtime in production and a build step you do not fully control.

A Go backend with a typed frontend client gives you two type systems that meet at the HTTP boundary. GoVueKit's answer is a typed fetch client and an API that speaks one language (English error codes), with the frontend translating. It is less magical than a server action. It is also legible at 3 a.m., and the boundary is exactly where your tests can sit.

Trade-off 4: what the licence lets you do

Starters are sold in three shapes, and the differences matter more than the price:

• One-time, perpetual: pay once, build unlimited products, keep the code.
• Per-project or per-seat: cheaper to enter, priced by success.
• Subscription for updates: you keep the code you have, but stop receiving fixes when you stop paying.

Read the restriction clause too. Most kits — GoVueKit included — forbid republishing the source as a competing kit while allowing unlimited end products, client work included. That is the clause that decides whether an agency can use it for customer work. Vendors change terms; check the current page before buying, whichever kit you pick.

Trade-off 5: what "tested" means

This is the fastest way to separate a serious kit from a demo.

• Does the repository contain tests you can run in one command?
• Do they run against a real database, or only mocks?
• Is there an end-to-end suite that drives the production build?
• Is CI public, or at least green on the version you receive?

The reason to care is not craftsmanship. It is that a boilerplate is code you did not write and will nevertheless modify. The tests are what tell you whether your change broke tenant isolation. GoVueKit ships 184 Go tests that run on both SQLite and PostgreSQL, 48 frontend unit tests, and 14 Playwright journeys against the real binary — including one that tries to read another tenant's data and expects a 404. Ask any kit for its equivalent.

Where GoVueKit fits

GoVueKit is the compiled-backend answer: Go and Vue 3 compiled into one binary, PostgreSQL or SQLite, no runtime service required. It is a good fit when:

• you know Go, or want the operational shape a single process gives you;
• you sell B2B with organizations and roles (or B2C via ORG_MODE=solo);
• data residency, on-premise delivery or predictable cost matter;
• you would rather read 11,000 lines of ordinary Go than learn a framework's conventions.

It is the wrong choice when your team is JavaScript-only and happy that way, when you need a generated admin over a large domain model, or when you want a managed platform to own auth and database so you can ignore both. Those are real needs, and the families above serve them better.

It is also deliberately a core rather than a catalogue: there is no code generator, no example business module and no second payment provider — those were built, then removed, and DECISIONS.md says why in the entry a buyer should read first. If your shortlist is scored on feature count, another kit wins that column.

A short decision procedure

1. Write down the three things that would hurt most if they went wrong in year two: vendor pricing, data location, hiring, latency, compliance.
2. For each family, ask what it costs to change your mind about that thing.
3. Pick the family whose exit is cheapest for your top risk. Then compare individual kits inside that family, on tests, licence and the quality of the code you can actually see.
4. Read the code before you buy, or at least the parts a vendor publishes. A boilerplate you cannot read is a dependency, not a foundation.

If step 3 lands you on a compiled backend, see what GoVueKit contains — and the buyer checklist works just as well on the competitors.