Multi-tenant shell, per-tenant theming, reseller admin, and Stripe Connect billing. You own the code. Pro tier, monthly subscription.
- Scope
- Ship
- Iterate
monthly subscription
Who this is for
You run an agency or consultancy that charges by the hour for something customers want permanently. Maybe it's a reporting dashboard, a booking flow, or a customer portal. The service works, the customers keep renewing, and somewhere in the back of your mind you know it should be a product. White-label software development is exactly that move: one codebase, many tenants, each seeing their own brand.
The pain today
- Revenue scales only with headcount — no leverage in the model
- Customers asking for 'their own version' with their logo and domain
- Off-the-shelf tools (GoHighLevel, Sharetribe) too opinionated or too expensive to resell
- Multi-tenant architecture feels like a speciality you don't have in-house
- Managing reseller margins and end-customer billing in the same system
The outcome you get
- Multi-tenant shell with per-tenant theme, logo, and custom domain
- Reseller admin — your cross-tenant view of all customers, usage, and revenue
- Tenant admin — each customer's self-serve view of their own users and data
- Stripe Connect billing with configurable reseller margins per tenant
- White-label email templates, docs, and zero-touch tenant provisioning
Why white-label software development is a different build problem
White-label software development is not a regular application build with a logo field added. It requires three isolated layers from day one: platform (your agency's cross-tenant operations), tenant (each end-customer's isolated workspace), and end-user (individuals inside a tenant). Missing the separation at architecture stage means retrofitting it later — expensive and fragile.
The most common mistake I see is agencies who build a single-tenant product first, then try to bolt on multi-tenancy after the first reseller deal. By then, tenant ID is scattered across 40 database tables with no enforced isolation. Starting with row-level tenancy — every query filtered at middleware level by tenant ID — means the wrong data never reaches the wrong customer. That is not a nice-to-have; it's what separates a white-label product from a data breach waiting to happen.
For the majority of agency white-label builds, row-level tenancy with strong application-layer enforcement covers the need. Schema-per-tenant adds isolation at the cost of operational complexity. I choose the pattern based on your security requirements and tenant count projections, not on what is fashionable.
Multi-tenant shell with per-tenant theme, logo, and custom domain
Tenant isolation: where most builds break
Tenant isolation is the engineering problem that looks solved until it is not. Every data access point — API endpoints, background jobs, exports, webhooks — must enforce the current tenant's context. One endpoint that forgets to filter by tenant ID is a cross-tenant data leak. In a white-label SaaS you are selling to agencies who are selling to their own customers, so the trust chain has three levels. A breach at any level is your problem.
I design tenant middleware at the framework level, not the controller level. Skipping it requires deliberate action, not an oversight. CI includes tests that impersonate Tenant B while authenticated as Tenant A and assert a 403 — if those tests ever pass, the build stops.
Role-based access control sits on top: platform admin (your agency), tenant admin (customer's IT contact), and end-user (customer's employee or customer). Each role sees exactly the surface it needs. The platform admin role also gets impersonation — you can drop into any tenant's session for support without sharing passwords, with a full audit log.
40+: Payment providers integrated.
Theming, custom domains, and zero-touch provisioning
Per-tenant branding is three layers deep. Visual: colors, fonts, logo, and favicon stored per-tenant, applied via CSS custom properties, editable by the tenant admin without a code deploy. Content: email templates, transactional strings, and help-link destinations — each tenant sees their own support URL, not yours. Domain: subdomain per tenant (customer.agency.app) is the default; full custom domain (app.customer.com) via Cloudflare SaaS Custom Hostnames or Vercel's multi-tenant setup, with automated SSL.
Tenant provisioning should be self-serve from the reseller admin. Your agency creates a new tenant, configures the branding, sends the invite — no engineer required for each new customer. That is the operational leverage white-label is supposed to deliver. If you need an engineer to onboard every new customer, the product is not finished.
For agencies targeting SMB customers, subdomain-per-tenant handles most of the market. Full custom domain is typically a tier upsell — customers who care enough about brand to want app.theirname.com will pay a premium for it.
Reseller billing and Stripe Connect
The billing model for white-label SaaS is B2B2B: you sell to an agency (or you are the agency) who sells to end-customers. Stripe Connect handles the split automatically — your agency keeps a configurable percentage, the rest settles to your vendor account or to end-customers depending on the model. No manual reconciliation.
End-customers see your agency's name on their statements, not Stripe's. That brand cohesion matters in B2B: end-customers should feel like customers of your product, not customers of a platform they have never heard of. Invoicing, receipts, and dunning emails all come from your agency's domain.
At bolttech, the platform I worked on served 40+ payment providers across 15+ international markets, with per-partner configuration for compliance rules, branded UX, and payment routing. The architectural patterns are the same at smaller scale: per-partner (tenant) isolation, unified platform operations, configurable billing splits. A $1B+ unicorn's discipline applied to a 20-tenant agency product.
What is included in the Pro tier build
White-label SaaS builds sit at the Applications Pro tier — $5,499/mo — because scope density is higher than a standard application. Multi-tenancy, per-tenant theming, reseller admin, and Stripe Connect all require careful architecture decisions that compound across the build.
First-version timeline is 6 to 8 weeks for a launch-ready shell: multi-tenant data model, reseller admin, tenant admin, Stripe Connect billing, per-tenant theming (subdomain, colors, logo), and tenant provisioning from the admin panel. That shell is deployable and resellable. Subscription continues through tenant onboarding as each new customer surfaces edge cases — they always do.
Work Made for Hire means you own the code outright once the first invoice clears. You can resell the product, white-label the development engagement itself, and hand it to your own engineers later. 14-day money-back, cancel anytime after that.
Off-the-shelf vs custom white-label build
GoHighLevel, Sharetribe, and similar platforms are valid starting points for some agencies. They are wrong for agencies whose service is domain-specific enough that the off-the-shelf product cannot represent it, or who want to own the asset rather than pay a platform rent indefinitely.
The calculation is straightforward. If your product generates $10,000/mo in reseller subscriptions and you are paying $1,500/mo in platform fees, you own 85 cents of every dollar. If the platform raises prices, changes API access, or gets acquired, your revenue depends on their decisions. Custom white-label software development removes that dependency. You pay a build cost, then you own a revenue-generating asset.
I have spent 17 years building products for agencies and founders across the US, UK, and Latin America. The agencies that end up with the most durable revenue streams are the ones who own their infrastructure. The ones who built on rented platforms have all had a conversation at some point about what happens when the rent goes up.
Recent proof
A comparable engagement, delivered and documented.
Unified payment orchestration across Asia and Europe
Delivered the payment orchestration platform at bolttech, a $1B+ unicorn, with 40+ integrations across multiple regions.
Read the case studyFrequently asked questions
The questions prospects ask before they book.
Row-level tenancy scales to tens of thousands of tenants on standard infrastructure. Most agencies ship with 5 to 50 tenants in year one — the architecture does not need to solve for 100,000 on day one. If projections push into hundreds of thousands of tenants, schema-per-tenant or sharded architecture becomes worth the operational cost. I size the pattern to your actual near-term numbers, not to the theoretical ceiling.
GoHighLevel and similar platforms are fast to market and reasonable for generic use cases. The trade-off is dependency: platform pricing, API access, and feature roadmap are outside your control. A custom white-label build takes 6 to 8 weeks and costs more upfront, but the code is yours. No platform rent, no risk of a pricing change erasing your margin, no feature gaps you cannot fix. If your service is specialized enough that the off-the-shelf product misrepresents it, custom is the right answer.
Yes. Subdomain per tenant (customer.agency.app) is the default and requires no extra configuration per tenant. Full custom domain (app.customer.com) uses Cloudflare SaaS Custom Hostnames or Vercel's multi-tenant setup, with automated SSL provisioning. Custom domain is typically a tier upsell — customers who care about brand presence at that level will pay for it, and it costs you nothing incremental once the plumbing is in place.
Stripe Connect with your agency as the platform operator. End-customer subscriptions flow through Stripe, the split happens automatically at the configured margin (your percentage, remainder to your vendor account or directly to the end-customer's payment). End-customers see your agency's name on their statements, not Stripe's. You see aggregate platform revenue, per-tenant subscription status, and refund controls in your agency's Stripe dashboard.
Per-tenant data export and deletion are both supported. Each tenant can export their data at any time via the admin panel. On cancellation, a 30-day retention window gives them time to extract before permanent deletion. GDPR and CCPA compliance is built into the data model. Your platform terms define whether end-customers own their data (standard) or license it — either way, your agency owns the platform itself.
That is a core requirement of the build, not an optional feature. Tenant provisioning is self-serve from the reseller admin panel: create the tenant, configure branding, invite the first admin user. No code deploy, no database migration. If onboarding a new customer requires engineering time, the product is not finished yet. Complex per-tenant custom workflows are the only exception, and those are scoped separately.
The standard stack is NestJS or Laravel for the API layer (depending on the team who will maintain it), React with Next.js for the admin interfaces, PostgreSQL or MongoDB for data, and Stripe Connect for billing. Cloudflare or Vercel handles the multi-domain routing. All choices are made against your existing team's skills and your hosting preferences — I am not attached to a single stack, but I am attached to choices that your engineers can maintain after I leave.