Integrations from Zero: Build vs. Buy

Senior Engineering Manager, Application Platform·2026·Ongoing·3 people·5 min read

Owned the build-vs-buy evaluation for a new integrations platform against a $500K+ ARR pipeline gap, made the call to build, and began standing up the founding team.

Overview

Stood up a greenfield integrations and APIs function after deals were lost over missing connectors. Ran the build-vs-buy evaluation between adopting an integration-platform vendor and building the abstraction in-house, then defined the team and roadmap to close the gap.

Problem

Missing integrations were costing real revenue. More than $505K in ARR was lost or at risk across several enterprise deals that needed connectors the product didn't have, and integration gaps showed up in roughly a quarter of lost deals. The product had five production integrations while competitors had dozens to hundreds. There was no team, no platform, and no roadmap for closing the gap.

Constraints

  • Revenue was actively bleeding, so the most critical coverage gaps needed stopgap fixes before any platform could exist.
  • Federal deployments couldn't rely on outbound connectivity to a third-party bridge.
  • Customer API keys and secrets couldn't be egressed to an outside vendor.
  • The founding team had to be assembled from a couple of internal transfers plus an incoming senior hire, not a fully staffed org.

Approach

Ran two tracks at once. On the near-term track, put stopgap technical measures in place to close the most urgent coverage gaps and stop the bleeding. On the platform track, ran a structured proof-of-value against a third-party integration platform to test whether buying the abstraction beat building it, made the build-versus-buy call, and defined the long-term team structure, category priorities, and a connector framework to bring new-integration time down from weeks to days.

Key Decisions

Build the integration abstraction in-house rather than adopt a third-party integration platform

Reasoning:

The vendor's abstraction leaked in the proof-of-value: setting something as basic as a ticket priority still required provider-specific terms, defeating the purpose of a universal layer. Performance was poor enough to time out clients, its bridge architecture required outbound connectivity that federal deployments couldn't allow, and routing customer secrets through an outside vendor was an unacceptable risk. The subscription cost couldn't be justified for a tool that added risk without a clear velocity advantage.

Alternatives considered:
  • Adopt the vendor platform and build integrations on top of it.
  • A hybrid model using the vendor for some connectors and building others.

Ship stopgap coverage first, build the platform second

Reasoning:

Deals were being lost in real time. Waiting for a proper platform before addressing any gap would have kept costing revenue for months. Closing the most critical gaps manually bought the time to build the durable thing correctly.

Alternatives considered:
  • Hold off on point fixes and put all effort into the platform from day one.

Invest in a connector framework and treat public APIs as first-class, rather than hand-building each integration

Reasoning:

Hand-building every connector doesn't scale against competitors with hundreds. A framework that brings new-integration time from weeks to days, plus a path for partners to build their own, was the only way to close a gap that large over time.

Alternatives considered:
  • Hand-build each integration as demand arrives.

Tech Stack

  • Python
  • REST
  • GraphQL
  • AWS

Result & Impact

  • $505K+ ARR lost or at risk from missing integrations
    Pipeline gap addressed
  • ~23% of losses cited them
    Integration gaps in lost deals
  • delivered: build in-house
    Build-vs-buy decision
  • 5 production integrations, with a roadmap to 10+ and beyond
    Starting coverage

The evaluation and the build-versus-buy decision were completed and documented, including the cost modeling behind them. The founding team and the multi-quarter roadmap were early-stage at the end of my tenure: the function existed, the direction was set, and the first hires were landing, with the bulk of the integration buildout still ahead.

Learnings

  • A build-vs-buy call on an abstraction layer turns on whether the abstraction actually abstracts; when the vendor's 'universal' interface still leaked provider-specific details, buying it bought nothing.
  • Deployment and security constraints can decide an architecture on their own: a bridge that needs outbound connectivity and handles customer secrets was a non-starter for federal, regardless of features.
  • When revenue is bleeding, the right sequence is stopgap-then-platform; buying time to build correctly is worth more than a clean-but-late platform.

Losing Deals to Missing Connectors

The trigger was commercial, not technical. Enterprise deals were being lost or put at risk because the product couldn’t connect to tools those customers already ran, and the pattern showed up in roughly 23% of every lost opportunity. Five production integrations against competitors with dozens to hundreds was not a gap that point fixes would ever close, and there was no team or platform pointed at the problem.

Two Tracks

Closing a gap that large while revenue was actively leaking meant running two things in parallel. The near-term track put stopgap measures in place against the most urgent coverage gaps, so deals stopped falling through while the real work got underway. The platform track asked the harder question: build the integration abstraction, or buy it from a vendor whose whole pitch was a universal layer over every third-party tool.

The Build-vs-Buy Evaluation

The vendor got a genuine proof-of-value, and it didn’t hold up. The abstraction leaked, setting a ticket priority still meant using each provider’s own terms, so the universal layer wasn’t universal. A single operation was slow enough to time out clients. Its bridge architecture required outbound connectivity that federal deployments couldn’t permit, and it wanted customer API keys routed through an outside service, which engineering wouldn’t accept. Weighed against the subscription cost, none of it justified adopting the platform. The recommendation was to build, backed by cost modeling comparing a native build against the subscription.

Where It Landed

What was delivered was the decision and the plan: the evaluation, the build-versus-buy call, the team structure, the category priorities, and a connector-framework strategy to bring new-integration time from weeks to days. The team itself was still forming as I left, the direction set and the first people arriving, with most of the integration buildout ahead of it.

All projects