Synthpop’s Approach to Building Reusable Infrastructure for Custom Deployments

In a recent episode of Category Visionaries, Elad Ferber, CEO of Synthpop, confronted a product architecture challenge that kills most infrastructure companies: every customer needs deep custom integration, but building everything from scratch doesn’t scale. The solution required rethinking what “scalable” means when your product’s value comes from depth, not breadth.

The Fundamental Tension

Synthpop’s AI agents achieve 93% autonomous resolution rates because they can execute actions across a company’s entire tech stack. As Elad explains: “We give agents access to all the tools that your support agents have access to. So that means access to Stripe, access to your database, access to your own internal APIs, to Salesforce, to your CRM.”

This deep integration is what separates Synthpop from chatbots that can only respond to text. But it creates an architectural challenge: no two companies use identical tech stacks. One e-commerce company runs on Shopify with Stripe payments and Zendesk support. Another uses custom-built infrastructure with proprietary payment processing and Intercom. A third has Salesforce Commerce Cloud, Braintree, and a homegrown ticketing system.

The naive approach would be to build custom integrations from scratch for every deployment. This maximizes flexibility—you can handle any edge case and unique requirement. But it destroys unit economics. If every customer requires months of custom development work, you can’t scale beyond a handful of implementations annually.

The opposite extreme is forcing standardization. Build integrations for the top 10 platforms and tell prospects they need to use those systems. This scales beautifully but eliminates most of your addressable market and forces customers to adapt their operations to your product rather than vice versa.

Synthpop needed a third path: reusable components that accelerate custom work without eliminating it.

The Modular Integration Architecture

Elad’s team invested heavily in building a library of pre-built integrations for the most common systems. Stripe integration for payment processing. Salesforce and HubSpot connectors for CRM data. Zendesk, Intercom, and Freshdesk adapters for support platforms. Shopify, WooCommerce, and BigCommerce for e-commerce operations.

These aren’t just API wrappers. Each integration encodes domain knowledge about how that system works, what actions are possible, how authentication flows, what rate limits exist, and how to handle error states. When Synthpop deploys for a new customer using Stripe, they’re not starting from zero—they’re starting from a battle-tested integration that’s been refined across dozens of implementations.

But Elad is candid about the limits of standardization: “Every company’s different and has a different tech stack, different tools.” Even customers using the same platforms often use them differently. Two companies both running Stripe might have completely different subscription models, refund policies, and billing workflows. The standard Stripe integration handles the technical connectivity, but customization is still required for business logic.

This is where the architecture’s modularity becomes critical. The standard integrations provide the foundation—reliable connectivity to external systems—while custom development layers on top to handle company-specific workflows, policies, and edge cases. Instead of building a Stripe integration from scratch (weeks of work), the team configures the standard integration for the customer’s specific business rules (days of work).

The Intelligence in Integration Components

What makes Synthpop’s reusable components different from simple API connectors is the embedded intelligence about how to use each system correctly. The Stripe integration doesn’t just expose “create refund” as a function—it encodes knowledge about when refunds are allowed, how to handle partial refunds, what happens with subscription billing cycles, and how to manage failed refund attempts.

This domain knowledge accumulation happens through repeated deployments. The first time Synthpop integrated with Stripe, they learned about edge cases the hard way. By the tenth integration, those edge cases were encoded into the standard component. New customers benefit from lessons learned across previous deployments without Synthpop rebuilding that knowledge each time.

The same pattern applies across all their integration components. The Salesforce connector knows how to query records efficiently, handle pagination correctly, and manage rate limits without hitting API throttles. The Zendesk integration understands ticket status workflows, SLA calculations, and how to preserve conversation threading.

This accumulated intelligence is what transforms reusable components from time-savers into competitive advantages. Competitors starting from scratch need to learn these lessons independently. Synthpop’s components contain years of operational knowledge about how enterprise systems actually behave in production.

The Custom Layer: Where Value Lives

The reusable components handle technical connectivity, but the custom layer is where Synthpop addresses each customer’s unique business requirements. This is where they encode company-specific refund policies, subscription upgrade logic, escalation workflows, and exception handling rules.

This customization work is unavoidable if you’re building AI agents that actually execute business logic rather than just conversing. A refund decision isn’t purely technical—it depends on how long ago the purchase occurred, whether the customer has a history of refund requests, what the product category is, and dozens of other factors that vary by company.

The key architectural decision Synthpop made was accepting this customization requirement rather than fighting it. Instead of trying to eliminate custom work through increasingly complex configuration options, they built infrastructure that makes custom work faster and more maintainable.

Their agent framework allows developers to define custom logic as modular rules that interact with the standard integration components. When a customer needs unique refund logic, that logic gets written once, tested thoroughly, and deployed as a component that the AI agents can invoke. The agents don’t need to understand the business logic—they just need to know when to call it.

How This Affects Implementation Timelines

The modular architecture significantly compresses implementation timelines compared to building everything custom, though it doesn’t eliminate implementation work entirely. For a customer using mostly standard systems—Stripe, Salesforce, Zendesk—deployment might take a few weeks rather than months. The standard components handle 80% of the technical work, leaving custom development focused on business logic and edge cases.

For customers with more proprietary systems or unusual workflows, implementation takes longer. But even then, the standard components for common systems reduce the scope. If a customer uses Stripe and Salesforce but has a custom ticketing system, Synthpop only needs to build one new integration instead of three.

This creates a virtuous cycle. As Synthpop builds more integrations, the percentage of customers requiring entirely custom work decreases. Each new integration becomes a reusable component that accelerates future deployments. The library grows steadily, covering an increasing percentage of the enterprise software ecosystem.

The Margin Math That Makes This Work

Synthpop’s approach only makes economic sense because of how they price and deploy. By charging per resolution rather than per seat, their revenue scales with successful automation, not with the upfront implementation work. This means they can invest more in thorough integration because the payoff comes from long-term usage, not quick deployment.

The deep integration also creates enormous switching costs. Once Synthpop is connected to a customer’s payment processor, database, CRM, and support platform—and once their agents are trained on company-specific policies and workflows—replacing them requires another vendor to replicate all that integration work. Customers essentially never churn because the cost of switching exceeds any realistic benefit.

This switching cost dynamic justifies the upfront investment in deep integration. Synthpop isn’t optimizing for the fastest possible time-to-value. They’re optimizing for the deepest possible value creation, knowing that depth drives retention and expansion revenue over time.

The Strategic Implications

Elad’s architectural choices reveal a broader principle about building infrastructure software: sometimes the “unscalable” approach creates the strongest competitive position. Conventional SaaS wisdom says minimize integration complexity, maximize standardization, and optimize for quick deployments. That works for shallow integrations solving simple problems.

But for infrastructure that needs to execute complex workflows across enterprise systems, depth matters more than deployment speed. The companies willing to invest in deep, custom integration work—while building reusable components that make that work progressively faster—create moats that shallow competitors can’t cross.

This doesn’t mean every infrastructure company should embrace customization. The approach works for Synthpop because their product’s value proposition depends on depth—AI agents that can actually execute actions, not just recommend them. For products where value comes from breadth rather than depth, heavy standardization might be the right choice.

The lesson is about matching architecture to value proposition. If your differentiation comes from doing things other products can’t do, build architecture that enables depth even if it requires custom work. If your differentiation comes from covering more use cases than competitors, build for standardization and configurability. Just don’t confuse the two strategies—they require fundamentally different architectural choices.