Building integrations in-house and other horror stories

Since we started Truto in January 2023, I have watched the B2B SaaS market closely. I have seen hundreds of startups raise money, launch ambitious products, and fight for market share. I have also watched many of the companies that chose to build their own integrations in-house quietly die.

If you are trying to settle the build vs buy SaaS integrations debate, here is the blunt answer: if the integration is not a core part of why customers pick your product, buying usually wins. Build only when the connector itself is part of your moat, when you need deep workflow control a vendor cannot handle, or when security and regulatory constraints leave you no choice.

Not pivot. Not get acqui-hired. Gone.

This isn't an edge case. It's a pattern. And the pattern always starts with the same six words: "We can just build that ourselves."

I am not saying engineers can't build it. They can. That is not the question. The question is whether you want your best engineers spending the next year on vendor API drift instead of shipping the product customers actually pay for.

The Ultimate Metric: Survival and Opportunity Cost

22% of startups fail due to lack of focus. That stat from CB Insights has been floating around for years, but it never fully clicked for me until I started seeing it play out in real time with product integrations.

The market pressure is absolute. PartnerStack's 2024 integrations research found that 92% of respondents who could assess churn said integrations reduce churn. You need integrations to survive. But how you acquire them dictates whether you scale or stall.

Scale makes this worse. Okta's Businesses at Work data shows the global average organization uses 101 apps, while large companies average 231. So when your team says, "we only need a few connectors," ask a better question: for how long? Product integration demand only ratchets in one direction.

When you evaluate build vs buy for SaaS integrations, you are not just comparing software licensing costs against engineering salaries. You are measuring opportunity cost. Every sprint your lead engineer spends mapping custom fields for a HubSpot sync is a sprint they are not building the features your customers actually pay you for.

The "Weekend Project" Illusion

Engineers are brilliant, optimistic problem solvers. They get excited by new technology and love building things from scratch.

Recently, one of our rockstar engineers got excited by some new AI tools. He looked at me and said we could build a Cal.com alternative or a fully functional CRM "over a weekend."

I smiled, but I knew the truth. The initial build is never the real issue. The initial build is a trap.

When a product manager asks for an integration, developers typically look at the vendor's API documentation. They find the exact endpoints they need, estimate the time to write the HTTP requests, and say, "Give me a few days. It is just a few API calls."

Here is the code engineers point at when they say, "it's just a few API calls."

The problem is that this kind of snippet is a lie by omission. The initial HTTP request is the visible 10% above the water. The remaining 90% lives below the surface, ready to sink your product roadmap. The ugly part lives outside the demo:

• Rate limit backoff: Salesforce tracks API usage over a rolling 24 hours, and paid orgs start with a daily API request limit of 100,000 before hitting protection thresholds and throwing REQUEST_LIMIT_EXCEEDED errors.
• Blind spots: HubSpot's search endpoints do not return standard rate limit headers, meaning your generic retry logic can be blind right where teams expect visibility.
• Pagination quirks: Zendesk supports both cursor and offset pagination, but explicitly recommends cursor pagination. That is one more vendor-specific branch in your abstraction.
• Batch throttling: Microsoft Graph can throttle individual requests inside a batch and tells clients to honor Retry-After. Even your batching logic needs vendor-aware failure handling.
• Authentication complexity: Google says apps requesting sensitive or restricted scopes may need verification. You have to handle OAuth 2.0 token rotation, refresh flows that silently expire, and vendors that change auth requirements without warning.

And then there is schema normalization. As we covered in our deep dive on why schema normalization is the hardest problem in SaaS integrations, standardizing data across disparate platforms is a nightmare. What Salesforce calls a "Contact", Zendesk calls a "Requester", and Jira calls an "Assignee".

The Real Cost of Building SaaS Integrations In-House

Let us look at the actual math behind in-house software development costs. The cost of building integrations is not the first sprint. It is the permanent tail.

Across this category, industry data shows that maintaining a single custom integration costs engineering teams between $50,000 and $150,000 annually. As we broke down in our analysis of the true cost of building SaaS integrations in-house, this figure accounts for QA testing, server monitoring, handling undocumented API changes, and the inevitable 3 AM pages when a vendor's OAuth endpoint goes down.

Here is the math most teams avoid:

If you want a simple calculator, start by multiplying your number of active integrations by a realistic annual maintenance range ($50k–$150k per connector).

That table only applies the maintenance range. It does not include PM time, QA, customer support, on-call interruptions, re-auth UX, migration work when APIs deprecate, or the feature work you did not ship because your engineers were busy babysitting connectors.

Building in-house creates a permanent infrastructure burden. Research shows that ongoing maintenance typically consumes 10% to 20% of a developer's time indefinitely. That is one day a week, every week, lost to debugging third-party webhooks.

Worse, this shifts your entire business model. You stop being a high-margin software company and become a low-margin dev shop. You report the integration work as "Product Engineering" on your P&L, but it behaves like professional services. Smart investors see right through it.

