Blog
Key takeaways:
No code SaaS is a thoroughly covered subject right up to the moment of launch, which is precisely where the interesting problems start.
An internal tool has one customer and forgiving users. A product people pay for has tenants who must never see each other's data, a billing relationship with tax consequences, buyers who send security questionnaires, and an expectation that it works on a Sunday. None of that is about whether you can build the thing.
This covers what happens after the build: how tenancy actually works on these platforms, who is legally selling your software, what compliance you inherit, how the pricing behaves when usage grows, and what leaving looks like. We build custom software, so treat our view on the last point with appropriate suspicion, and check the numbers, which is why they are all sourced.
Taking money converts a project into an obligation, and four specific things change at once.
You acquire tenants rather than users, so data separation stops being a convenience and becomes the thing that ends your business if you get it wrong. You also acquire a billing relationship, which carries tax obligations in every jurisdiction your customers live in.
Buyers arrive who ask about your security posture, sometimes before they will pay you anything. And you take on an availability expectation you cannot fully meet, because part of your stack belongs to somebody else.
None of these is a reason not to use these tools. They are the four things to have an answer for before the first invoice goes out, and a no code SaaS business plan can look complete without addressing a single one of them, because none of them blocks the build.
The pattern we see most often is a founder who validated demand properly and then discovered the commercial plumbing afterward. Validation is the easy part to do well now, and validating the idea first remains the right sequence. It just is not the whole job.
The vocabulary here is worth borrowing from people who do this at scale. AWS's SaaS Lens describes three patterns. The silo model is where "tenants are provided dedicated resources," for example a separate database each. The pool model is where "tenants share resources," which it calls "the more classic notion of multi-tenancy." The bridge model is a mix, with some parts siloed and some pooled.
Every mainstream no-code platform puts you in a pool. Your customers share one application instance and one database, and the separation between them is not architectural. It is a set of permission rules you configure.
There are three ways to separate tenants, and these tools all pick the same one.
On Bubble, for example, there is no native multi-tenant mode. You build tenancy yourself by creating a workspace record, attaching every piece of tenant data to it, and writing privacy rules so that searches only return records belonging to the current user's workspace. That works. It also means the boundary between two paying customers is a configuration you maintain, with no row-level security underneath to catch a mistake.
Xano is the exception worth naming: it offers tenant isolation for data and resources, but that sits on its custom enterprise tier rather than its published plans.
The practical consequence is a testing discipline, not an architecture choice. Create two tenants, put real-looking data in both, and try hard to reach one from the other, using an ordinary account rather than the admin account you built with. Do it again after every change to the data model.
This is the question almost nobody writing about no-code SaaS asks, and it has real money attached.
Stripe's standard product is a payment processor. It moves money and takes 2.9% plus 30 cents on card transactions, but you remain the legal seller. That means registering for, collecting and remitting sales tax, VAT or GST in every jurisdiction where you have customers, which for a digital product sold online can mean obligations in places you have never visited.
Paddle works differently. It acts as merchant of record, meaning it is the legal seller and it takes on the tax registration, collection and filing, for 5% plus 50 cents. Lemon Squeezy does the same job at the same rate, and is not an independent alternative to Stripe: Stripe acquired it in 2024.
Stripe now sells the model under its own name too. Managed Payments makes Stripe the merchant of record and handles sales tax, VAT and GST compliance, and it is priced at 3.5% per transaction on top of the standard Payments fees rather than instead of them.
| Stripe Payments | Stripe Managed Payments | Paddle | Lemon Squeezy | |
|---|---|---|---|---|
| Fee | 2.9% + 30 cents | 3.5% on top of Payments fees | 5% + 50 cents | 5% + 50 cents |
| Merchant of record | You | Stripe | Paddle | Lemon Squeezy |
| Who owes sales tax and VAT | You, everywhere you sell | Stripe | Paddle | Lemon Squeezy |
| Handles registration and filing | No, though Stripe Tax automates calculation | Yes | Yes | Yes |
| Owned by | Stripe | Stripe | Independent | Stripe |
| Best fit | You have finance support | You are already deep in Stripe's stack | Selling internationally, solo or small | Selling internationally, solo or small |
Stack the fees instead of reading across the headings and the ranking changes. Managed Payments comes to roughly 6.4% plus 30 cents all in, which is more than either specialist charges for the same transfer of liability. Keeping everything inside one stack is a real reason to pay that; a better rate is not one.
Plain Stripe still looks cheaper by roughly two percentage points, and for a US-only product with an accountant, it usually is. For a solo founder selling into several countries, the merchant-of-record premium buys tax compliance that would otherwise be your evenings.
The fee gap is also frequently smaller than what a specialist charges to handle the same filings, which makes it one of the rare costs worth paying more for when you are managing early burn.
The table shows something the fee comparison hides, too. Three of the four options are Stripe, so treating "we will move processors if the terms change" as your fallback is thinner than it looks.
Every no-code platform in common use integrates Stripe, and none of them is a merchant of record itself. So the default path these tools put you on is the one where the tax liability stays with you.
Card data attracts rules, and the rule that matters depends on a design decision you may make without noticing: whether the payment form lives on your page or on the processor's.
The PCI Security Standards Council's FAQ 1588 clarifies the eligibility criteria for the revised SAQ A under PCI DSS v4.0.1, which took effect on 1 April 2025. The criterion in question requires that a merchant confirm "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."
Here is the part worth reading carefully. That criterion applies to merchants whose page includes the processor's embedded payment form, for example in an iframe. It explicitly does not apply to merchants who redirect the customer away to the processor, or who fully outsource payment entirely.
The same purchase, two obligations, decided by where you put one form.
So embedding the payment form on your own page, which is the nicer experience and what most builders default to, takes on an obligation that redirecting does not. You can meet it, either by protecting the page yourself or by getting confirmation from your processor that their embedded solution includes that protection. You simply need to know you have taken it on, and check with your acquirer that SAQ A is even the right questionnaire for you.
Seat-based pricing is intuitive: more people, more money. Most no-code platforms do not work that way, and the mismatch catches people out because a SaaS product's usage grows with its customers' activity rather than with your team.
Each platform meters something different, and there is no shared unit that lets you compare them.
| Platform | What it meters | What that means for a paid product |
|---|---|---|
| Bubble | Workload units, covering database queries, workflow runs and page loads | Cost tracks how hard your customers use the app, not how many there are |
| Glide (Classic) | Updates written to a connected external data source, plus per-user | Native tables are free to write; synced sources are the meter |
| Softr | AI credits, plus builder seats, plus separately counted end users | Three meters at once, and end users are counted apart from your team |
| Xano | Compute allocation, workspaces and seats | Closer to infrastructure billing; predictable, and isolation costs extra |
| Backendless | Peak API requests per minute | A traffic spike, not a monthly total, sets your bill |
| Adalo | Deliberately nothing | Flat tiers, marketed explicitly as no usage-based charges |
Bubble's own tiers run from a free plan at 50,000 workload units a month through Starter at $59, Growth at $209 and Team at $549, all of them Web and Mobile plans billed annually, with 500,000 units at the top published tier.
Real numbers help more than the abstraction. In one r/Bubbleio thread from October 2024, founders posted their actual consumption against revenue.
One reported roughly 4,000 monthly users and 900 daily actives burning 1.5 million units, for a bill a little over $300 against $6,000 in monthly recurring revenue. Another reported around 2 million units and a similar bill against $10,000.
Read those as ratios rather than as current prices. Both bills sit below today's $549 Team tier while consuming three to four times its unit allowance, which is a clear sign that Bubble has repriced since the thread and that nobody would be quoted those figures now. What survives the repricing is the proportion, and it is the useful part: the platform fee came to roughly 5% of revenue in the first case and 3% in the second.
The healthy reading is that the platform fee is a small share of revenue in both cases. The uncomfortable reading is that it is a variable cost you do not fully control, which is a genuinely different shape of business from one with a variable cost structure you chose deliberately.
Sell to one mid-sized company and a questionnaire arrives. It will ask where data is hosted, who can access it, whether you have single sign-on, whether you keep audit logs, and whether you hold SOC 2.
On no-code platforms most of those answers are the vendor's rather than yours, which cuts both ways. You inherit their certification, and you also inherit their tier structure, because the features buyers ask about tend to sit at the top of the price list.
Softr places SOC 2 Type II, SAML single sign-on and audit logs on its enterprise tier. Xano includes SOC 2 in its paid plans but sells HIPAA with a business associate agreement as a $500 a month add-on. Backendless bundles audit logging and HIPAA support into an enterprise security package at $399 a month or $4,000 a year, and Knack is unusual in leading with HIPAA, GDPR and SOC 2 in its ordinary marketing.
Four things are worth having ready before the first questionnaire arrives:
An investor doing technical due diligence will ask a version of the same questions, usually with more interest in what happens if the platform changes its pricing or its mind.
When a shared platform has an incident, your product is down and there is nothing you can do except post an update. That is a real trade and mostly an acceptable one, since these vendors run better infrastructure than a solo founder would.
The sharper risk is not an outage. It is the platform ceasing to exist. Bildr, a no-code builder with paying customers, shut down on 25 May 2026, and its pricing page now carries a farewell note. Anyone who had built a commercial product on it discovered that the platform's business model was a dependency inside their own.
The reason its founder gave is the part worth sitting with, because it is not the usual story of a company running out of money. Mark Magnuson wrote that AI had made Bildr obsolete, "not gradually, quickly," and that agentic development rather than visual development was the destination Bildr had been building toward.
His illustration is the sharp bit. A customer who had spent months building an application on Bildr, with significant help from his team, migrated it off in a couple of days using a coding agent and no support at all. He also argues the no-code category was "always a bridge" and a transitional technology.
He is now building an AI company, so he has an obvious interest in that conclusion and it should be read that way. The concrete part is harder to wave away than the framing around it, and it is a first-hand account of a platform closing rather than a prediction about one.
That is the extreme case and it is not common, but it sets the right question to ask before you commit: if this vendor disappeared or tripled its price, what would you do in the following ninety days?
If the honest answer is that you would rebuild from scratch, price that risk now rather than later. Our resources include the forecasting models that make a question like this a number instead of a worry.
The skeptical case is easy to overstate, so it is worth being concrete about the other side.
Messly, a UK marketplace matching locum doctors with shifts, was built on Bubble and was acquired by M3, a physician-network company listed on the Tokyo Stock Exchange. The detail that matters for this article is that the product continued running on Bubble after the acquisition rather than being rebuilt as a condition of it.
That is one case, not a trend, and marketplaces are a genuinely good fit for these tools because the hard part is liquidity rather than engineering. It is the same reason we tell people that building a marketplace is mostly a demand problem wearing a software costume.
What the good examples share is a product whose value is the network, the content or the workflow rather than the software's own sophistication. Where the product's differentiation is the engineering, the platform becomes the ceiling, which is the honest version of the no-code saas vs custom saas question.
We watched this happen from the inside with ProduceDesk, a produce logistics business that saw an opportunity to build a subscription platform for brokering orders. It tried to build the first version itself, and the result was weighed down with enough errors that the initial version was shelved before it could be rebuilt properly with us.
That is the ordinary failure and it is not really a technology failure. A company that knows its industry deeply is not automatically equipped to build and operate commercial software, and the tooling being easier does not change the operating part.
The breakages cluster in three places. Data volume, where query performance degrades as records accumulate across every tenant rather than just yours. Permissions, where a rule that was correct when you had one customer type stops being correct when you add a second. And integrations, where a customer requires single sign-on with their identity provider and your platform offers it two tiers up, or not at all.
All three sit at the same end of the timeline, and it is not the beginning.
None of those arrive on day one. They arrive at the point where the product is working, which is the worst possible time to discover them.
If you outgrow the platform, do not budget for a migration. Budget for building it again.
The reason is structural. Your application logic lives in a proprietary visual format that has no export, and while the data usually comes out, it comes out shaped around the platform's internal model rather than yours. Practitioners describe writing scripts to pull data through the API while access lasted, rather than trusting a CSV export with relational data.
One builder who moved a series of client applications from Bubble to conventional code posted a year of their own numbers: a median rebuild of about nine weeks, ranging from two weeks for a small app up to twelve for one with more than 100,000 users, and data migration consistently the hardest part.
The spread matters more than the median, because it tracks how much product you have.
That same post makes a point against its own interest, reporting that monthly platform costs stayed roughly the same afterward, because Bubble is only expensive at high workloads.
That is anecdotal and matches what we see. The rebuild is not a disaster, and it is far cheaper than the first build was, because you now have a working specification that real paying customers have already validated. Investors tend to take a similar view, and it rarely blocks a round, though it does come up when raising an early round gets to the technical section.
Yes, and people have, including products that got acquired. The build is genuinely solved for a large class of applications, particularly marketplaces, directories, internal-tool-shaped products and workflow software with moderate data volumes.
What is not solved is the commercial layer around it. Tenancy, tax liability, security review and platform dependency are all still yours to handle, and none of them gets easier because the interface was drag and drop.
The short answer to how to build scalable SaaS with no-code is that scale gets decided in the data model rather than in the interface.
Keep the data model simple and index-friendly from the start, since query performance across all tenants degrades faster than most founders expect. Push heavy or scheduled processing off the platform to a service designed for it rather than running it in a workflow.
Watch the meter your platform actually charges on and instrument it before you need to, so a bill increase tells you something about usage rather than arriving as a surprise.
There is no single answer, because the platforms meter and constrain different things. Bubble is the most capable for genuinely custom application logic, Softr and Glide are faster for products that sit on structured data, and Xano is the one to look at when the backend and tenant isolation matter more than the interface.
Choose on the metering model and the compliance tier rather than the feature list, since those are the two things that decide what the product costs to run at scale.
For the interface and the workflow around a model, yes, and this is a common shape now. No code AI SaaS products generally call an external model API, which these platforms handle fine.
Be careful with the economics. A no code AI SaaS pays platform metering and model inference on the same request, so a usage spike hits your costs twice, and both are variable.
When the platform's ceiling has become your product's ceiling, when compliance requirements exceed what the vendor offers, or when the metered cost has grown into a serious share of revenue. Any one of those is worth a conversation rather than an immediate rebuild.
Plan the rebuild when two arrive together, and treat the existing product as the specification rather than as something to be ashamed of.
The decisions that get expensive here are the ones made by default: an embedded payment form nobody scoped, a permission rule that was fine with one customer, a platform chosen on features rather than on how it meters.
Contact us and we will walk the commercial layer with you before you are committed to it.
