Connecting two systems through an API costs $1,500 to $5,000 for a simple one-way sync, $5,000 to $15,000 for a moderate one, and $15,000 to $50,000+ once it’s two-way with real edge cases. A Salesforce-to-HubSpot sync starts around $3,000; a CRM-to-ERP sync runs $10,000 to $25,000. A managed platform to run it all costs more: enterprise iPaaS like MuleSoft starts near $300,000 a year. The build is rarely what hurts. Maintenance is, at 15% to 25% of build cost every year, because APIs change and integrations break.
You probably already know the symptom. Your CRM doesn’t know what your billing system knows. A rep keys the same customer into three tools. Someone exports a spreadsheet every Monday because two systems that should talk don’t. The average company now runs 101 apps, and only 27% of enterprise applications are actually connected to each other. The other 73% are islands, and the bridges between them are what this post is about.
We’re gmware, a software development firm headquartered at 5900 Balcones Drive in Austin, TX, with engineering centers in Bangalore and Mohali, India. We build and run production data-sync systems ourselves: our Shield Suite product pulls retail intelligence across 60,000+ beverage-alcohol storefronts, which means feeds break, vendors change formats, and someone has to be paged when they do. So the “integrations break and somebody has to fix them” section here isn’t theory. Below: the four integration patterns and what each costs, the real projects we get asked for, the build-versus-iPaaS call, and the maintenance reality nobody quotes.
Integration cost, at a glance
What does API and system integration actually cost
Integration cost scales with two things: how many systems you’re connecting, and whether data flows one way or both. A one-way push (new lead in a form, drop it in the CRM) is cheap. A two-way sync (keep the customer record in agreement across CRM, billing, and support, in real time, forever) is a different animal, because now you’re handling conflicts, ordering, and what happens when both sides edit the same record.
Here are the bands for a point-to-point API integration, the most common starting shape:
| Integration depth | What it looks like | Typical cost | Timeline |
|---|---|---|---|
| Simple | One-way sync, 1 to 3 endpoints, standard auth | $1,500 to $5,000 | 1 to 2 weeks |
| Moderate | A few endpoints, light transformation | $5,000 to $15,000 | 2 to 6 weeks |
| Complex | Two-way sync, real error handling and edge cases | $15,000 to $50,000+ | 6 to 16+ weeks |
| Enterprise | Many systems, compliance, high volume | $50,000 to $100,000+ | 3 to 6+ months |
API integration cost by depth
One thing the table hides: these are per-connection prices for the simplest architecture. Wire five systems together directly and you’re not buying one integration, you’re buying ten. That’s the trap the next section is about.
The four integration patterns, and how each one ages
There are really only four ways to connect systems. The difference between them isn’t the first build. It’s how the cost behaves as you add the fifth, tenth, and twentieth system.
Point-to-point is the obvious one: wire each system straight to each other. For two systems it’s perfect, the cheapest and fastest thing you can do. The problem is the math. The number of direct connections follows n(n-1)/2, so 10 systems need 45 connections and 20 systems need 190. Every one of those is code somebody has to maintain. Worse, the systems are coupled: when one system pushes an API update or renames a field, every integration touching it can break. Past about five systems, point-to-point becomes the thing engineers call spaghetti, and they’re not being affectionate.
Hub-and-spoke middleware fixes the math. Instead of every system talking to every other, they all talk to one central broker that does the routing and translation. Now adding a system is one connection, not N. You own and host the middleware, so there’s real upfront engineering, but the maintenance curve flattens out instead of exploding. This is the right answer for most mid-sized companies connecting a handful of systems they expect to keep.
iPaaS (Integration Platform as a Service) is hub-and-spoke that someone else hosts, with hundreds of prebuilt connectors so you’re configuring instead of coding. MuleSoft, Workato, Boomi, and friends. The appeal is speed and managed infrastructure; the catch is the license. MuleSoft Anypoint runs roughly $1,250 per vCore per month on its Gold tier and $1,750 on Platinum, and its Titanium tier starts around $300,000 a year. A real-world Platinum contract came in at $210,000 a year for 4 vCores across 3 environments. The iPaaS market is growing fast, from $13.88 billion in 2025 to a projected $18.72 billion in 2026, which tells you a lot of companies are choosing rent-the-platform over build-it-yourself.
A custom API layer is bespoke integration code you own outright: no per-vCore license, no connector catalog, just engineering tuned to exactly your systems and logic. It’s the right call when an off-the-shelf connector doesn’t exist, the business rules are too specific for a no-code recipe, or the iPaaS license would cost more over three years than the build. The trade is that you own the maintenance too. There’s no vendor SLA to lean on when a downstream API changes; that’s your team or ours.
Why point-to-point stops scaling
Pattern versus cost versus fit: a decision matrix
This is the part most integration guides won’t put on one screen, because it makes the trade-offs obvious. Read across your situation, not down a single column. Most companies end up mixing two patterns, which is fine and usually correct.
| Pattern | Upfront cost | Maintenance burden | Best fit | Where it bites |
|---|---|---|---|---|
| Point-to-point | Lowest: $1.5K to $15K per link | High, and grows with every system | 2 to 3 stable systems, simple syncs | Past 5 systems it’s spaghetti; one field rename breaks several flows |
| Hub-and-spoke middleware | Medium: real build, but reused | Moderate and flat as you scale | A handful of systems you expect to keep | You build and host it; needs an owner |
| iPaaS (MuleSoft, Workato, Boomi) | $25K to $300K+ to stand up, plus license | Low day-to-day; vendor manages infra | Many mainstream SaaS tools with prebuilt connectors | License compounds: MuleSoft Titanium $300K+/yr |
| Custom API layer | Medium to high, scoped to your logic | You own it; predictable if staffed | Logic no connector covers; high volume | No vendor SLA; you fix downstream breakage |
Which pattern fits you
The integrations companies actually ask us for
In practice, the requests cluster. Three jobs make up most of what lands on our desk.
CRM-to-ERP sync. The classic. Sales lives in the CRM, money lives in the ERP, and the two disagree about who the customer is. A custom Salesforce-to-NetSuite-style sync runs $10,000 to $25,000 because ERP data (orders, invoices, products) is unforgiving and two-way. Get an order ID wrong here and finance notices.
Salesforce-to-HubSpot. Common when marketing runs HubSpot and sales runs Salesforce. A basic contacts-companies-deals sync runs $3,000 to $5,000 and a native connector or a light middleware tool often covers it. Add custom objects, lead-routing rules, and activity tracking and it tops $10,000, with fully customized builds past $20,000. This is the case where buying beats building most often, and we’ll say so below.
Getting data out of inboxes and spreadsheets. The least glamorous and the most common. A team runs a critical process through a shared inbox and a Google Sheet that one person updates by hand. There’s no clean API on either end of a human’s habits, so this is part data engineering, part change management. It’s also where the payback is quickest, because you’re replacing labor, not just moving bytes.
A note that applies to all three: AI makes integration more urgent, not less. 82% of IT leaders say data integration is their biggest challenge when deploying AI, because a model is only as good as the data it can reach. If your systems don’t talk, your AI initiative inherits that problem on day one. We unpacked the adjacent build in what it costs to add AI to existing software; the data plumbing there and the integration plumbing here are the same muscle.
Build it yourself, buy iPaaS, or have it built
Here’s an opinion we’ll defend: the most expensive integration mistakes happen at the build-versus-buy fork, not during the build. Pick the wrong pattern and you either drown in license fees you didn’t need or in maintenance you didn’t price.
The honest version of the decision:
- A native connector or a cheap middleware tool wins when you’re syncing two mainstream SaaS apps in a standard way. If all you need is Salesforce-to-HubSpot contact sync, the native connector or a $100-to-$500-a-month middleware subscription is the right answer and paying for a custom build would be silly. We turn these down regularly.
- iPaaS wins when you’re connecting many mainstream tools, the prebuilt connectors already cover them, and you want someone else to host and patch the infrastructure. The license is real money, so run the three-year cost before you sign.
- A custom build (or having us build it) wins when an off-the-shelf connector doesn’t exist, the logic is specific to how your business actually works, the data needs cleaning on the way through, or the iPaaS license would cost more than owning the code. The inbox-and-spreadsheet job almost always lands here.
That first bullet is the one we mean most. If a $5-a-month Zapier-style recipe solves your whole problem, use it. The slice that should call a development firm is narrower: the integrations that touch money or customers, span brittle or legacy systems, or carry logic no connector understands. We make the same call on workflow automation in our breakdown of building it yourself versus having it run for you, and the principle carries straight across.
Why integrations break, and what maintenance really costs
An integration is not a thing you finish. It’s a thing you keep alive. The systems on both ends keep moving underneath it, and none of them ask your permission first. A vendor ships an API version bump. Someone renames a field in the CRM. An OAuth token expires on a Saturday. A downstream service deprecates the endpoint you depended on. Any one of those can take a sync down silently, no error in a place you’d see it, just data quietly drifting out of agreement between two systems until someone downstream notices the numbers don’t match.
This isn’t an edge case. It’s the baseline. 95% of organizations report facing challenges with data integration, and the constant churn of connected systems is most of why. The build was the easy, one-time part. The recurring part is catching failures fast, rotating credentials before they expire, and updating the mapping every time a system changes shape.
Which is why the maintenance number matters more than the build number. Budget 15% to 25% of the build cost per year. On a $30,000 integration, that’s roughly $4,500 to $7,500 a year just to keep it working. Teams that budget zero for this don’t save the money; they defer it into a worse bill later, the one that arrives when a silent failure has been corrupting data for three weeks. We run production data feeds for Shield Suite across tens of thousands of storefronts, and the lesson that buys is simple: monitoring and an owner are not optional line items. An integration nobody watches is an outage waiting for a calendar slot.
Four ways a working integration dies
When you should not build a custom integration
Skip it, or delay it, when any of these hold. There’s no volume behind the data movement (syncing forty records a month saves nobody anything). A native connector already does exactly what you need. The systems on both ends are stable, mainstream, and have clean APIs, in which case a middleware subscription is cheaper than a build for years. Or nobody on your side will own the thing after it ships.
That last one is the quiet killer, same as it is with automation and AI pilots. An integration with no owner becomes shelfware that silently rots, and the cost shows up as bad data nobody trusts. If you can’t name who gets paged when the sync breaks, that’s your signal the integration either needs a managed-service arrangement or isn’t ready to be built. The grim industry pattern, the same ownership-and-data-readiness failure we see across small-business custom software projects, is rarely a technology problem. It’s an ownership problem wearing a technology costume.
How gmware builds and runs integrations
We start by mapping the data, not the code: what lives where, which system is the source of truth for each field, and what happens when two systems disagree. Then we pick the pattern honestly, point-to-point for two stable systems, middleware or a custom layer when the math says so, and we’ll tell you to buy a connector when a connector wins. We build with the boring parts included from day one: retries, error handling, alerting that pages us before it surprises you, and monitoring so a silent failure can’t drift for three weeks. Our integration and data-sync practice runs delivery from Austin with engineering in Bangalore and Mohali, which keeps senior eyes on it during US hours without US-only burn rates.
And when the real problem is upstream, that your data is scattered and dirty before any sync can help, the first project is a data engineering and warehouse foundation, not another point-to-point connection. Syncing dirty data faster just spreads the mess to more systems.
Tell us which systems aren’t talking and whether anyone on your side can own the integration after launch. Reach out and we’ll give you a straight answer on the right pattern, the cost, and the timeline within 48 hours.