"And now for several clients": why scaling is a whole other product

Suppose you pull it off: the assistant works for your shop. The logical question arrives: “now, do we open it to other shops?”. That’s when you discover that going from one to many isn’t “the same but at scale”. It’s almost a different product.

What changes when third parties come in

• Self-service onboarding. Each shop must be able to connect its WhatsApp without you touching anything. That’s building an embedded signup flow, storing each one’s credentials, and routing every message to the right client.
• Shopify per shop. No more hardcoded store: you need a public app with OAuth, a token per merchant, and per-client configuration (their product, their brand).
• Isolating data. One shop’s data can’t bleed into another’s. True multi-tenancy means thinking about isolation at every layer.
• Billing and metering. Who consumes how much, and how it’s charged. Without per-client metering, there’s no business model.
• Contracts. You become each shop’s data processor: DPAs, responsibilities, safeguards.

The trap: building it too early

It’s tempting to “leave it ready for multi-tenant” from day one. It’s almost always a mistake: you design the abstraction blind, without a real client to tell you what it actually looks like, and you refactor anyway. The expensive part isn’t the “client parameter”: it’s the new subsystems (OAuth, onboarding, billing, DPAs), and those don’t get cheaper by front-loading them.

The sensible move: build clean for one client, keep the hygiene that makes the seam cheap (centralized config, routing by identifier), and build the abstraction when the second client arrives — with the real shape learned.

The takeaway

“Make it work for several” sounds like a tweak; it’s a whole project: onboarding, OAuth, isolation, billing and contracts. That’s why so many great ideas stay at “it works for me”.

We’re walking that path so a shop doesn’t have to. You connect, and you’re already part of something that scales — without building any of this.

— The Taituri team