The rented stack: what a BaaS-based starter really commits you to

July 8, 2026

A starter built on managed services gets you to a working product fast. That is a real benefit, and this post is not going to pretend otherwise. But the speed is bought with commitments that are invisible on day one and very visible in year two.

Here is the full ledger, including the cases where renting wins.

The four bills

1. The monthly bill. Platform hosting, database, auth, object storage, email, queue, error tracking. Each is modest alone. Together they are the kind of number founders discover when they finally read the invoice: the auth vendor's free tier ends at a few thousand monthly active users, the database service charges for compute you cannot turn off, and the platform bills seats for team members who only need to read logs.

2. The coupling bill. Vendor-specific code is code you cannot take with you: row-level security written in one vendor's dialect, auth tables you do not own, storage URLs baked into your frontend, functions written against a runtime that only exists there. None of it is wasted work — it is just work you will redo if you leave.

3. The compliance bill. Every processor is a line in your GDPR register, a data-processing agreement to sign, a sub-processor list to keep current, and an answer you owe to every enterprise buyer's security questionnaire. Five vendors is five of each.

4. The dependency bill. Their incident is your incident. Their price change is your board meeting. Their deprecation is your sprint.

What the self-hosted alternative actually costs

Being fair means quoting the other side properly. Self-hosting is not free:

• a server to configure, patch and monitor;
• backups you must set up and restore at least once, because an untested backup is a hope;
• TLS certificates (automated, but yours to notice when they fail);
• an on-call reality where nobody else gets paged.

GoVueKit's answer is to make that list as short as it can be: the app is one binary, sessions and the job queue live in the database, files can stay on disk, and docker-compose.prod.yml puts the app behind Traefik with Let's Encrypt — the reference Traefik stack ships in deploy/traefik/ — so the certificate part is automatic. The deployment guide is a handful of commands long. What remains is genuinely your job: backups, monitoring and updates.

Concretely, the required list is: a server, a domain. Everything else — PostgreSQL instead of SQLite, S3-compatible storage, an email relay, a payment provider, an error reporter — is optional and swappable, and the kit boots without any of it.

The exit test

Before you commit to any starter, run this thought experiment for each vendor in its stack:

The vendor triples its price, or is acquired, or changes its terms for companies my size. What do I do that week?

Score the answer, honestly:

The last two are the ones that decide architecture. They are also the ones the feature comparison table never mentions.

Where renting genuinely wins

Do not read this as an argument for building everything yourself. Renting is the right answer when:

• You are validating. If the product might not exist in three months, the fastest path to a paying user beats every architectural consideration.
• The service is genuinely hard. Payment processing, email delivery reputation, fraud scoring, video transcoding. GoVueKit rents these too: it uses Stripe for payments and Resend or an SMTP relay for delivery, because building either would be malpractice.
• You have no operations capacity at all and no intention of acquiring any. A single founder with no infrastructure background will ship faster on a platform, and that is a legitimate trade.
• Elastic load is your normal. If your traffic swings by two orders of magnitude on a schedule, per-request pricing may genuinely be cheaper than provisioned capacity.

The distinction worth holding: rent capabilities that are hard and replaceable behind an interface. Avoid renting your data model, your users and your runtime, because those are the parts you cannot swap.

That is why GoVueKit puts every outbound integration behind a small seam — billing.Provider, email.Mailer, storage.Storage, the error reporter — and keeps users, organizations, sessions, subscriptions and jobs in your own database. Stripe is the one payment implementation that ships; the seam is what you write against if you ever need another.

The EU angle, without the flag-waving

If you sell to European companies, self-hosting answers three questions at once: where the data is, who processes it, and what happens if the answer must change. Host in Frankfurt, Paris or Amsterdam and the answer is "our server, nobody else, and we can move it".

That is not compliance in itself — you still need a privacy policy, a register, and the ability to export and erase a user's data. GoVueKit ships the last part as product features (GDPR export and account erasure, audit log for administrative actions) precisely because they are tedious to retrofit.

A practical middle path

You do not have to choose ideologically. A reasonable sequence:

1. Start self-hosted on one server with SQLite. It costs the price of a coffee per month and has no vendor in it.
2. Move to PostgreSQL when concurrent writes justify it — one environment variable in GoVueKit, same SQL either way.
3. Add S3-compatible storage when files outgrow the disk or you want two app instances.
4. Rent the genuinely hard things — payments, email delivery — from day one, behind the interfaces that already exist.

You end up with a stack where every rented piece is replaceable in an afternoon, and nothing rented owns your users.

See the dependency ledger on the product page, or read how the boilerplate families compare.