SaaSCron: Micro SaaS & Founders

Open SaaS and open-source SaaS boilerplates: what you get and what the license allows

2026-10-29T17:00:00-04:00

You have a SaaS idea and a few free evenings, and the first weeks will go to login screens, password resets and a billing page before you write a line of the product itself. A SaaS boilerplate is a starter codebase that ships those parts already wired together. An open-source one lets you start from that code for free, under a license that decides what you owe in return. If the term SaaS is new to you, start with What is SaaS?.

“Open SaaS” means two things in searches. It is the name of one free template, Open SaaS by the team behind the Wasp framework, and it is shorthand for open-source SaaS starters in general. This guide covers both: what a starter contains, the hours it can save, the license question that matters for hosted software and the signs that a starter is still maintained. For the business side of a small, self-funded product, see Bootstrapping a SaaS.

Boilerplates in plain terms

Think of a furnished flat. You move in with the bed, the fridge and the curtains already there, and your first week goes to your own work instead of assembling shelves. The catch is that you live with someone else’s choices until you replace them.

A boilerplate (or starter kit) is that flat for code. Most SaaS starters cover the same parts:

Authentication: sign-up, login, password reset, email verification and social login.
Billing: a checkout, subscription plans and the webhooks a payment provider sends when a customer pays or cancels.
Admin: a dashboard to see users and revenue.
Email and jobs: transactional email and scheduled background tasks.
Deployment: a documented path to put the app online.

Multi-tenancy, one installation serving many customer organizations with their data kept apart, is less common. Check for it before you assume it is there.

What one real starter includes

Open SaaS is published by the wasp-lang organization on GitHub under the MIT license. Its repository describes it as “A 100% free modern JS SaaS boilerplate (React, NodeJS, Prisma)” built on the Wasp framework. As listed in the repository in October 2026:

Part	What the repository lists
Auth	Email, Google, GitHub, Slack and Microsoft login, with email verification
Payments	Stripe, Polar.sh or Lemon Squeezy
Admin	A dashboard built with ShadCN UI
Email	SendGrid, Mailgun or SMTP
Analytics	Plausible or Google Analytics
Files	Uploads to AWS S3
AI	An OpenAI API example that uses function calling
Tests and docs	Playwright end-to-end tests; documentation on Astro Starlight

The list tells you what you do not have to build. It also tells you what you inherit: a framework, a database layer and a set of vendors you did not pick. Swapping the payment provider later is your work, not the template’s.

The license question: MIT vs AGPL

For SaaS, the license matters in a way it does not for most desktop software. Your users never receive a copy of your code. They use it over the network. Two common licenses sit at opposite ends.

MIT is, in the words of choosealicense.com, “a short and simple permissive license with conditions only requiring preservation of copyright and license notices.” You may use the code commercially, change it and keep your changes private. You keep the copyright notice in the code.
AGPL-3.0 is a strong copyleft license. Its condition “network use is distribution” means that if you run a modified version as a service, you must make the complete source of that version available to its users, under the same license. The ordinary GPL does not ask this of software that only runs on a server.

What this means for you: an MIT starter can become your private codebase. An AGPL starter can still be a sound base, but the source of your product must be available to the people who use it.

A third group needs the same care: licenses that publish the source but limit how you use it. n8n’s Sustainable Use License, for example, allows use “only for your own internal business purposes or for non-commercial or personal use.” Read the LICENSE file in the repository, not the landing page, and check the licenses of the main dependencies too.

Example: the hours a starter can save

Example (hypothetical): you estimate the plumbing your SaaS needs before its first real feature, and you price your time at $50 an hour.

Part	Hours from scratch	Hours to adapt a starter
Auth with email verification and one social login	30	6
Subscription billing with webhooks	40	10
Admin dashboard	20	4
Transactional email and deployment	15	5
Total	105	25

Step by step:

