The economics of open-source SaaS: how FormTo makes money while giving the code away

April 5, 2026 · 8 min read

Abstract pattern — the economics of open-source SaaS

Every time I tell someone FormTo is open source under AGPL with the full code on GitHub, the very next question is some version of: "but how do you make money?"

It's a fair question, and I like it because it forces me to think clearly about the business instead of hiding behind vibes. This post is the honest answer. No funnel diagrams, no "land and expand" corporate speak, no slides with the word "leverage" on them. Just what the model is, why it works, why it could fail, and what that means for you as a user.

If you're here because you're thinking about open-sourcing your own SaaS, hopefully this is also useful as a case study.

The model, in one paragraph

FormTo has two products that share the exact same code. The open-source version is self-hosted — you run it on your own server, you own all the data, and you pay nothing to us. The cloud version is hosted by us on our infrastructure, with a managed edge network, aggregated spam reputation, and a paid support story. Both versions are the same software. The difference is who operates the server.

Self-hosters don't pay. Cloud users do. The cloud revenue funds the development of the software, which flows back to the self-hosters for free. That's the whole model.

It's unsexy. It works.

Why this isn't as crazy as it sounds

The standard SaaS instinct is "if people can get it for free, they won't pay." That instinct is correct for some kinds of products. It is dramatically wrong for others, and a form backend falls into the second category for a simple reason: most people do not want to run a server.

I've watched developers look at FormTo, fully read and understand that the AGPL version is free, genuinely intend to self-host, and then three weeks later sign up for the $9/month cloud plan anyway. Not because they were tricked. Because when they actually looked at their Sunday afternoon and thought about setting up backups, rotating TLS certificates, monitoring uptime, and handling the inevitable 2 a.m. Postgres hiccup, they decided $9 a month was worth it. That's the whole market.

This isn't cynicism. It's a real division of labor. People who love running infrastructure self-host (and genuinely enjoy it). People who would rather spend their time on their actual business pay for cloud. Both groups get the same software. Nobody feels ripped off.

The ingredient list

Let me break down what we're actually charging for on the cloud side, because "$9/month for a form backend" sounds abstract until you itemize it.

Cloud cost line Monthly share of $9
Infrastructure (servers, DB, bandwidth, object storage) ~$1.50
Email delivery (transactional, sending-domain reputation) ~$0.50
Monitoring, alerting, on-call tools ~$0.30
Security scanning, DDoS protection at the edge ~$0.40
Backups (cross-region, point-in-time recovery) ~$0.20
Payment processing fees (Stripe) ~$0.60
Support inbox / time handling tickets ~$1.50
Software development (amortised across all users) ~$2.00
Taxes, accounting, legal, compliance ~$1.00
Margin (for sustainability and growth) ~$1.00
Total ~$9.00

These numbers are rough, not audited. They're more illustrative than precise. But the shape is accurate: a $9 subscription isn't mostly "profit" — it's mostly operational costs, with a small margin for reinvestment. The cloud version is not charging a premium for the software. It's charging for the infrastructure and the people who run it.

When you self-host, you are signing up to pay those costs yourself, in money (VPS, bandwidth, backups, your own time) rather than in subscription fees. That's the actual trade. It's not "free vs paid." It's "your time and infrastructure vs our time and infrastructure." Sometimes yours is cheaper. Sometimes ours is. It depends on you.

Why AGPL specifically helps the model

I explained the license choice in more detail in the "why we open-sourced FormTo" post. Here's the business-specific version.

MIT would let a better-funded competitor fork FormTo, rebrand it, run it as a hosted service, and keep their improvements closed. That company wouldn't owe us anything, not even a credit line. In theory we could "outcompete them on product velocity," which is what people always say when they're arguing for MIT. In practice, a well-capitalized fork with better sales reach can win even while the original project makes better software. I've watched this happen to other OSS-SaaS companies.

AGPL closes that door without hurting legitimate users. If you run FormTo for yourself, nothing in the license triggers. If you fork FormTo and run it as a public commercial service, you have to release your changes under the same license, which means anyone can take your fork and run it themselves, which destroys the moat the fork was trying to build.

It's not a perfect legal barrier — nothing is — but it raises the bar enough that the business case for forking FormTo as a commercial competitor becomes weak. And that's all we need. We're not trying to prevent every theoretical competitor. We're trying to prevent the specific failure mode where a big player vacuums up our work and gives nothing back.

The "four revenue streams" thing

Some OSS-SaaS companies have three or four revenue streams: cloud, enterprise licenses, support contracts, hosted training. That's fine if it works. FormTo, for now, has basically one:

  1. The hosted cloud product, with monthly and annual tiers.

That's it. No paid support plans. No enterprise license that unlocks secret features. No dual-licensing scheme where companies can buy a non-AGPL version. We looked at all of those and rejected each of them for different reasons:

  • Paid support plans distract from the cloud product and create a second sales motion. For a small team, we'd rather do one thing well.
  • Enterprise licenses make sense for projects where big companies need compliance checkboxes, but for our category, self-hosting under AGPL already covers almost every compliance need.
  • Dual licensing — where we'd sell a commercial license to companies that can't use AGPL — is a fine model, but it creates adverse incentives (you subtly benefit from making AGPL harder to use). We'd rather make AGPL easy and keep everyone honest.

