White-Label SaaS: What It Is and When It Makes Sense

White-label SaaS is software that one company builds and runs while other companies sell it to their own customers under their own name, logo and domain. The end customer only ever sees the partner's brand. It pays off when your customers are easiest to reach through intermediaries such as agencies, consultancies or franchise networks, but making a product carry someone else's brand takes far more than a logo upload field.

Most of the work hides in the data model, custom domains, email setup and every template where your own name still appears. Those are the parts I focus on below, from the point of view of the person who has to build them.

The short answer

White-labeling isn't all or nothing. It comes in levels, and each level costs more to build and run than the one before.

The effort column is a rough estimate and assumes your product already keeps customer data separated. My rule of thumb: build the level a paying partner is asking for today, not the one you imagine they'll want next year. Level 4 is really a new line of business with support, contracts and revenue share attached, not just a development task.

White-labeling extends a SaaS that already works. If you're still building that, my step-by-step guide to building a SaaS is the better starting point.

White label vs reseller vs private label

The term gets used for two different situations. In the first, you own a SaaS and let partners sell it under their brand. In the second, you don't own any software: you license a ready-made white-label product and sell it as your own. Then you're the partner, and the job is procurement and contracts, not development.

A few neighboring terms get mixed up with it:

• Co-branded or "powered by": the partner's logo is in the app, but your name is still visible somewhere. Much less to build.
• Reseller or referral program: the partner sells your product under your brand and earns a commission. No rebranding at all.
• Private label: often used interchangeably with white label in software. Some people reserve it for a version made exclusively for one reseller.
• A separate deployment per customer: that's single-tenant hosting, not white-label. It's also where many products end up when white-labeling wasn't designed in from the start.

What they share is that the partner gets the right to use and sell the product. The code and the infrastructure stay with you.

When white-labeling your SaaS pays off

If you own the product

Good signs:

• Your customers already buy through intermediaries: agencies, accounting firms, consultancies, managed service providers, franchise networks or industry associations that own the relationship.
• Partners are asking for it and are willing to pay, for example a platform fee plus a fee per active customer.
• The product is stable, and a new customer can get started without your help.
• Your product slots into the partner's own service, like a client portal an agency hands to its clients.

Warning signs:

• You don't yet know what your own customers will pay for. A partner layer between you and your users slows down how fast you learn.
• One partner brings in most of the revenue. At that point they effectively control your roadmap.
• Every partner wants different features. That's custom development dressed up as a product.
• Your brand is your main acquisition channel. If nobody sees your name, nobody recommends you.

If you want to resell someone else's software

Licensing a ready-made white-label product is often the right call, and far cheaper than building. If an existing product covers most of what you need, my honest advice is to buy it and spend the money on sales, not on hiring a developer like me to rebuild it from scratch.

The trade-off is that you don't control the roadmap, the vendor can raise prices, and moving your customers is hard if the vendor shuts down or gets acquired. Always ask whether you can export your customers' data in a usable format, and where it's hosted if your clients expect EU hosting. If you're weighing this for a client portal, I've compared building a custom customer portal with white-labeling one.

Steps 1-4: data model, theming, domains and email

Once you've decided to open up to partners, these eight steps decide whether you end up with one product or a pile of one-offs. The first four are the foundation.

1. Add a partner level to your data model. White-labeling adds a level above the customer: partner, customer, user. A partner can create customers and see their usage but must never see another partner's customers, and your tests need to cover both boundaries. I've explained customer-level isolation in my post on multi-tenant SaaS architecture.
2. Store branding as data, not code. Logo, colors, favicon and product name live in the database per partner and get injected as CSS variables, so onboarding a partner never requires a deploy. Don't let partners upload arbitrary CSS, because it breaks the next time you change your markup. Check color contrast automatically too, since a pale brand color on white is often unreadable.
3. Support custom domains with automatic certificates. The partner points a CNAME record at your servers, and your stack has to obtain and renew the TLS certificate on its own. Caddy's on-demand TLS and Cloudflare for SaaS exist for exactly this. With Caddy you build an "ask" endpoint that approves each domain, or anyone could make your server request certificates for arbitrary domains. Mind sign-in as well: cookies are scoped to a domain, and Google or Microsoft login usually needs every redirect URL registered with the provider.
4. Send email from the partner's domain, or don't. If your servers send mail as the partner's domain without SPF and DKIM in place, it lands in spam. Since February 2024, Google's sender guidelines require SPF or DKIM from everyone sending to Gmail accounts. Anyone sending more than 5,000 messages a day to Gmail needs both SPF and DKIM, plus DMARC and an aligned From domain. Build a settings page that shows partners the exact DNS records and verifies them. Until they pass, send from your own domain with the partner's name as the display name.