The Bottleneck Reality: When Engineers Become Internal Support

The real tax of in-house builds is not code. It is dependency. I learned this the hard way with an internal project right here at Truto.

I am a non-technical founder. A while back, one of our engineers built a quick internal script to fetch data for our outbound campaigns. It pulled the data we needed and helped our sales motion. It worked perfectly on day one, and I was thrilled.

Then reality hit. A week later, I needed to add a new column to the output to track a different metric. I could not do it myself. I had to go back to the engineer.

A month later, the external API we were pulling from changed its rate limits without warning. The script broke entirely. I had to file an internal ticket and wait for the engineer to pull away from building Truto's core features just to fix my sales tool.

Suddenly, a highly paid, brilliant engineer became a bottleneck for basic sales operations. They became glorified IT support.

This happens at scale with product integrations. An enterprise customer asks for a new custom field to be synced to their ERP. The product manager writes a ticket. The engineering team pushes it to the next quarter because they are busy fixing a critical bug in the core product. The customer gets frustrated, feels ignored, and churns.

McKinsey noted that "Some companies find that actively managing their tech debt frees up engineers to spend up to 50 percent more of their time on work that supports business goals." That is the flip side: when you stop making your engineers do undifferentiated integration work, they become dramatically more productive on the stuff that actually matters.

How Product Managers Can Win the Build vs. Buy Argument

Product managers constantly battle their engineering teams over the unified API vs custom integration debate. Engineers naturally want control. They want to own the code base and avoid third-party dependencies.

But PMs do not buy third-party tools because engineering is incapable. PMs buy them to protect engineering time for differentiated work. Buying a tool is not an insult to their technical abilities; it is the ultimate protection of their time.

If you need a fast decision framework, use these five questions:

1. Is this integration a top-3 reason customers buy us, renew, or expand?
2. Does owning this connector create defensible IP, or is it table stakes?
3. Will non-engineers need to tweak mappings, fields, or workflows after launch?
4. Do we need dozens of connectors in the same category, or just one strategic integration?
5. What core roadmap items will slip if we build this ourselves?

If the honest answers are 'table stakes,' 'lots of connectors,' and 'non-engineers will need changes,' buying is usually the rational call.

Then pick the right model. As outlined in our breakdown of the 3 models for product integrations, you have architectural choices:

• Direct integrations (build): Full control, highest maintenance cost, slowest time-to-market.
• Unified API (buy): One integration gives you access to hundreds of platforms, with trade-offs on depth and customization.
• Embedded iPaaS (buy): Visual workflow builders for custom logic, with trade-offs on engineering control.

Where Truto Fits (and Where It Doesn't)

I would be dishonest if I didn't acknowledge the bias here. I am the co-founder of an integrations company. So let me be transparent about both what Truto does well and where the trade-offs are.

We built Truto because I hated the false choice between rigid unified APIs and engineering-heavy, one-off connector work. Truto is a Unified API that normalizes data across hundreds of SaaS platforms, specifically designed to solve the friction between PMs and developers:

• Service-first integrations: We build integrations according to your roadmap, not ours. Customers like Sprinto have asked for a new connector on a Tuesday and had it live by Friday for a critical demo with a key enterprise prospect.
• Zero-code architecture: PMs can add new integrations instantly without waiting on engineering sprints. You authenticate, you map the data, and you are live.
• Programmable JSONata mapping: We handle complex schema normalization natively. Unlike rigid 1:1 unified APIs that force you to conform to their limited models, our programmable mapping lets you handle deep, custom edge cases without writing backend code.
• Real-time proxy architecture: We fetch data instantly without storing your customer data unnecessarily. We do not hoard your data in our databases, which keeps your security and compliance teams happy.
• Built-in resilience: We natively handle the undocumented API rate limits, the bizarre pagination quirks, and the silent upstream changes that constantly break custom builds.

The trade-off is also real: when you proxy live data, you inherit upstream latency and still need to respect the source API's limits. If you need extremely deep, platform-specific functionality that goes way beyond standard CRUD operations, you may still need some direct integration work.

But the question is whether that last 5-10% of edge case coverage is worth the 90% of undifferentiated work you'd take on by building everything yourself.

What I Would Do as a PM

The most expensive phrase in SaaS is not "we need to pivot." It is "we can just build that ourselves."

If you want to fix this in your organization, do this on Monday morning:

1. List every integration request from the last 6 months.
2. Mark each one as moat or table stakes.
3. Put a maintenance range ($50k-$150k) next to each request, not just a build estimate.
4. Ask what core roadmap item loses if you build it in-house.
5. Buy anything that fails the moat test. Build only the few that define the product.

Every time you choose to build a non-core feature, you are actively choosing to slow down your company's growth. Stop letting your engineering team build custom integrations. Protect their time. Protect your roadmap. The survival of your company depends entirely on your ability to focus on what actually matters.