Bridge
The connector stitching ecosystems together through integrations.
The Pattern
What the Bridge pattern is
Getting two existing systems to work together is what a Bridge does, and it gets paid on the traffic that moves between them. Each crossing earns very little on its own, but together they add up to real revenue. A toll bridge works the same way, with traffic in both directions and drivers who barely notice the toll. Customers do notice the day the connection goes down, and that's when they start looking for another way to connect.
Think: Zapier, Plaid, IFTTT, Twilio, early Stripe, Segment, MuleSoft.
The Engine
How it makes money
A Bridge stands or falls on its integration layer: the standard API (application programming interface, the way two pieces of software talk to each other) or connector that turns two systems that don't talk into one workflow. The quality and reliability of each connection count for much more than how many you have. If uptime slips or a single connector breaks, customers stop trusting you quickly.
A Bridge connects two groups that depend on each other, and it does that by integrating systems that already exist rather than inventing a new product. Customers pay it to take the friction out of getting those systems to work together. The Bridges that win are the most reliable and complete option in their category, and also the most boring one.
The Discipline
Operating principle
The platforms you connect can change their APIs or their pricing, and they can even take over what you do entirely. So a Bridge depends on diplomatic skill with those platforms as much as it depends on engineering. Reliability is really what customers are paying for, and the other features matter far less to them.
Sitting between two ecosystems makes you indispensable, but it also leaves you exposed when either side changes its policies. So we'd invest in observability (monitoring that shows what's failing and why), incident response and uptime the same way you'd invest in product features.
Healthy
Being boringly reliable is what healthy looks like, because a Bridge is infrastructure and any surprise counts as a failure.
Unhealthy
The weakness is depending on the platforms it connects, so the business model can shift overnight if they raise prices or change their terms. Losing access to one of those platforms can do the same thing.
A customer using 5 integrations is 10x stickier than one using 1, which is why depth matters more than the connector count.
What Works & What Breaks
Healthy vs. breaking
What healthy looks like
What breaks it
The Profile
Profile
Best Fit Founder
This model suits a systems engineer who's deeply technical and thinks in terms of infrastructure. They're good at partnerships and they're patient. They also have the discipline to turn down new features when reliability needs the attention.
Go-To-Market
Growth is developer-led or product-led, and there's a sales team only at the enterprise tier. The standard approach is self-serve documentation and a generous free tier, with paid plans that kick in based on usage. Adoption starts from the bottom up, with an engineer integrating for free, hitting a limit and then getting the team to upgrade.
Ideal Focus
What matters most is owning the critical connectors your target market cares about, whether those are APIs or middleware (software that sits between systems and passes data along). Three things build on each other here: reliability, coverage of the integrations that matter and the developer experience. That takes discipline, because feature creep that doesn't make the Bridge itself stronger spreads out the engineering investment that keeps you ahead. We'd ask the same question about every decision: does this make us more dependable for the workflows customers already trust us with?
Revenue Pattern
Revenue is recurring, and it grows as the ecosystems on both sides grow. The standard model is a hybrid, with a subscription floor plus usage-based fees on top. In healthy Bridges, net revenue retention typically runs 110-130%.
Unhealthy Signs
Risk, Speed & Burnout
Sales Cycle
Self-serve is instant, and a developer can be paying within minutes of finding the docs. Mid-market deals close in 30-90 days. Enterprise cycles run 6-12 months, because they go through security review, SOC 2/ISO audits (third-party security certifications) and procurement.
Hiring Sequence (first 5 after founder)
- Founding/Senior Backend Engineer: obsessed with reliability, and owns the core platform
- Developer Relations (DevRel) lead: runs the community and the docs, and does the evangelism
- Integration Engineer: the specialist who adds new connectors
- Site Reliability Engineer (SRE) / Platform lead: owns uptime, because uptime is the product
- Solutions Engineer: supports the enterprise sales motion
Under the hood it's webhook infrastructure and queueing systems like Kafka or SQS, plus observability tooling and API gateways. A Bridge also handles OAuth (the standard way a user lets one app access another) at scale, and keeps audit logs.
Long, focused blocks of engineering fill most of the week, broken up by incident response. Day to day it's calmer than a Bazaar, but it gets intense the moment something breaks.
Leading KPIs
- Integration count - how far the Bridge reaches across the ecosystems you serve. It's the surface area of your value, though depth matters more than count.
- Integration uptime / error rate per connector - each connector is its own reliability commitment, and one broken connector makes customers trust the whole platform less.
- Active users % - free-tier and trial users only matter if they turn into active usage. Signups are vanity, and active usage is what's real.
- API calls per month - the truest measure of how much customers depend on you, and the input to usage-based revenue.
- Number of active integrations per customer (depth of embed) - a customer using 5 integrations is 10x stickier than one using 1, so depth predicts retention.
- Net revenue retention (NRR) - 110%+ is the threshold for a healthy Bridge. Below 100% means the model is leaking faster than it's expanding.
- Gross margin % - cloud infrastructure cost as a % of revenue decides how scalable the model really is.
- Retention % - gross logo retention (the share of customers who stay, whatever they spend) separates true infrastructure from convenient tooling that gets ripped out under pressure.
- ARPU (average revenue per user) - this is the tell for moving upmarket, because it shows you capturing more value per customer over time.
- Time-to-first-successful-call for new developers - how fast developers get activated is a leading indicator of conversion and product-market fit. If it's slow, a lot of them churn before they ever pay.
Feature Focus
It connects two different customer types that depend on each other.
It depends on outside ecosystems and carries reputation risk.
CFO Watchpoints
What to watch
Defense
Defensibility
Customer concentration is usually moderate to low. On the integration side it's severe, because losing one upstream API can hurt thousands of customers at once.
Each niche ends up dominated by one player (Plaid in bank connections, Twilio in SMS, Stripe in payments), though the niches are narrower than they look. Open-source alternatives turn the simple connectors into commodities first. The hardest pressure comes from the platforms themselves, when they vertically integrate and build the connector natively.
A Bridge has four moats, and none of them is enough on its own: switching costs, the breadth of its integrations, its relationships with upstream platforms and its engineering investment. Of the four, the years of engineering work on hundreds of edge cases go the deepest, because a competitor would have to redo that work from scratch.
Switching away is very expensive. Once a Bridge is in production, ripping it out means rewriting workflows and retraining ops teams, and then earning back the engineers' trust. Most customers stay, even while they grumble about pricing.
Financial Impact
The money
Impact
Margins are high and the revenue recurs, though it depends on outside ecosystems staying stable. You get software margins, and customers stick the way they stick to infrastructure, which makes it one of the most attractive financial profiles in business.
Target P&L Allocation
| Category | Target |
|---|---|
| Client Acquisition / Ad Spend | 20% |
| Total Labor | 20% |
| Fixed Overheads & G&A | 28% |
| Legal & Professional | 5% |
| Operating Income (EBITDA) | 22-27% |
High-margin software economics; track partner dependence concentration
Source: Compass archetype one-pager, target allocation as a percent of revenue
DevOps and API engineers are on salary plus a bonus for uptime and for meeting the SLA (service level agreement, what you've promised customers on uptime and response). It's tied to error rates and incident response time. We'd pay it for sustained performance over a quarter or a year, rather than just for a stretch with no incidents. On-call rotation premiums matter for keeping people, because burnout here is the top cause of senior engineers leaving.
Partner managers and enterprise AEs (account executives) get a base salary plus a quarterly kicker on MRR (monthly recurring revenue) and usage growth, tied to API adoption rather than just to the contract being signed. Enterprise reps earn a 40/60 base/commission split, with accelerators (higher commission rates past a target) for multi-year contracts and for customers using more integrations. Self-serve revenue is credited to marketing and product, so it isn't part of sales comp.
Chargeback risk is low. It's B2B SaaS (business software sold by subscription) on annual contracts, so refunds get negotiated instead of charged back. Bad debt is typically under 1%.
Working capital need is modestly positive. Annual prepayments help, but engineering payroll is the biggest cash outflow, whatever the timing of revenue.
Revenue Quality Score
9 / 10. It recurs and it's sticky. It's also high-margin, and it expands with usage. The only deduction is for platform dependency risk, and otherwise it's one of the most CFO-friendly models there is.
Trajectory
Where this goes
A Bridge can only grow as big as the ecosystems it connects and as fast as they grow, so it plateaus when both sides do. At maturity the only way forward is adjacent expansion, meaning new integration types, new categories or workflow tooling. Most Bridges hit their ceiling because the engineering complexity outpaces revenue.
Pivot difficulty is moderate. A Bridge can extend up the stack into workflow automation on top of its integrations, the way Zapier did, or down into managed services for enterprise customers. A true pivot is hard, because the engineering investment is specific to each integration.
One exit is a strategic acquisition by a platform that wants the integration footprint. Visa tried to buy Plaid for $5.3B, and Salesforce bought MuleSoft for $6.5B. The other is an IPO (initial public offering) at scale, like Twilio. Either way the multiples are premium, because the revenue quality is so high.
Common Founder Failure Modes