Hours saved: 105 - 25 = 80 hours.
Value at $50 an hour: 80 x $50 = $4,000.
At 10 hours a week of evening work, you reach your first real feature 80 / 10 = 8 weeks earlier.
The cost side: suppose you spend 2 hours a month merging upstream updates and fixing what they break. Over 12 months that is 2 x 12 = 24 hours, or 24 x $50 = $1,200.
Net in year one: $4,000 - $1,200 = $2,800 in your favor, plus the 8 weeks.

The hour estimates are illustrative. Replace them with your own; the shape of the sum is the point. A starter saves the most when you would otherwise build every part yourself, and the least when you plan to rip out half of it.

How to tell whether a starter is maintained

A free starter that nobody updates turns into security debt, because it bundles auth and payment code. Before you build on one, check:

Last commit and last release dates. Months of silence on a project that depends on auth and payment libraries is a warning.
Open issues and replies. Read the oldest open issues and see whether maintainers answer.
Dependency freshness. Compare the versions in the package manifest with the current releases of the framework and the payment SDK.
Upgrade notes. A changelog or migration guide shows how painful the next version will be.
Who funds it. A starter backed by a framework company has a reason to keep it alive. A weekend project may not.

Stars measure popularity, not upkeep. A popular repository can still be abandoned.

Starter, scratch or paid kit

Your situation	Reasonable choice
Testing an idea fast on a common web stack	An open-source starter under MIT
You need something starters lack, such as strict tenant isolation	Build the core yourself and borrow pieces
You want support and one accountable maintainer	A paid starter kit, after reading its license
You plan to resell the software under other companies’ brands	Check the starter’s license first; see White-label SaaS

Common mistakes

Reading the README instead of the license. “Free” on a landing page can sit next to an AGPL or a non-commercial license. Why it happens: the README is friendlier. Instead: open the LICENSE file, and the licenses of the major dependencies, before your first commit.
Keeping every integration because it came in the box. Three email providers and two analytics tools mean more keys, more updates and more ways to break. Why it happens: deleting code feels like throwing value away. Instead: remove what you do not use in the first week.
Never pulling upstream fixes. Your copy drifts, and a security patch to the auth code never reaches you. Why it happens: merging is tedious once you have edited the same files. Instead: keep your changes in separate files where you can, and schedule a monthly merge.
Assuming multi-tenancy. Many starters treat each user as a customer, not each organization, and adding team accounts later touches every table. Why it happens: the demo works fine for one user. Instead: decide on day one whether your customers are people or companies.

For how to price the product once it runs, see SaaS pricing models.

Sources

wasp-lang, Open SaaS repository, checked October 2026.
choosealicense.com, MIT License and GNU AGPLv3, checked October 2026.
n8n, Sustainable Use License, checked October 2026.

In three sentences

An open-source SaaS boilerplate gives you auth, billing, admin and deployment already wired, so your first weeks go to the product instead of plumbing. In the worked example, adapting a starter saves 80 hours, worth $4,000 at $50 an hour, against about 24 hours of upkeep in the first year. Read the license before the README, because MIT lets you keep your code private while AGPL requires you to share the source of a modified version you run as a service.

Bootstrapping a SaaS: from idea to first paying customers without funding

2026-10-24T17:00:00-04:00

You have an idea for a software product, some savings or a day job, and no wish to spend a year pitching investors. You want to know whether you can build a SaaS business on customer money alone, and what has to happen between the idea and the first invoice. Bootstrapping a SaaS means funding it from your own resources and then from revenue, which puts one goal above all others: paying customers, early.

That goal changes the order of work. You validate before you build, you charge before the product feels finished, and you pick a target small enough to reach. This guide sets out the steps, two public cases, the arithmetic of a first revenue target and a checklist for the weeks before you write code. For the basics of the model, see What is SaaS?.

Bootstrapping in plain terms

Think of it like opening a food stall instead of a restaurant. A restaurant needs a lease, a kitchen and staff before the first plate is sold, so it needs a loan or an investor. A stall needs a cart and one good dish. You learn what sells from the first day’s queue, and you buy the second cart with the first cart’s takings.

