Go + Vue or a Next.js starter: what changes when the backend is a binary

July 15, 2026

Most SaaS starters sold today are Next.js applications. That is not an accident: one language across the stack, a huge component ecosystem, and a deploy button that works. GoVueKit is the other shape — a Go backend and a Vue 3 frontend that compile into one binary you run yourself.

This post compares the two honestly, including the places where the Next.js kit is the better buy.

The deployment model is the real difference

A Next.js SaaS ships as a Node application, usually onto a platform that builds it, splits it into serverless functions and edge middleware, and bills per invocation or per seat. You can self-host it — next start on a VPS is fine — but most kits assume the platform, and their instructions, environment variables and image optimisation reflect that.

GoVueKit ships as bin/govuekit: a 27 MB file containing the API, the migrations, the embedded Vue build, the transactional email templates and the job queue worker. Deployment is copying it to a server and running it behind a reverse proxy — or docker compose up -d with the provided Traefik stack.

What follows from that:

Neither column is strictly better. The platform buys you "no server to think about" for money and coupling. The binary buys you "one process I fully control" for the cost of learning docker compose and a backup cron.

Type safety: shared types versus a typed boundary

The strongest argument for the JavaScript stack is the shared type system. With a Next.js kit you can call a server action from a component and have TypeScript check both ends. That is genuinely productive, and Go cannot replicate it.

What GoVueKit does instead is make the boundary explicit and typed on both sides: sqlc generates Go types from the SQL, the handlers return small explicit JSON shapes, and the frontend has a typed fetch client that carries the CSRF token and normalises errors. You describe a response twice — once in Go, once in TypeScript. It costs a few minutes per endpoint and it never surprises you at runtime.

There is a second-order effect worth naming: because the boundary is HTTP, the backend is testable without a browser and the frontend is replaceable without touching the backend. Several buyers keep the Go side and rewrite the frontend in whatever their team uses. That is a supported outcome, not a hack.

Ecosystem: where Next.js clearly wins

Be honest about this. The React ecosystem has:

• more prebuilt UI kits, dashboards and component libraries than Vue;
• more copy-paste solutions for niche integrations;
• more people who have already solved your exact problem on a forum.

Vue 3 with Composition API and Tailwind is a comfortable, small, stable surface — but if your differentiator is a complex, highly designed interface and you want to buy components rather than write them, React gives you more to buy. If that is your situation, a Next.js kit is the right call.

Where the Go binary wins

Operational simplicity. One process, one database. No worker fleet, no Redis, no queue service, no build platform. systemd or Docker restarts it.

Predictable cost. The whole product runs on a 4–6 €/month VPS at the beginning and does not become more expensive because you added seats or because a crawler hit an API route ten thousand times.

Latency you control. No cold starts, no per-request function boot, no edge runtime with a different set of available APIs than your local machine.

Compliance answers that fit in one sentence. "It runs on our server in Frankfurt, and the database never leaves it." Nothing to map, no sub-processor list to maintain, no data-processing agreement per vendor.

Data ownership. Your users, sessions, subscriptions and files are rows and bytes on disk you can pg_dump and take elsewhere.

Performance, without the marketing

Both stacks are fast enough for almost every SaaS. The differences that actually show up:

• Memory: a Go binary serving a few hundred requests per second sits in tens of megabytes; a Node process doing the same sits considerably higher. This matters mostly because it decides how small your server can be.
• Startup: the Go binary is serving in milliseconds, which makes blue/green deploys and container restarts boring.
• Frontend delivery: identical in practice — both ship a compiled bundle. GoVueKit serves it from go:embed with immutable cache headers on hashed assets, and one build flag prerenders the public pages to static HTML so crawlers do not have to run JavaScript.

Do not choose a stack on benchmarks you will never reproduce. Choose it on the operating model, then verify the performance you actually need.

Feature-for-feature, in the box

Comparisons between kits are only fair when they are specific. Here is what GoVueKit ships, so you can hold it against whichever Next.js kit you are considering — several of them match parts of this, and few match all of it:

• argon2id passwords, server-side sessions, email verification, reset, magic links, Google/GitHub/Microsoft/OIDC sign-in, TOTP two-factor with recovery codes;
• organizations with owner/admin/member roles, invitations, row-level isolation with 404 for outsiders, and a solo mode for B2C;
• Stripe behind a billing.Provider seam, subscriptions and one-time payments, idempotent webhooks that re-fetch objects by id, refunds and chargebacks handled;
• a durable job queue in the database, 16 transactional templates in FR and EN, delivered through SMTP or Resend with retries;
• an admin console with MRR, ARPU, churn, signups and plan mix computed from your own data;
• file storage on disk or any S3-compatible service — SigV4 over net/http, no AWS SDK — active session revocation, pluggable error reporting;
• 184 Go tests that run on both SQLite and PostgreSQL, 48 frontend unit tests, 14 Playwright journeys against the real production binary.

All of it runs on your own machine on day one: deploy/labs/ starts the app with single sign-on, S3, a Stripe API double and a mail inbox in one command, with no account to create anywhere and nothing to configure.

Choose the Next.js kit when

• your team writes TypeScript and nothing else, and hiring follows that;
• the interface is the product and you want to buy components;
• you want a platform to own deployment and are comfortable with its pricing;
• you need edge rendering or ISR-style caching semantics.

Choose GoVueKit when

• you know Go, or want a single-process backend you can reason about;
• self-hosting, EU residency or on-premise delivery is on the table;
• you want the cost curve flat and the vendor list short;
• you plan to read the code you bought, and keep reading it.

Both answers are defensible. The mistake is picking the architecture by default and discovering the operating model in production.

See what is inside GoVueKit or read the first-hour guide to judge the code before buying.