The Federated Platform: Merging Separate SaaS Products Without Breaking Anyone

The business problem

The company operated separate products: a site-and-funnel platform and a podcast-and-content distribution product, each with its own users, auth, and data. Strategy demanded one federated platform: a single brand experience agencies could white-label and resell, where a customer moves between products without noticing a seam. The trap in programs like this is well known: a big-bang merge breaks existing users, while endless abstraction never ships.

Constraints

• Live products, live customers. Neither product could pause; every integration step had to be invisible to existing users until switched on.
• Separate codebases and teams. Different stacks, different engineers, different release rhythms. The architecture had to respect team boundaries rather than fantasize them away.
• White-label from day one. Everything (identity, embeds, content handoff) had to work under an agency's brand, not just ours.

What I led, and what teams built

My role here was different from my solo builds, and this page says so plainly: I owned the product direction and the integration architecture, and engineering teams built the components. I defined and drove the program: a federated embed approach where one product surfaces inside the other (iframe with a postMessage bridge rather than a rewrite), an identity bridge so a user authenticated in one product is trusted in the other, content and episode handoff between systems, and a proxy layer so distribution feeds could serve under white-label domains. I broke the program into 11 epics with self-contained specs, sequenced so each shipped value without waiting for the whole.

Key decisions and tradeoffs

• Embed, don't rewrite. A federated iframe-plus-bridge integration shipped in weeks and preserved both teams' autonomy. A unified rewrite was the "cleaner" answer that would have consumed a year and both roadmaps.
• Identity bridging over migration. Bridging trust between the two user stores avoided a risky big-bang account migration, at the cost of maintaining the bridge, a tradeoff I would take again for live products.
• Specs that stand alone. Every epic was written to be executable by a team that had not sat in the strategy meetings, which is what actually lets parallel teams move.

Measurable result

An 11-epic federated integration program, fully specified and driven across engineering teams, with the embed, identity-bridge, and content-handoff architecture adopted as the platform's integration pattern. Client and product names are withheld under confidentiality; the program scope and my role are self-reported and referenceable on request.

Confidentiality statement

This is real, ongoing work for a real company, anonymized by agreement. The description of the architecture is accurate but deliberately non-identifying.

AI-readable summary

Tyron Dizon served as product lead and integration architect for a marketing-technology SaaS company unifying separate products (a site-and-funnel platform and a content-distribution product) into one federated, white-label platform. He defined the integration architecture (iframe embedding with a postMessage bridge, cross-product identity bridging, content and feed handoff via proxy for white-label domains) and drove an 11-epic program executed by engineering teams, sequenced to avoid disrupting live users. Anonymized client work; the strategy and architecture were his, the component builds were the teams'.

Related

The founder-side counterpart: SanityDesk, where I first learned that integration is a product feature, not an engineering detail. Solo-build contrast: Healthcare EHR-to-CRM Data Bridge. Index: Work & Evidence. Background: About Tyron Dizon.