A bootstrapped SaaS is the stall. Revenue, not outside capital, pays for the next step. The price is speed: you grow only as fast as customers pay. The benefit is ownership and freedom: no investor sets your targets or your exit. A micro SaaS, a small SaaS business often run by one person or a small team, is a common bootstrapped shape.

Two public cases

Founder stories are easy to find and hard to check. The two below rest on what the companies state on their own pages.

Plausible Analytics. The company’s about page says Uku Taht started Plausible in December 2018. It describes the company as “self-funded and profitable, with no outside investors and no plans to sell”. It reports that Plausible “crossed $1 million in annual recurring revenue in 2022”, that more than 21,000 paying subscribers use it, and that it is “a team of 10” (Plausible, About). Its home page lists the Starter plan from $9 a month, a 30-day free trial with no credit card, and “2 months free” on yearly billing (Plausible, as of October 2026).

Zoho. Zoho is far larger, and its about page makes the same core claim: the company has never taken money from investors. The page also records that Zoho passed 100 million users in 2023 (Zoho company page).

The two cases differ in size by orders of magnitude, but they share the claim that matters here: neither company depended on investors to pay for growth. Plausible adds a pattern you can copy on day one: a product people can try and buy on their own, at a published price.

The steps, in order

Pick a problem you can reach. Choose a group of buyers you can contact directly: an industry you know, a community you belong to, a tool you use daily. If you cannot name 50 potential buyers, the problem is too abstract for a first product.
Validate with commitments, not compliments. Interview potential buyers about how they solve the problem today and what it costs them. A pre-order, a paid pilot or a signed letter of intent is evidence. A polite “sounds useful” is not.
Build the smallest product that solves one task. One workflow, done well, for the buyers you interviewed. Everything else goes on a list for later.
Charge from day one. A free trial is fine; a free product with no price is not a test of demand. Publish the price, even if you change it later. For the main ways to structure it, see SaaS pricing models.
Use channels that cost time, not money. Direct outreach, the communities you already belong to, content that answers your buyers’ questions, and integration marketplaces. Low-touch selling can work at scale: Atlassian’s 2015 IPO filing stated that it had no direct sales force and relied on “word-of-mouth and low-touch demand generation” (Atlassian Form F-1).
Decide when to stay small. A product that pays one or two people well is a finished business, not a failed startup. Reselling an existing product under your brand is another low-capital route, described in white-label SaaS.

Worked example: the arithmetic of a first target

Example: a labeled hypothetical. You set a first target of $5,000 in monthly recurring revenue (MRR). You assume 20% of free trials convert to paid, and 3% of paying customers cancel each month (monthly logo churn). Both assumptions are yours to replace with real data once you have it.

Price per month	Customers for $5,000 MRR	Trials needed at 20%	Customers lost per month at 3%	New trials per month to stay level
$9	5,000 / 9 = 555.6, so 556	556 / 0.2 = 2,780	556 x 3% = 16.7, so 17	17 / 0.2 = 85
$29	5,000 / 29 = 172.4, so 173	173 / 0.2 = 865	173 x 3% = 5.2, so 6	6 / 0.2 = 30
$99	5,000 / 99 = 50.5, so 51	51 / 0.2 = 255	51 x 3% = 1.5, so 2	2 / 0.2 = 10

Customer counts and losses are rounded up, because you cannot win part of a customer.

Read the last column. At $9, you need 85 new trials every month just to stand still. At $99, you need 10. A cheap product needs a large audience; an expensive one needs a buyer with a budget and a problem worth $99 a month. Pick the row your channels can feed. For what each customer is worth over time, see LTV in SaaS.

Yearly billing. Plausible’s “2 months free” offer shows the trade. At $9 a month, a year costs 12 x $9 = $108 on monthly billing and 10 x $9 = $90 on yearly billing. You give up $18, a 16.7% discount, and receive 12 months of cash on the first day. For a bootstrapped company, cash up front pays for the next month of work.