Steps 5-8: copy, partner admin, billing and GDPR

The next four get skipped most often, because they aren't really about the app itself.

5. Hunt down every place your name appears. The app rarely gives you away. The welcome email does, along with the payment receipt, the PDF export, the maintenance page, the browser tab title, help articles and API docs. Replace product names and URLs with variables in every template and translation file. A quick test: create a partner with a made-up name, then search everything the system sends out for your own.
6. Build a partner admin panel with clear roles. Partners need to create and suspend customers, see usage and edit branding, which means at least partner admin, partner support, customer admin and user roles. If partner support can sign in as a customer, log it. Agree on who answers the end customer too: usually the partner takes first-line support and you take second line, since the end customer doesn't know you exist.
7. Decide who bills the end customer. Either you charge the partner a wholesale price, say per active customer, and they set their own retail price. Or you bill end customers on the partner's behalf and split the revenue, for example with Stripe Connect, which is built for platforms that take payments for others. The first model is far simpler. The second also gets messier with VAT once partners and customers sit in different EU countries. Read up on SaaS pricing models and my comparison of subscription billing options for SaaS before you promise partners anything.
8. Make the data processing agreements line up. Typically the end customer is the controller, the partner is the processor and you are a sub-processor. Article 28 of the GDPR requires the controller's written authorization before a processor engages a sub-processor, and the same data protection obligations have to flow down the chain. So the partner must be able to name you as a sub-processor, even though your brand appears nowhere else. My GDPR checklist for SaaS covers the technical side. This isn't legal advice.

Pitfalls that show up at partner number three

Most white-label problems don't appear with the first partner. They appear with the third.

• Forking the code per partner. It feels fast the first time. By the third partner every bug fix has to be made three times, and the copies drift apart. Anything that differs between partners should be a setting or a feature flag, not a separate branch.
• The biggest partner writes your roadmap. A large, well-paying partner will want their own features. Only say yes to what helps the other partners too, or charge for it as separate development work.
• Wholesale pricing that's too thin. The partner needs a margin to resell, and you still carry hosting and second-line support. A price that only just covers your costs won't hold once the number of end customers grows.
• Churn you can't see. The partner owns the relationship, so you never hear the complaints. Track activity and cancellations per partner from day one.
• Custom domains handled by hand. Certificates renewed manually eventually expire, and the partner's customers get a browser security warning instead of the app.
• No exit plan. What happens to the customers' data if a partner walks away? Can those customers move to you directly, or to another partner? Put it in the contract before the first customer is onboarded.

Next steps

If you're still unsure whether white-labeling is right for you, start with one level and one partner, and build the rest when the next partner is ready to pay for it. Run through this list before you sign.

If you'd like to see how I approach this kind of work, from a fixed-price discovery phase to code you own from day one, take a look at my SaaS development service.

Frequently asked questions

Can I white-label an existing SaaS after launch?+

Yes, but how much work it takes depends on how the product was built. If every table already has a tenant ID and your product name lives in translation files rather than scattered through the code, it's mostly a matter of adding the partner level, theming and custom domains. If names, colors and URLs are hardcoded everywhere, or customers aren't properly isolated, you start there, and that's usually the bigger job.

Do white-label partners get the source code?+

No, not usually. A white-label agreement gives the partner the right to use and resell the product under their own brand, while you keep the code, the hosting and the right to keep developing it. A partner who wants the code needs a different deal: a source code license or buying the product outright. That can make sense for a very large partner, but you typically lose control over the version they run.

What should a white-label SaaS agreement cover?+

At minimum: pricing and payment terms, who supports end customers, uptime and response times, brand usage rules, data processing agreements, and what happens to customers and data when the agreement ends. Also agree whether you may contact end customers directly during outages or security incidents. This isn't legal advice, so have a lawyer review the agreement before anyone signs it.

Can each partner get their own app in the App Store?+

Generally not, if you submit them yourself. Apple's guideline 4.2.6 rejects apps built from a commercial template or app generator unless the company whose content the app shows submits them itself. Your options are a single app where users pick their partner, or having each partner publish the app from their own developer account. A web app, on the other hand, can carry every partner's brand with no app store review at all.