SaaSWorks · Wave 1
Run the whole SaaS, not just build it.
SaaSWorks is a planned end-to-end platform for running a software business: the application foundation, then the revenue, support and growth machinery every SaaS rebuilds — dunning and recovery, ticketing, partner programmes and growth tooling in one place.
- Build
- Monetise
- Recover
- Support
- Grow
- Stage
- Planned
- Portfolio bay
- Bay 06
- Focus area
- AI & Software Engineering
- Part of
- The Collective Foundry
The problem
Why SaaSWorks exists.
A software business is mostly machinery that is identical everywhere: sign-in, organisations and roles, subscriptions, failed-payment recovery, support, referrals, lifecycle messaging, reporting. None of it differentiates anything, every team rebuilds it, and the parts that get deferred — dunning, attribution, usage intelligence — are the ones that quietly cost the most revenue.
Who it's for
Founders, product teams and software agencies running multi-tenant SaaS who want the undifferentiated machinery — build, billing, support and growth — solved once rather than rebuilt per product.
The opportunity
The market SaaSWorks is built for.
The categories SaaSWorks spans are established and separately large — application development, subscription management and revenue recovery, customer support, partner marketing and SaaS analytics. They overlap heavily and are shown separately rather than added together. Starter kits (Makerkit, supastarter, SaaS Pegasus) solve the first slice and stop; Chargebee and Paddle own billing; Intercom and Zendesk own support; PartnerStack and Rewardful own affiliates. The thesis is not beating any one of them at its specialism, but that a software business should not have to assemble five systems before its first customer.
The numbers
What the category is worth.
-
Low-code development platforms
$31.6B (2026) → $78.9B (2031)
20.1% CAGR
Source: Mordor Intelligence
A proxy for demand, not a market SaaSWorks could capture. Publishers disagree widely: 2026 bases run $26B to $66B and growth 20% to 32%, and Mordor’s own page carries two different 2026 figures.
Why now
The timing behind it.
- 01
Failed payments are one of the largest recoverable revenue leaks in subscription software, and dunning is still something most teams add late or never.
- 02
Billing, identity, messaging and support have matured into composable services, so the machinery is assembly rather than invention — but assembling it is still months of nobody’s differentiating work.
- 03
A foundry building many SaaS products amortises that machinery across all of them, which is the only reason building it is rational at all.
What it does
The capabilities inside SaaSWorks.
The application foundation
Authentication, multiple organisations, fine-grained roles and workspace administration, wired together rather than assembled.
Billing that collects
Subscriptions, usage and invoicing — plus the dunning and recovery flows that decide how much of it is actually collected.
Support in the same system
Ticketing and customer conversations against the same accounts and entitlements, instead of a separate help desk guessing at them.
Partners and affiliates
Referral and affiliate programmes, attribution and payouts — a growth channel most teams bolt on late or never.
Growth tooling
Lifecycle messaging, campaigns and the funnel instrumentation that shows which of it worked.
Intelligence on launch
Revenue, retention and product-usage reporting present from day one, not a later integration project.
Where we start
The smallest valuable first step.
- Who it is for first
- Founders and small teams launching a multi-tenant SaaS
- The first thing it does
- The application foundation plus billing that actually collects - subscriptions with dunning and recovery wired in from the start.
- Likely commercial model
- Per workspace, with usage-based billing above a threshold
- What has to be proven
- That a team will trust a foundation they did not write with their billing.
What makes it innovative
Why SaaSWorks is different.
Past the foundation
Starter kits end at auth and billing. The revenue, support and growth machinery is where the remaining months go, and that is the scope here.
Security as a default
Hardened defaults are part of the starting point rather than a pre-launch scramble.
Proven before it is offered
Designed against real products with real customers, so it arrives tested rather than theoretical.
The usual way
Five systems assembled per product — a starter kit, a billing provider, a help desk, an affiliate tool, an analytics stack — each with its own customer record.
The foundry way
One operating surface where billing, support and product already read the same customer, so the first commit is about the actual product.
How it compares
SaaSWorks against the starter kits, AI builders and billing platforms a team assembles a SaaS business out of today.
Every competitor cell below is drawn from that vendor's own official site on the date shown. Where a capability was not documented there, it is marked Not publicly verified rather than Not available — absence of evidence is not evidence of absence.
| Capability | SaaSWorks Not built — scoped for Wave 1 | Makerkit Pro licence, one-time, one developer | SaaS Pegasus Professional tier, one-time (teams and Stripe subscriptions are not in Starter) | Lovable Paid plan (built-in payments and custom domains require one) | Chargebee Chargebee Billing with RevenueStory, subscription pricing |
|---|---|---|---|---|---|
| Standing it up Authentication, organisations and fine-grained roles The part everyone rebuilds first. Also the part this category has genuinely solved, which is why it is cheap to match and not worth winning. | Planned Depth 0/5 · target 5/5 The one row where the category is genuinely solved. Matching the established starter kits here is the baseline, not the differentiator. | Advanced Shipped Depth 5/5 Personal, team or hybrid accounts, custom per-tenant roles, invitations, MFA and passkeys; Supabase kits isolate tenants with Postgres row-level security | Included Shipped Depth 4/5 Teams with admin and member roles, invitations, user impersonation; per-team isolation by foreign key in one database. Teams need the Professional tier | Included Shipped Depth 3/5 Prebuilt authentication flows added from a prompt on a Supabase foundation; organisations and roles are whatever the generated schema contains rather than a designed tenancy model | Limited Shipped Depth 1/5 Holds customer and subscription records, not your application’s sign-in, organisations or roles. Not an application platform |
| Standing it up Deployment, hosting and ownership of the code Decides how much of the business you still control. A platform that absorbs billing and support has to answer this before anything else. | Planned Depth 0/5 · target 4/5 Source-code ownership and data export as defaults rather than concessions — the stated answer to the switching cost this venture creates for its own customers. Below Makerkit, which is nothing but code you own. | Advanced Shipped Depth 5/5 Source code you own and host anywhere; one-time licence with lifetime updates and unlimited projects | Advanced Shipped Depth 5/5 Generates a Django codebase you own outright, deployed wherever you choose; one-time purchase | Included Shipped Depth 4/5 Free publishing to a lovable.app URL with HTTPS, custom domains on paid plans, autoscaling hosting and a resizable database | Limited Shipped Depth 1/5 A hosted service: there is no application code to own and nothing to deploy |
| Getting paid, and keeping it Subscriptions, usage and invoicing Table stakes everywhere, and deeper than it looks once tax, proration and usage aggregation arrive. | Planned Depth 0/5 · target 4/5 Deliberately short of Chargebee. 480+ documented invoicing scenarios plus tax compliance is a decade of edge cases, and claiming parity would discredit the rest of this table. | Included Shipped Depth 4/5 Flat, per-seat and metered Stripe subscriptions, one-off payments, customer portal and webhooks, behind a provider gateway that also covers Paddle and Lemon Squeezy | Included Shipped Depth 4/5 Stripe pricing tables, webhooks for upgrades, downgrades and cancellations, customer portal, per-seat and per-unit models, plan-based feature gating | Included Shipped Depth 3/5 Built-in Stripe or Paddle checkout through edge functions with secrets kept out of the code. Built-in payments need a paid plan, and the two providers cannot run in one project | Advanced Shipped Depth 5/5 The reference point: catalog and pricing configuration, 480+ invoicing scenarios, usage aggregation, entitlement provisioning and tax compliance across 40+ gateways |
| Getting paid, and keeping it Failed-payment recovery and dunning One of the largest recoverable revenue leaks in subscription software, and the thing teams defer longest. | Planned Depth 0/5 · target 4/5 The stated wedge, and the row where every starter kit scores at or near zero. Still 4/5: Chargebee’s retry logic responds to the gateway’s failure reason, and matching that needs payment volume we would not have. | Not publicly verified Depth 1/5 Webhooks keep plans and seat counts in sync; a failed-payment recovery or dunning flow is not documented as included | Not publicly verified Depth 1/5 Subscription lifecycle webhooks are documented; failed-payment recovery is not | Not publicly verified Depth 0/5 Checkout session creation and webhook processing are documented; recovery of failed payments is not | Advanced Shipped Depth 5/5 Configurable, ML-assisted dunning whose retry intervals respond to the gateway’s transaction error type, deciding when to retry and when to notify instead |
| Getting paid, and keeping it Revenue, retention and cohort reporting Without it nobody can tell whether any of the rest worked. Usually a separate purchase made twelve months late. | Planned Depth 0/5 · target 4/5 Reporting present on launch instead of as a later integration project. The claim is timing and joinedness, not depth against RevenueStory. | Not publicly verified Depth 1/5 A super-admin dashboard manages users and organisations; revenue, retention or cohort reporting is not documented | Limited Shipped Depth 2/5 A dashboard app with user signup statistics and date filters, added in 2026.6.1 — signup counts rather than revenue or retention | Not publicly verified Depth 0/5 Dashboards can be generated over your own data; subscription revenue reporting is not documented as a platform feature | Advanced Shipped Depth 5/5 RevenueStory: subscription and trial analytics, custom reports, and collections reporting down to lifetime amount recovered by dunning stage |
| Looking after customers Support ticketing against the customer record A ticket that cannot see the plan, the entitlements and the failed payment is an agent guessing. The specialists here are excluded and named below. | Planned Depth 0/5 · target 4/5 Ticketing reading the same accounts and entitlements as billing. The specialists are deeper at support itself; this row is about what the ticket can see without being asked. | Not publicly verified Depth 0/5 Support ticketing is not part of the documented scope of a starter kit | Not publicly verified Depth 0/5 Not documented. The Django admin is the back office, which is a strong operations tool but not a ticketing product | Not publicly verified Depth 0/5 A ticketing app could be built with it; none is provided | Not publicly verified Depth 1/5 Billing-side customer records and collections correspondence; a support ticketing product is not documented |
| Growing it Affiliate and partner programmes with attribution and payouts A growth channel most teams bolt on late or never. The specialists here are excluded and named below. | Planned Depth 0/5 · target 4/5 Attribution and payouts beside billing that already knows what a referred customer actually paid — the join a standalone affiliate tool cannot make. | Not publicly verified Depth 0/5 Not in the documented feature set | Not publicly verified Depth 0/5 Not in the documented feature set | Not publicly verified Depth 0/5 Not documented as a platform feature | Not publicly verified Depth 0/5 A search of Chargebee’s own material found no affiliate or partner-programme feature. Recorded as unverified, not as absent |
| Growing it Lifecycle messaging, campaigns and funnel instrumentation The row where a platform of this shape is most likely to overreach, so it is scored and targeted conservatively. | Planned Depth 0/5 · target 3/5 The lowest target in the table, on purpose. Lifecycle messaging and funnel instrumentation — not a marketing automation suite, which is where a platform this broad would overreach first. | Limited Shipped Depth 2/5 Transactional emails, marketing pages, a blog and docs; lifecycle campaigns and funnel instrumentation are not documented | Limited Shipped Depth 2/5 An email marketing integration is listed on the Professional and Unlimited tiers; its scope is not documented in detail | Limited Shipped Depth 2/5 Marketing sites with forms, accounts and payments built in the same chat as the app; campaign and lifecycle tooling is not provided | Limited Shipped Depth 2/5 Billing experimentation and revenue-operations alignment across go-to-market functions; not a lifecycle marketing product |
| Holding together One customer record across billing, support and product The actual thesis. Every other column is one slice of a stack, and each slice brings its own customer record. | Planned Depth 0/5 · target 5/5 The thesis, and one of only two rows targeted at outright leadership. If this is not materially better than five systems wired together, the venture has no argument. | Included Shipped Depth 3/5 One database behind auth, teams and billing — genuinely joined, but what is joined is only the foundation | Included Shipped Depth 3/5 One codebase and one database across users, teams and subscriptions; the same strength and the same limit as Makerkit | Limited Shipped Depth 2/5 One generated project holds auth, data and payment records together, but the joins are whatever the prompts produced rather than a modelled customer | Limited Shipped Depth 2/5 Authoritative for the billing record and integrates outward from it, but the application and support records live in other systems |
Who each tool is actually best for
- SaaSWorks Not built — scoped for Wave 1
Not a buying option. Every row is target specification at an achieved depth of zero. The intended buyer is a founder or small team who would otherwise assemble five systems — and five customer records — before their first paying customer.
- Makerkit Pro licence, one-time, one developer
Teams that want the foundation solved properly and the rest of the stack chosen themselves. The deepest documented multi-tenancy and billing foundation in this shortlist, as source code you own outright.
Source: Next.js Supabase SaaS boilerplate — personal, team and hybrid accounts, RBAC, Postgres RLS isolation , Starter kit comparison — billing provider gateway across Stripe, Paddle and Lemon Squeezy , Homepage — one-time licence with lifetime updates and unlimited projects; Playwright suite over auth, billing, members, invitations and roles
- SaaS Pegasus Professional tier, one-time (teams and Stripe subscriptions are not in Starter)
Django teams. Generates a codebase you own outright, with teams, Stripe subscriptions, feature flags and the Django admin as a genuinely capable back office from day one.
Source: Subscriptions — Stripe pricing tables, webhooks, customer portal, per-seat and per-unit models, feature gating , Using Teams — roles, invitations, per-team data isolation by foreign key , Release notes — dashboard app with signup statistics (2026.6.1); React team settings (2026.3) , Homepage — tier feature comparison, including email marketing integration on Professional and above
- Lovable Paid plan (built-in payments and custom domains require one)
Getting something real in front of users fastest. Auth, database, storage and functions are on by default, checkout is a prompt away, and publishing is free — which makes it the most likely answer to "I need a SaaS by Friday".
Source: Lovable Cloud — database, storage, auth, realtime and functions on by default , Payments — Stripe and Paddle via edge functions, secrets kept out of code; one provider per project , Supabase integration — generated tables and schema, prebuilt authentication flows , FAQ — publishing, custom domains, autoscaling hosting
- Chargebee Chargebee Billing with RevenueStory, subscription pricing
Any subscription business whose billing has outgrown Stripe primitives. On dunning and revenue reporting specifically it is the deepest product in this shortlist by a wide margin, and nothing here suggests otherwise.
Source: Billing and monetisation — usage, hybrid and outcome-based pricing; 480+ invoicing scenarios; tax compliance , Revenue recovery — configurable, ML-assisted dunning with retry intervals driven by gateway error type , Collections reporting — lifetime amount recovered by dunning attempt, invoices by dunning stage, in RevenueStory , Subscription management — 40+ payment gateways
Considered and excluded
- supastarter, ShipFast and the other starter kits — Makerkit is compared as the representative of this category, as the most thoroughly documented of them on multi-tenancy and billing. Adding near-identical columns would widen the table without changing a single row — all of them solve the foundation and stop there. Check current status
How this comparison is made
- Comparative claims follow ACCC guidance: they must be accurate, fair and supportable on reasonable grounds, judged on the overall impression rather than line by line.
- A competitor capability is only marked as present where its official site or documentation describes it. Where it was not documented the status is “Not publicly verified” — not “Not available”. This is a desk review of published material, not a hands-on benchmark.
- SaaSWorks has no single competitor; its competitor is a stack. The shortlist therefore holds three products competing for the same decision at the same moment — Makerkit, SaaS Pegasus and Lovable — and one that owns the money half outright, Chargebee. A vendor-per-column table cannot represent "a starter kit plus four subscriptions", so the rows are written to make that assembly visible instead.
- Intercom and Zendesk in support, PartnerStack and Rewardful in affiliate marketing, ChartMogul and Baremetrics in revenue analytics, and Paddle alongside Chargebee in billing — all excluded, because none of them is an alternative to a foundation. They are bought *in addition to* one. Their rows here are scored at or near zero for every starter kit precisely because that is when a team goes and buys them.
- Makerkit leads on authentication and tenancy depth and on code ownership. Chargebee leads on billing, dunning and revenue reporting, and our targets sit a point below it on all three rather than claiming parity. SaaSWorks targets outright leadership on two rows only: breadth, and one customer record across billing, support and product.
- Depth scores (0–5) are our own analytical assessment of how deep a capability runs. They are not vendor-published figures, and they are separate from the evidence status beside them.
- SaaSWorks is not built. Every one of its cells shows delivery “Planned” and an achieved depth of zero. A target beside it is the specification being built toward, never a claim about today.
- Targets are published only for our own column and only with a stated reason. The lowest is growth marketing at 3/5, deliberately, because a platform this broad would overreach there first. Three more sit a point below Chargebee by design.
The approach
How we build it.
SaaSWorks is a planned platform for running a software business end to end. It starts where a starter kit stops: once the application foundation exists, the work that decides whether the business survives is collecting revenue, keeping customers and growing the account base — and almost every team builds that from scratch.
So the scope is the whole operating surface. Authentication, organisations and roles; subscriptions, usage billing and the dunning flows that recover failed payments; support ticketing reading the same customer record as billing; affiliate and partner programmes with attribution and payouts; lifecycle messaging and the instrumentation that shows which of it worked.
The intent: the undifferentiated three-quarters of a SaaS business, solved properly once so a team can spend its time on the quarter that actually differentiates it.
The outcome
What changes when it's in place.
- The undifferentiated foundation stops being a project.
- Revenue that would have leaked to failed payments is recovered.
- Support, billing and product all read the same customer record.
- A new venture reaches its real problem in days, not months.
What could go wrong
The risks, named.
-
Starter kits are a crowded, low-priced category, and buyers may not pay platform prices for a platform.
Do not compete on the starter-kit wedge. The revenue, support and growth machinery is where the remaining months go, and that is a different purchase.
-
A platform spanning build, billing, support and growth competes with four mature specialists at once.
Win on the join rather than the parts: one customer record across all four, which none of the specialists offers.
-
Owning a customer’s billing and support makes switching costly for them, which raises the trust bar before adoption.
Source-code ownership and data export as defaults, not concessions.
The open questions
What would need to be true.
-
A team will accept someone else’s foundation for billing and support, not just for sign-in.
How we would know: Measure how far down the stack early adopters actually deploy, rather than how many sign up.
-
The four areas are genuinely better joined than bought separately.
How we would know: Compare recovered revenue and resolution time against teams running a billing provider plus a separate help desk.
A scenario
What this could become.
$15M–$35M
at $5M ARR, on 3–7× ARR
A scenario, not a valuation, a forecast or an offer. It states what the venture might be worth IF it reached the revenue shown, at multiples other private SaaS businesses have transacted at. Nothing here has revenue today.
Published private-SaaS transaction benchmarks, checked 2026-10-12: private deals broadly transact at 2–7× ARR, with medians around 3–5×. These come from advisory firms and marketplaces rather than audited transaction data.
How it fits the foundry
A venture, not a department.
SaaSWorks moves through the whole foundry — discovery, design, engineering, quality and launch — like every venture we build. It's most visible in AI & Software Engineering, where its business purpose is sharpest.
- Discover
- Define
- Design
- Build
- Assure
- Launch
- Learn
- Scale