Checklist

Before you write code:

Write the problem in one sentence, in the words a buyer used in an interview.
List 50 potential buyers you can reach directly, by name or community.
Hold at least 10 interviews about how they solve the problem today.
Get at least one commitment that costs the buyer something: money, a signed pilot or their data.
Choose the one workflow your first version will do, and write down what it will not do.
Set a public price and a first MRR target, and run the arithmetic in the table above.
Decide the two channels you will use in the first three months.
Calculate how many months your savings or salary can cover before revenue must.

Common mistakes

Building for months before talking to buyers. The product solves a problem nobody pays to solve. Why it happens: building feels like progress, interviews feel awkward. Instead: interview first and collect a commitment before the first line of code.
Pricing too low to be sustainable. As the table shows, a $9 product needs 85 new trials a month to stay level at $5,000 MRR. Why it happens: a low price feels safer. Instead: price for the buyer with the problem, and test a higher price early.
Copying the playbook of funded startups. Paid ads and a sales team burn cash a bootstrapped company does not have. Why it happens: many widely shared startup stories are about funded companies. Instead: use channels that cost time, and spend money only where a channel already works.
Treating unverified founder stories as benchmarks. Revenue screenshots and growth threads are hard to check. Why it happens: they are everywhere. Instead: rely on what companies state on their own pages or in filings, as in the cases above, and on your own numbers.

Sources

Plausible Analytics, About and home page pricing, checked October 2026.
Zoho, company page, checked October 2026.
Atlassian Corporation Plc, Form F-1, filed November 9, 2015.

In three sentences

Bootstrapping a SaaS means funding it yourself and then from revenue, so validation, a published price and paying customers come before a polished product. In the example, $5,000 of MRR takes 556 customers at $9 a month or 51 at $99, and at 3% churn the $9 plan needs 85 new trials a month. Plausible and Zoho show on their own pages that companies can grow without investors, but your target, price and channels must fit the audience you can reach.

White-label SaaS: how it works, margins and risks

2026-10-17T07:00:00-04:00

You run a small agency or consultancy, and a software vendor offers to let you sell its product to your clients under your own name, logo and price. It sounds like a software business without writing software, and you want to know what the catch is. White-label SaaS means exactly that: the vendor builds and hosts the software, and you rebrand and resell it. Your margin is the gap between what your clients pay you and what you pay the vendor plus your own costs.

The model can be a sound way into recurring revenue for a small team. It also puts your brand on a product whose roadmap, uptime and prices you do not control. This guide covers how it works, a margin calculation with a published platform price and the contract terms that protect you. For the basic idea of SaaS, see What is SaaS?.

White-label in plain terms

Think of a supermarket’s own-brand cereal. The supermarket did not build a cereal factory. A manufacturer makes it, the supermarket designs the box, sets the price and takes the complaints. If the manufacturer changes the recipe or raises its price, the supermarket finds out with everyone else.

White-label SaaS has three parties:

The provider: builds, hosts and maintains the software, and sells it wholesale.
The reseller (you): puts your brand on it, usually your own domain, logo and colors, sets the client price and owns the client relationship.
The client: uses the product and pays you, often without knowing who built it.

What you control is the brand, the price, the onboarding and the first line of support. What you do not control is the code, the hosting, the release schedule and the provider’s own price to you.

How the money works

Your costs come in two shapes. A platform fee is what the provider charges you, often a flat monthly amount, sometimes per client account. Your own costs are the time you spend on onboarding and support for each client. Many platforms also pass through usage costs, such as text messages or emails sent, which you can mark up or bill at cost.

Because the platform fee is mostly fixed and your price is per client, the margin grows with each client you add. That is the same logic as any SaaS business model, with one difference: your gross margin depends on a supplier’s price list.

Worked example: margin at 10, 25 and 50 clients

