A custom web app rarely fails because the software doesn’t work. It fails because the software doesn’t talk to anything else. The orders live in the new system, the customers live in the CRM, the invoices live in accounting, and somebody on the team spends two hours every afternoon copying between them.
That gap almost never shows up properly in a quote. Most vendors price what they can see — screens, user roles, a database — and treat “integrations” as a single line with a round number beside it. If you’re budgeting a project, the sensible approach is to start from a full web app development cost breakdown and then rebuild the integration line yourself, because it behaves differently from every other item on the estimate.
Here’s what actually drives that number.
Why integration estimates miss more often than build estimates
Building a screen is bounded work. The developer controls the code, the framework, and the database. If it takes 20% longer than planned, it takes 20% longer.
It’s also work almost nobody finishes. MuleSoft’s 2026 Connectivity Benchmark Report, based on a survey of 1,050 IT leaders, found that only 27% of applications in the average organisation are actually connected to anything else, and 95% of organisations report running into integration problems. Those are enterprises with dedicated IT departments and real integration budgets. If they’re connecting roughly a quarter of their systems, a ten-person business underestimating the difficulty isn’t careless — it’s the normal outcome.
An integration is not bounded, because half of it belongs to someone else. Your developer doesn’t control the API’s rate limits, its field structure, how it handles duplicates, or when the vendor decides to deprecate a version. The work isn’t “write the connection.” The work is “write the connection, then discover what the documentation didn’t mention, then handle it.”
Vendors know this, which is why integration estimates tend to come with the widest ranges on a proposal. Typical market figures for a CRM or ERP connection run somewhere between $10,000 and $40,000, with payment gateways at roughly $5,000 to $20,000 and analytics tools closer to $2,000 to $8,000. That CRM spread is a factor of four. It’s not vendor evasiveness — it’s the honest range before anyone has looked at your specific CRM instance.
The good news is that the spread narrows fast once four questions get answered.
The four questions that set the price
1. Which direction does the data move?
One-way sync is straightforward: the web app pushes a record into the CRM, and the CRM is the passive receiver. Two-way sync is a different category of work, because both systems can now change the same record.
The moment data flows both ways, someone has to decide what happens when a salesperson updates a phone number on their phone at 2:15 and the web app updates the same field at 2:16. That decision — conflict resolution — is where two-way sync quietly doubles the cost of one-way sync. Ask which one you’re being quoted for.
2. How do the two systems agree on who a customer is?
Your web app might key on an internal ID. Your CRM keys on an email address. Your accounting system keys on a customer code your bookkeeper invented in 2014. None of these match.
Record matching is the least glamorous part of an integration and one of the most expensive. A real customer database always contains the same company under three spellings, an email address shared by two contacts, and a handful of records nobody can explain. Somebody has to write the rules for all of it, and somebody has to clean the existing data before the rules can run.
Budget for this separately. Data migration and cleanup commonly lands in the $5,000 to $30,000 range depending on how tidy the source data is, and “how tidy is it, really” is a question worth asking your own team honestly before you ask a vendor.
3. How fresh does the data need to be?
“Real time” is the default answer and it’s usually wrong. Real-time sync means webhooks, queues, retry logic, and monitoring. A scheduled sync every 15 minutes means a job and a log file.
For most small businesses, most of the time, a 15-minute delay on a CRM contact update costs nothing. A 15-minute delay on inventory availability during a flash sale costs a lot. Decide per data type rather than per system, and you’ll often find only one or two flows genuinely need to be instant.
4. What happens when it breaks?
It will break. The shipping carrier’s API will go down mid-afternoon. The accounting platform will rate-limit you at month end when everyone is syncing at once. A field that was optional last year will become required.
The difference between a cheap integration and a reliable one is almost entirely here: retries with backoff, a dead-letter queue for records that failed, alerting that tells a human something is stuck, and a way to replay the failures once the other system recovers. This work is invisible in a demo and it’s the first thing cut when a quote needs to come down. Ask explicitly whether error handling and monitoring are in scope, because “the integration works” and “the integration keeps working” are priced differently.
Build the connection, or buy middleware?
Before pricing any custom integration work, it’s worth asking whether it needs to be custom at all. There are three routes, and plenty of small businesses reach for the most expensive one by default.
No-code automation tools — Zapier, Make, and similar — connect two systems through pre-built templates and charge per task or per operation. Setup is measured in hours, not weeks, and no developer is required. They’re an excellent fit for one-way flows, moderate volumes, and simple field mapping: push a new order into the CRM, create a contact when a form is submitted, notify a channel when an invoice is paid.
Integration platforms (iPaaS) — Workato, Celigo, Boomi and others — sit a tier above. They handle higher volumes, offer real error handling and retry logic, and can manage genuinely complex transformations. They also cost meaningfully more per month and usually need someone technical to configure and maintain them.
Custom-coded integrations are what the rest of this article has been pricing.
The honest guidance is to start at the cheapest tier and move up only when you hit a wall. The walls are fairly predictable:
- Volume economics flip. Per-task pricing is cheap at 2,000 operations a month and painful at 200,000. Run the arithmetic at your projected volume, not today’s — and remember that a two-way sync counts operations in both directions.
- The logic exceeds what a template can express. Conflict resolution between two systems that both edit the same record, multi-step conditional routing, or matching rules that need to check three fields and a fuzzy name comparison will hit the ceiling of a no-code tool quickly.
- You need real error handling. Most no-code tools will tell you a task failed. Fewer will queue it, retry it intelligently, and let you replay a batch once the other system recovers.
- The connector doesn’t exist. If your CRM is niche, self-hosted, or heavily customised, there may be no pre-built connector — and building one inside a middleware platform is often harder than writing the integration directly.
- You need to own it. A middleware subscription is a dependency. If the platform changes pricing, deprecates a connector, or you simply want to leave, the integration logic doesn’t come with you.
A sensible pattern for a business with several connections is to mix routes rather than standardise on one. The high-volume, business-critical flow — usually orders or inventory — gets custom-built. The low-volume conveniences get a no-code tool. Paying for custom development on a sync that fires forty times a month is money spent on precision nobody will notice.
What each of the three connections tends to involve
CRM. The expensive part is almost never the API — it’s the field mapping and the ownership question. Which system is the source of truth for a contact? If the answer is “both,” you’re in two-way sync territory with all the conflict logic that implies. Custom fields add up quickly, and most CRMs have more of them than anyone remembers creating.
Accounting. The API is usually well-documented and stable. The complexity comes from the domain: tax rules, credit notes, partial payments, multi-currency, and the fact that an accounting system will refuse a malformed transaction outright rather than accepting it and letting you fix it later. Accounting integrations also need to be right in a way that a CRM sync doesn’t — a duplicate invoice is a real problem, not a tidy-up task. That precision requirement is why testing takes longer here than the connection itself.
Shipping. Shipping is the one that looks simplest and generates the most support tickets. Rate quoting, label generation, address validation, tracking webhooks, and returns are five distinct integrations wearing one name. Add a second carrier and you’re not doubling the work exactly, but you are adding a normalisation layer, because two carriers will describe the same service level in two incompatible ways.
Illustrative worked example
A distributor with roughly 40 staff replaces a set of spreadsheets with a custom order portal. Build estimate: $85,000. Integration line on the original quote: $15,000.
What it looked like once scoped properly:
| Item | Range |
| CRM, two-way contact and company sync | $12,000–$18,000 |
| Accounting, one-way invoice push + payment status pull | $8,000–$14,000 |
| Shipping, rates + labels + tracking, two carriers | $10,000–$16,000 |
| Data cleanup and initial migration | $6,000–$12,000 |
| Error handling, monitoring, alerting | $5,000–$9,000 |
| Total | $41,000–$69,000 |
⚠ [VERIFY: figures above are illustrative market ranges, not a documented client project — confirm framing with the editor, or replace with a real anonymised engagement before publishing.]
The integration layer wasn’t 18% of the project. It was closer to half of it. That isn’t unusual for a business that already runs several systems — and a business that runs several systems is precisely the kind that needs a custom app in the first place.
The costs that arrive after launch
Integrations are the part of a web app most likely to need attention in year two, for reasons entirely outside your control:
- API versioning. Vendors deprecate old versions on their own schedule. Migrating a connection to a new API version is real development work with no new features to show for it.
- Rate limits and tier changes. Growth can push you into a paid API tier, or into throttling that requires the sync to be rearchitected.
- Per-connection subscription fees. Middleware platforms and some vendor APIs bill monthly. These belong in your operating budget, not the build budget.
- Monitoring and on-call. Someone has to notice when a sync stops. On a small team, that someone is usually the owner, at the worst possible moment.
A reasonable planning figure for overall maintenance is 15–25% of the initial build cost annually, and integrations consume a disproportionate share of it.
Questions to ask before signing
Take these to any vendor quoting integration work:
- Is each connection one-way or two-way, and what’s the conflict rule for two-way fields?
- What are the record-matching rules, and who is responsible for cleaning source data before go-live?
- Which data flows need real-time sync, and which can run on a schedule?
- Are retries, error queues, and alerting inside this quote or outside it?
- Which API versions are you building against, and what’s the plan when they’re deprecated?
- What are the ongoing subscription or usage fees per connection, forecast over 12 months?
- Who fixes it at 4pm on a Friday, and what does that cost?
A vendor who answers all seven clearly is giving you a number you can plan against. A vendor who reaches for a round figure hasn’t scoped the work yet — which doesn’t make them dishonest, but it does mean the number will move.
The takeaway
Integration cost tracks how messy your existing systems are, not how complex your new app is. Two businesses can order an identical portal and pay a $30,000 difference purely because one has a clean customer database and one doesn’t.
That’s actually encouraging, because the messiness is the part you control. Deduplicating your CRM, standardising customer codes, and deciding which system owns which record are all things you can do before a developer quotes the work — and every hour spent on them comes off an invoice later. Sort out the data before you sort out the connection, and the line item stops being the surprise on the estimate.
Frequently Asked Questions
Can I launch the app first and add integrations later?
Often yes, and sometimes it’s the right call for cash flow. The caveat is that integrations shouldn’t be an afterthought at the design stage even if they’re deferred at the build stage. If the data model is designed without knowing that customer records will eventually sync with a CRM, retrofitting the matching keys later means touching the database and everything that reads from it. Design for the connection early; build it when the budget allows.
Why does two-way sync cost more than twice one-way?
Because it introduces a category of problem that doesn’t exist in one-way. With a one-way push, the receiving system is passive and there’s a single source of truth. With two-way, both systems can change the same field independently, so you need conflict rules, change tracking to know what actually changed since the last sync, and loop prevention so an update pushed to system B doesn’t bounce back and re-trigger system A. That logic has to be designed, built, and tested against edge cases nobody thinks of until they happen in production.
What if my accounting or CRM software has no public API?
You have three options, in descending order of preference: file-based exchange on a schedule, if the system can export and import CSV reliably; a database-level integration, if it’s self-hosted and you can get read access safely; or replacing the system. Screen scraping exists as a fourth option and is genuinely fragile — it breaks whenever the vendor changes their interface. If a core business system has no API, factor a replacement into the conversation, because you’ll otherwise pay for the workaround repeatedly.
How much of my integration budget should go to testing?
More than feels reasonable, particularly for anything touching money. Integration testing needs realistic data volumes, deliberate failure injection, and a sandbox account on the other system. Accounting connections deserve the most, because an error there produces a wrong invoice rather than a stale field — and wrong invoices reach customers.
Do I need every system connected on day one?
Rarely. Rank the connections by how many manual hours each one removes per week, then build in that order. The flow your team currently handles by copying data every afternoon should be first. The one somebody touches at month-end can wait a quarter, and a scheduled export might cover it indefinitely.