Building RepSaaS on Google Cloud — The Architecture Behind a White-Label Platform

When you sell software under your own brand, your clients are trusting your name with their reputation — even though there's a platform underneath. That platform has to be invisible and it has to be reliable, because the moment it isn't, it's your brand that takes the hit, not ours. That's the bar we're building RepSaaS to. Here's an honest look at how we're putting it together on Google Cloud, and why we made the choices we did.

Why we started with infrastructure, not features

The three of us building RepSaaS — Lewis, Tim, and me — previously spent years building and scaling multi-million-pound software together in another industry. The biggest lesson from that experience: the boring infrastructure decisions you make early are the ones that either let you scale calmly or haunt you forever.

So before we built the parts you'll see, we spent real time on the parts you won't: how data is isolated between agencies, how messages get sent reliably, how billing stays consistent, and how the whole thing stays up. White-label SaaS lives or dies on reliability, because an agency reselling our platform is staking their reputation on our uptime. That's a responsibility we took as the first design constraint, not an afterthought.

Why Google Cloud

We chose Google Cloud for a few practical reasons:

• Managed services that scale without drama. We'd rather spend our engineering hours on the product than on babysitting servers. Google Cloud's managed compute, databases, and queues let a small team operate like a much larger one.
• A serious data and global networking backbone. A review platform is fundamentally about moving and storing a lot of small records reliably — review requests, messages, events, billing records — and serving them fast wherever clients and their customers are.
• Room to grow into. As RepSaaS adds more intelligent features, having the broader cloud ecosystem available means we're not boxed in later.

None of this is exotic. It's a deliberately proven, well-trodden stack, because the goal is reliability, not novelty.

How multi-tenancy works (the heart of white-label)

The defining technical challenge of a white-label platform is multi-tenancy: many agencies, each with many clients, all running on one shared platform — while every agency's data stays cleanly separated and every client portal looks like it belongs entirely to that agency's brand.

We treat tenant isolation as a first-class concern. Every record is scoped to its owner, every request is checked against who's allowed to see it, and the branding layer — logos, colours, domain, product name — is resolved per tenant so the same underlying system renders as a completely different-looking product for each agency. From the outside, an agency's portal is theirs. Underneath, it's one platform we can improve for everyone at once. That's the white-label promise made real, and it's the part that's hardest to retrofit, which is exactly why we built it in from day one. The broader idea is covered in what is white-label SaaS.

Reliable messaging and review flows

A review platform is, at its core, a messaging system with good timing. Requests go out, follow-ups send on schedule, and everything stops the instant a customer leaves a review. Getting that right means designing for the messy reality of the real world:

• Queued, retried sending. Messages go through a queue so a momentary hiccup with an external provider doesn't lose a request — it retries. Sending should be eventually reliable, not best-effort.
• Graceful channel fallback. Requests go out on the best available channel and fall back automatically when needed — the tradeoff Lewis wrote about in RCS vs SMS for review requests.
• Idempotency everywhere. When you're sending at volume, you design so a retry can never double-send. Every send is keyed so "try again" is always safe.

The user-facing result is simple: requests go out at the right moment, every time, without anyone watching. The engineering to make "simple and reliable" true at scale is the actual work.

Billing that lands in the agency's account

One of the choices we're proudest of is how billing works. Rather than collecting payments ourselves and paying agencies out, billing runs through each agency's own payment setup, so the money lands directly with them. Technically that means orchestrating payment flows on behalf of many connected accounts while keeping every agency's billing data consistent and isolated — the same multi-tenancy discipline applied to money. It's more work than a simple resell-and-pay-out model, but it's the right model: the agency owns the customer and the cash.

Building in a closed beta, on purpose

RepSaaS is in closed beta, opening more widely in Q3 2026. That's deliberate. Building infrastructure that thousands of branded portals will eventually depend on is not something you rush to a public launch. We'd rather onboard a small group of founding agencies, watch how the system behaves under real load, and harden it before we open the doors — than launch loud and learn the hard lessons in public.

If you want to see how this engineering shows up in the product, our white-label review management page is the best place to start. And if you'd like to be one of the founding agencies we build this with, the waitlist is open now.

The honest bottom line

There's no magic here — just a deliberate set of proven choices made by people who've built and scaled real software before, aimed squarely at one goal: a white-label platform reliable enough that agencies can confidently put their own name on it. On Google Cloud, with multi-tenancy, reliable messaging, and agency-owned billing built in from the start, that's exactly what we're building.