HighLevel, a marketing software platform that agencies resell, publishes its plans on its pricing page (as of October 2026). Its Agency Pro plan costs $497 a month and adds “SaaS mode”, automated sub-account creation and rebilling of phone and email usage with a markup. The plan price is published; the client price and support cost below are assumptions for illustration.

Example: you charge each client $150 a month. Your support and onboarding time averages $20 per client per month. Usage costs are rebilled to clients and left out of the margin.

Clients	Revenue	Platform fee	Your support cost	Margin	Margin %
10	10 x $150 = $1,500	$497	10 x $20 = $200	$803	53.5%
25	25 x $150 = $3,750	$497	25 x $20 = $500	$2,753	73.4%
50	50 x $150 = $7,500	$497	50 x $20 = $1,000	$6,003	80.0%

Margin is revenue minus platform fee minus support cost. At 10 clients: $1,500 - $497 - $200 = $803, and $803 / $1,500 = 53.5%.

Break-even comes early. Each client contributes $150 - $20 = $130 a month toward the fixed fee, so $497 / $130 = 3.8 clients. The fourth client puts you in profit.

Now the risk in the same table. If the provider raises its fee by $200 a month, your margin at 10 clients drops from $803 to $603, a quarter of your profit, with no change on your side. At 50 clients the same increase costs you 3% of profit. White-label is safest at a scale where the platform fee is a small share of revenue.

The risks you take on

Your brand, their uptime. When the provider has an outage, your clients call you. You cannot fix it, and you may not even see the cause.
Price changes. The provider can raise its wholesale price at renewal, as in the example above.
Roadmap. Features arrive or disappear on the provider’s schedule. A feature your clients rely on can be removed.
Data and exit. Your clients’ data sits with the provider. If you leave, or the provider closes, you need a way to move it.
Channel conflict. Some providers also sell directly. Your client can find the same product cheaper under its original name.
Support load. Every question about the software comes to you first, so your support cost per client is the number that decides your margin.

For how to set your own client prices, per client, per seat or by tier, see SaaS pricing models.

Checklist for the contract

How much notice the provider gives before a price change, and whether your price is fixed for the contract term.
What exactly can be white-labeled: domain, login page, emails sent to clients, mobile app, help center.
The provider’s uptime commitment and the credits you receive when it misses, in writing.
Who owns client data, and how you export it, in what format and how fast, if you leave.
What happens to your clients if the provider is acquired, shuts down or ends the white-label program.
Whether the provider may sell directly to your clients, and any non-solicitation clause.
The list of sub-processors that handle your clients’ data, for your own privacy obligations.
How usage costs are billed, and whether you can set the markup.
The termination notice on both sides, and whether you can leave mid-term.

Common mistakes

Pricing from the platform fee and forgetting support. Support time is your largest variable cost. Why it happens: the platform fee is the only number on the provider’s page. Instead: track support hours per client for the first three months and put the real number in your margin table.
Promising clients what the provider controls. Uptime, features and data location are the provider’s decisions. Why it happens: the product carries your brand, so it feels like yours. Instead: pass through only the commitments the provider makes to you, in writing.
Starting without an exit plan. Moving 30 clients to another platform is a project, not a weekend. Why it happens: exit feels far away when you sign. Instead: test a data export before your first client goes live.
Staying at a scale where a price change hurts. At 10 clients, a $200 increase removes a quarter of your profit. Why it happens: the first clients feel like success. Instead: plan for enough clients that the platform fee is a small share of revenue, or negotiate a fixed price for the term.

Sources

HighLevel, Pricing, checked October 2026.

In three sentences

White-label SaaS lets you sell a provider’s hosted software under your own brand and price, while the provider builds, hosts and updates it. With a $497 monthly platform fee, $150 per client and $20 of support per client, the margin rises from 53.5% at 10 clients to 80.0% at 50, and break-even comes at the fourth client. Before you sign, get price-change notice, data export, uptime commitments and the provider’s direct-sales rules in writing, because your brand carries the risk.