Maybe we add something later. Maybe we don't. One revenue stream is enough if the stream is healthy, and "$9 × a lot of customers" scales fine if you don't get greedy.

The failure modes

I want to be honest about how this could go wrong, because every OSS-SaaS post I've ever read glosses over the risks.

1. A fork competes with us anyway. AGPL doesn't stop forks. It requires them to release their changes. Someone could still fork FormTo, add features, comply with the license, and compete with our cloud product on the hosted side. If they do it well enough, they might take market share from us.

Mitigation: stay the fastest team on the upstream repo, and keep the cloud product's operational story strong. The fork has to beat us on operations, which is harder than it sounds because operational excellence is accumulated over years.

2. Self-hosting becomes so good that almost nobody pays for cloud. This would be a strange failure because it would mean we built the software really well. But it is theoretically possible that improvements to self-hosting (better Docker images, better auto-updates, better backup tooling) reduce the friction enough that the cloud convenience isn't worth $9/month to most users.

Mitigation: the cloud product has structural advantages that self-hosting can't match — global edge network, aggregate spam reputation, 24/7 on-call, automatic DR across regions. Those get better over time as we scale, and they do not replicate on a single-server self-hosted install.

3. The cloud product can't reach sustainable revenue. If we can't get enough cloud customers, the open-source version is the only thing keeping the project alive, and we can't fund development on nothing. The project would slow down, release cadence would suffer, and users would eventually move to something actively maintained.

Mitigation: honestly, this one is just "run the business well." There's no clever trick. We need enough paying cloud customers to sustain development, and we have to earn them by making the cloud product good enough that paying is an obvious choice.

4. AGPL scares off corporate users anyway. Despite my earlier argument that AGPL concerns are usually mythology, some enterprise legal teams genuinely have allergies to it. Those companies won't use FormTo even though they could, and we lose them.

Mitigation: I don't think this is a huge loss — those companies are usually a terrible fit for a $9/month SaaS anyway. But we do lose some deals to it, and I want to acknowledge that the license choice has real costs even when I defend it.

What "open source" is not

A few things I want to clarify because the word "open source" gets used for a lot of different things these days.

We're not open-core. In open-core, the free version is deliberately crippled and the paid version has features held back. We don't do that. Every feature in the cloud product is in the AGPL repo. If you self-host, you get the same software.

We're not source-available. Source-available licenses let you read the code but restrict what you can do with it. BSL and ELv2 are the most common examples. They're fine licenses for what they are, but they're not OSI-approved open source. FormTo's AGPL-3.0 license is fully open source under the OSI definition, and we intend to keep it that way.

We're not abandonware-in-waiting. Some OSS projects are open source technically but haven't shipped a meaningful release in two years. That's a legitimate concern and I take it seriously. The best answer is the release history itself — check the commit log and see for yourself how actively we're shipping.

What this means for you

If you're a self-hoster, the practical implication is: keep using the AGPL version, don't feel guilty about not paying, and know that the cloud customers are funding the development that benefits you. The model assumes you're here and welcomes you.

If you're a cloud customer, the practical implication is: the $9/month isn't just paying for the infrastructure. It's keeping the open-source project alive. You're not "subsidizing" the self-hosters — you're paying for a service you want, and a side effect is that a useful open-source project exists because of your subscription. That's a better relationship than most SaaS.

If you're thinking about open-sourcing your own SaaS, the practical implication is: the model can work, AGPL is a serious choice worth considering, and the economics depend on whether the cloud side has structural operational advantages that self-hosting can't match. If it doesn't, don't open-source. If it does, the free version can be an asset instead of a threat.

The thing I come back to

Here's the feeling I want to leave you with.

Most software exists at the end of a chain of business decisions that nobody outside the company can see. You use the product, you pay for it, you hope the people running it are making good choices, and you have no recourse if they aren't.

Open-source SaaS — the real kind, not the "source-available with a contract" kind — breaks that chain a little. You can read the code. You can fork it if we stop maintaining it. You can move your data. You can argue with us in public issues on GitHub. The relationship is more symmetrical than the usual vendor dynamic.

I don't think that's morally superior or anything grand. I think it's a better way to build trust, and trust is the most important resource a form backend has, because you're asking it to handle every stranger who wants to contact your business. The economics of this model are just the mechanism that lets the trust exist.

If you've read this far, you probably already care about the same things I care about. Thank you. That's actually what makes the model work — users who care enough to understand the tradeoffs are the users who make good decisions about which version to run, and good decisions at scale add up to a sustainable project.


The repo: github.com/lumizone/formto (star it if you like the direction).

If you're picking between the two versions, FormTo Cloud vs self-hosted breaks it down. If you want to try self-hosted first, the complete self-hosting guide or the Hetzner VPS walkthrough will get you running in about 15 minutes. If you'd rather skip to the cloud, pricing is here.

← All posts