August 21, 2025. Day 2 of building STRAŦUM.
I was sitting at my desk with one working AI agent (Business Strategy), basic authentication, and a very simple data model. Coffee’s getting cold. I knew exactly who I wanted to build for: SMEs who needed AI marketing help, AND agencies who could use it across multiple clients.
Both audiences. From Day 1.
After 20 years working on the agency side, I understood what agencies actually need—not the glossy marketing version, but the messy reality of managing 10-15 clients with different strategies, different brand guidelines, different everything. I also knew SMEs desperately needed affordable strategic help.
But on Day 2, staring at my simple data model, I realized something uncomfortable: building for both audiences meant building multi-tenant architecture. Now. Not later.
By end of day, I’d committed to a decision that would triple my development complexity and extend my timeline by weeks.
I built multi-tenant architecture from Day 2.
Was this ambitious or insane? Honestly, I wasn’t sure. I’m still not 100% sure. But here’s the story of why that decision—made with almost no working product—turned out to be one of the most important technical choices I made.
Why Both Audiences? 20 Years of Agency Experience
The vision was never SME-only. From the start, I wanted to build for two distinct audiences:
SMEs (Small businesses, 1-30 employees) — The Strategic Co-Founder You Can Afford:
– Can’t afford marketing agencies or consultants
– Don’t have strategic marketing expertise
– Need quick wins without the learning curve
Agencies (Managing 5-15+ clients) — Scale Your Strategic Capacity, Not Your Headcount:
– Drowning in strategy work across multiple clients
– Need consistent frameworks that scale
– Require complete data isolation between clients
Why agencies? Because I spent 20 years on the agency side. I know the pain firsthand.
I’ve seen strategists juggle 12 clients with 12 different brand guidelines, copying and pasting context between tools, praying they don’t accidentally send the wrong strategy to the wrong client. I’ve watched agencies lose good people to burnout because there’s no way to scale strategic thinking without scaling headcount.
And honestly? I wanted to challenge myself. Building for SMEs alone would be simpler—one user, one organization, straightforward routing. Building for agencies meant multi-client dashboards, data isolation, role-based permissions, client-scoped everything.
I wanted to build something complex. Something that actually solved the hard problems I’d seen for two decades.
The Day 2 Realization: You Can’t Retrofit Multi-Tenancy
Here’s what I understood on Day 2, staring at my simple data model:
SME architecture (what I had):
```
users → campaigns → agent_outputs
```Multi-tenant architecture (what I needed for agencies):
```
organizations (SME or AGENCY)
↓
clients (agencies only)
↓
campaigns
↓
agent_outputs (with org_id AND client_id)
```The difference isn’t just “add a few columns.” It’s a fundamentally different data model.
If I built for SMEs first and added agency support later, I’d be looking at:
– Migrating every existing table to add `org_id`
– Retrofitting RLS policies across the entire database
– Rewriting frontend routing for client context
– Re-testing everything with multi-tenant scenarios
That’s not a feature addition. That’s a rewrite.
The longer I waited, the more expensive the retrofit. Day 2 was cheap. Day 60 would be painful. Day 200 would be “maybe we just build a separate product for agencies.”
So I made the call: build multi-tenant from Day 2, or accept that agencies would never be first-class citizens.
The Trade-Offs: What Multi-Tenancy Actually Costs
Here’s the part where I should’ve paused and asked myself: “Are you sure about this? You have ONE working agent. ONE.”
But I didn’t pause. Instead, I started writing SQL schemas like a madman. Multi-tenancy on Day 2 meant accepting costs that would make any reasonable person reconsider:
Cost 1: Development Complexity (3X)
Every table needed `org_id`. Agency tables needed `client_id`. RLS policies needed both filters. Every query, every API endpoint, every frontend route—all had to be multi-tenant aware.
Estimated complexity increase: 3X development time for same features.
(Spoiler: It was actually closer to 4X. I underestimated. Classic me.)
Cost 2: Extended Development Timeline
Building for both audiences from Day 1 meant a longer path to launch. Here’s what that looked like:
Timeline:
– August 20: Started building (multi-tenant from Day 1)
– September 15: 4 weeks in, 3 agents working, targeting October
– October: Got sick for 10 days, couldn’t code
– November 5: Private Alpha launch (75 days total)
What multi-tenancy added:
– Schema routing between public and agency tables
– RLS policies on every table (ended up with 83 across 26 tables)
– Client context propagation through every agent
– Dual routing patterns (SME vs agency URLs)
Would I have launched faster with SME-only architecture? Probably 3-4 weeks faster. But then I’d be staring at a rewrite when agencies came knocking.
Cost 3: Security Requirements (Higher Risk)
SME data isolation is table-stakes. Agency data isolation is mission-critical.
Requirements added:
– 83 RLS policies across 26 tables
– Schema-level isolation (public vs agency schemas)
– Database router functions for every CRUD operation
– Comprehensive audit logging
– Multi factor authenticator option
Security complexity: 5X higher than SME-only.
I spent more time on Row-Level Security policies than on actual AI agent development some weeks. Let that sink in.
Cost 4: Testing Complexity (2X Test Cases)
Every feature needed testing for:
– ✅ SME flow (simpler)
– ✅ Agency flow (client-scoped)
– ✅ Data isolation (Nike ≠ Adidas)
– ✅ Permission boundaries (can agencies see SME data? No.)
Test maintenance: Doubled.
You know what’s fun? Writing the same test twice with slightly different contexts. Said no one ever.
—
Why I Made the Trade-Off Anyway
So let me get this straight: 3X complexity, extended timeline, 5X security overhead, doubled testing… and I still did it?
Yeah. Here’s the thinking (such as it was):
Reason 1: Retrofitting Is a Nightmare
Day 2: Almost no code written. Data model still flexible. No users to migrate.
Day 60: 45 tables, 200k lines of code, 15 alpha users. Adding multi-tenancy would require rewriting half the codebase.
Lesson: Architectural decisions get exponentially harder to change over time.
Cost on Day 2: ~5 hours to redesign data model.
Cost on Day 60: ~200 hours to refactor everything.
I’ve seen companies try to retrofit multi-tenancy. It’s brutal. You’re basically rebuilding the plane while flying it. With passengers. Who are paying you.
Reason 2: I Actually Understand Agencies
This wasn’t theoretical market research. I spent 20 years watching agencies struggle with exactly this problem.
I know they need:
– Complete data isolation (client 1 can’t see client 2’s strategy)
– Client-scoped everything (brand guidelines, personas, campaigns)
– Role-based access (account managers vs strategists)
– White-label potential for client presentations
I could build this right because I’d lived the pain. That’s not an advantage I wanted to waste by shipping SME-only and “adding agencies later.”
Reason 3: The Challenge Was the Point
Here’s something I don’t say often: I *wanted* the complexity.
I’m a middle-aged founder with a family, not a 22-year-old who can survive on energy drinks and no sleep. If I’m going to spend a year building something, it better be something that challenges me. Something I’m proud of technically.
Multi-tenant architecture with proper data isolation, RLS policies, schema routing—that’s hard. That’s interesting. That’s the kind of engineering problem that keeps me engaged at 2 AM.
Building SME-only would’ve been faster. But would I have been as motivated to push through the hard parts? Probably not.
Reason 4: Both Audiences Make Each Other Better
SMEs and agencies aren’t competing use cases. They’re complementary:
– Agencies validate the product: If agencies trust it with client data, SMEs will too
– SMEs provide volume: More users means more feedback, faster iteration
– Architecture serves both: Team accounts, role permissions, and white-label work for both audiences
Building for both meant building the *complete* solution, not a simplified version I’d outgrow.
Reason 5: Future-Proofing
Even beyond agencies, multi-tenancy architecture enabled:
– Team accounts (SMEs with multiple users)
– Reseller partnerships
– White-label opportunities
– Enterprise sales (if we ever wanted to go there)
Option value: Multi-tenancy unlocked business models I couldn’t even envision on Day 2.
The Implementation: What Day 2 Architecture Decisions Looked Like
Here’s what I actually built on August 21:
Database Schema (Core Decision)
```sql
-- Organizations table (SME or AGENCY)
CREATE TABLE organizations (
id UUID PRIMARY KEY,
name TEXT,
type TEXT CHECK (type IN ('SME', 'AGENCY')), -- Critical distinction
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Clients table (agencies only)
CREATE TABLE clients (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id), -- Which agency owns this
company_name TEXT,
slug TEXT UNIQUE, -- For URL routing
created_at TIMESTAMPTZ DEFAULT NOW(),
-- Constraint: Only agencies can have clients
CONSTRAINT clients_agency_only CHECK (
(SELECT type FROM organizations WHERE id = org_id) = 'AGENCY'
)
);
-- Campaigns table (multi-tenant aware)
CREATE TABLE campaigns (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id), -- Always required
client_id UUID REFERENCES clients(id), -- Required for agencies, null for SMEs
name TEXT,
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Agent outputs (multi-tenant + client-scoped)
CREATE TABLE agent_outputs (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id),
client_id UUID REFERENCES clients(id),
campaign_id UUID REFERENCES campaigns(id),
agent_type TEXT,
content JSONB,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```Key decisions on Day 2:
– `org_id` on every table (enables RLS)
– `client_id` nullable (SMEs don’t have clients)
– `type` discriminator on organizations (SME vs AGENCY)
– Constraint: Only agencies can create clients
Row-Level Security (Day 2 Planning)
```sql
-- RLS policy for campaigns (multi-tenant isolation)
CREATE POLICY campaigns_org_isolation ON campaigns
FOR ALL TO authenticated
USING (
org_id = get_user_org_id() AND
(client_id IS NULL OR client_id IN (SELECT id FROM clients WHERE org_id = get_user_org_id()))
);
```This policy ensures:
– ✅ Users only see campaigns from their organization
– ✅ Agency users can’t see SME campaigns
– ✅ Agencies can’t see each other’s clients
Cost: Wrote 5 initial RLS policies on Day 2. Eventually grew to 83 by launch.
URL Routing (Multi-Tenant from Day 1)
```typescript
// Frontend routing structure (planned Day 2)
// SME routes (simple)
/campaigns/:campaignId
/agents/strategy/:campaignId
// Agency routes (client-scoped)
/clients/:clientSlug/campaigns/:campaignId
/clients/:clientSlug/agents/strategy/:campaignId
```This URL structure enabled:
– ✅ Client context in every URL (agencies)
– ✅ Clear separation between SME and Agency flows
– ✅ Bookmarkable, shareable URLs
– ✅ Analytics tracking per client
The Results: Did It Pay Off?
Launch date: November 5, 2025 (75 days from start)
Development overhead from multi-tenancy:
– Schema design and migrations
– 83 RLS policies across 26 tables
– Database router functions
– Dual routing patterns (SME vs agency URLs)
– Client context propagation
With Claude Code and Gemini 2.5 Pro, the actual coding went faster than it would have solo. But debugging RLS policies that *should* work but don’t? That’s still painful at 2 AM regardless of AI assistance.
What I have now:
– Complete data isolation between organizations
– Agency-ready architecture with client scoping
– 83 RLS policies across 26 tables
– Schema-level routing (public vs agency schemas)
– White-label potential built in from Day 1
– A product that can genuinely serve both SMEs and agencies
Worth it?
Ask me in 6 months when I have actual customers paying actual money. Right now I’m in private alpha with 15+ users, still learning what works and what doesn’t.
But here’s what I know: I have the architecture to serve both audiences properly. If I’d built SME-only and tried to add agencies later, I’d be staring down a 3-month rewrite right now. Instead, I’m focused on product-market fit, not architectural debt.
That feels like the right trade-off.
The Framework: When to Build Multi-Tenancy Early
Not every product needs multi-tenancy on Day 2. Use this framework:
Build Multi-Tenancy Early If:
✅ Target market includes agencies/resellers (higher value per customer)
✅ Data isolation is critical (legal/compliance requirements)
✅ B2B with team accounts likely (Slack, Figma model)
✅ White-label opportunities exist*(reseller GTM strategy)
✅ Enterprise sales is possible (need multi-client from Day 1)
Skip Multi-Tenancy Early If:
❌ B2C product (individual users, no organizational hierarchy)
❌ MVP needs speed (test product-market fit first)
❌ No team/agency use case (single-player tools)
❌ Simple data model (adding org_id later is easy)
❌ Solo founders learning (complexity may be too much)
Lessons Learned: Build for Your Expertise
1. Audience Knowledge Should Drive Architecture
Don’t design for hypothetical users. Design for users you actually understand.
My advantage: 20 years of agency experience meant I knew exactly what agencies needed—data isolation, client scoping, role-based access.
Wrong approach: “Let’s build for SMEs first and add agencies later when we understand them”
Right approach: “I already understand agencies. Build for them now while it’s cheap.”
If you have deep expertise in a market segment, use it. Don’t defer to “simpler first.”
2. Early Complexity Beats Late Refactoring
Day 2 architecture cost: 5 hours to redesign data model.
Day 60 architecture cost: 200 hours to refactor everything.
40X difference.
If you’re 80% sure you’ll need multi-tenancy, build it early. The longer you wait, the more expensive it gets.
3. Technical Challenge Can Be Motivation
This one’s personal: I *wanted* to build something hard.
Multi-tenant architecture with RLS policies, schema routing, and proper data isolation—that’s interesting engineering. It kept me engaged through the hard parts.
If you’re a solo founder, don’t underestimate motivation. Building something that challenges you might be worth more than shipping faster.
4. Architecture Enables Business Models
Multi-tenancy wasn’t just a technical decision. It enabled:
– Agency pricing tiers (whenever I figure out pricing)
– White-label opportunities
– Enterprise sales potential
– Team accounts for SMEs
Architecture = business optionality in code form.
5. Solo Founders Can Build Multi-Tenant
“Multi-tenancy is too complex for one person” → False.
With modern tools (Supabase RLS, database functions, AI-assisted development), solo founders can build enterprise-grade multi-tenancy.
Time cost: 70 days (part time).
What you get: Real data isolation, not a hack you’ll regret later.
Worth it if you’re serious about serving both audiences
Final Thoughts
Day 2 was way too early to know if STRAŦUM would succeed. I had one agent. No users. No validation. Just 20 years of agency experience telling me what agencies actually need.
The extended timeline felt painful at times. Watching other launches while I was still debugging RLS policies and writing database router functions? Frustrating doesn’t begin to cover it. There were days I questioned whether the complexity was worth it.
But here’s what I know now: building for both audiences from Day 1 was the right call. Not because of some clever unit economics calculation—I still don’t know what pricing will work. But because I have the architecture to actually serve both audiences properly.
Multi-tenancy on Day 2 wasn’t just a technical decision. It was a bet on building for users I actually understand, not hypothetical users I’d figure out later.
Did that bet pay off?
I’m still in Private Alpha with 15+ users. I don’t have the answer yet. But I can tell you this: when an agency reaches out and asks “can we use this for multiple clients with proper data isolation?” I can say yes. I don’t have to say “we’re working on that.”
That feels like the right foundation.
Time will tell if I was ambitious or just stubborn. (Probably a bit of both, honestly.)
—
Building a multi-tenant SaaS? STRAŦUM’s architecture supports both SME and Agency customers from Day 1. Request alpha access at https://stratum.chandlernguyen.com/request-invitation
—
Still learning that architecture decisions are business decisions in disguise. Still debugging RLS policies. Still questioning my Day 2 choices (but less so now). More building adventures at https://www.chandlernguyen.com/.
—