Software Integration Cost: The Integration Surface Test for the Scope Proposals Leave Out
Integration is where software budgets quietly break. The Integration Surface Test gives buyers seven questions to price every connection before signing a quote.
Most software proposals contain one line that nobody reads carefully: *Integration with existing systems.* It sits between the screens and the testing, it carries a modest number, and it is where a surprising share of change requests, missed launch dates and strained vendor relationships begin.
The line is not dishonest, just underspecified. It prices the part of an integration that is easy to see, a request goes out and a response comes back, and leaves out the part that consumes the effort: what happens when the response is late, duplicated, out of order, rejected, or refers to a record the other system has never heard of.
This guide is for founders, CTOs and operations leaders commissioning software that must talk to systems they already run. It gives you a checkable way to price that before you sign: the Integration Surface Test.
Why integration is where software budgets break
Three mechanisms explain why integration estimates drift further than any other line in a quote.
**The visible part is the small part.** Calling an API is a few days of work. Making it correct under every condition the two systems can produce is the real job, and those conditions are invisible in a demo. A proposal written from a requirements document sees the call. It does not see the states.
**Half the system belongs to someone else.** Your vendor controls its own code. It does not control your ERP, your payment provider, your warehouse system or the agency that built your CRM customisations. Every integration imports somebody else's design decisions, rate limits, release calendar and support response time into your project.
**Integration failures surface late.** Screens can be reviewed in week two. Integration defects appear when real data meets real volume, usually in the final weeks, when every fix costs most.
None of this argues against integration. It argues for counting it properly. The unit of counting is not "the integration". It is the *surface*: every distinct place where your new software and an existing system have to agree about something.
The Integration Surface Test
For every connection in scope, ask seven questions. A connection where all seven have written answers is priced. A connection with gaps is not priced yet, whatever number the proposal puts next to it.
Which system is the source of truth, and in which direction does data move?
One-way reads are cheap. Two-way synchronisation is a different class of problem, because both sides can change the same record and something has to decide who wins. If the answer is "both systems can edit customers", the scope must say which fields each side owns and what happens on conflict. A proposal that says "sync" without a direction is pricing the cheap version.
How are records matched across systems?
Your new platform calls it a customer ID. The ERP uses an account code. The CRM keys on email address, which changes. Before anything flows, someone has to define the matching rule, the cleanup of existing duplicates, and what happens to records that match nothing. This is often the largest hidden task in the whole integration, and it is data work, not code.
What does the other system guarantee about delivery?
Many systems deliver events "at least once", not "exactly once", and not in order. Stripe's own documentation is explicit on both points: webhook endpoints "might occasionally receive the same event more than once", and Stripe "doesn't guarantee the delivery of events in the order that they're generated" (Stripe webhooks documentation). That is honest engineering, and it means your side must de-duplicate, tolerate reordering and recover missing objects. If the proposal does not mention idempotency or replay, that work is either unpriced or not planned.
What quotas does the connection share, and with whom?
API limits are frequently organisation-wide rather than per integration. Salesforce, for example, states that its limits "are enforced against the aggregate of all API calls made to the org in a 24-hour period" and "are not on a per-user basis" (Salesforce API request limits). The question to settle is how much headroom exists today and what the design does when it runs out: batching, caching, backoff, or a queue.
When a sync fails, who sees it and who fixes it?
Every integration fails sometimes. The difference is whether a failure is a log line nobody reads or a visible queue with an owner, a retry button and an alert. Monitoring, alerting and a reprocessing screen for operations staff are real deliverables. They are also the deliverables most often cut when an integration line was priced too thin.
How does the other side change, and who tells you?
APIs are versioned and retired on the provider's calendar, not yours. Ask which version the integration targets, how breaking changes are announced, and who watches for them after launch. An integration with no named watcher is a scheduled outage with an unknown date.
Can the team actually get access to build and test it?
A sandbox that mirrors production, test credentials, realistic sample data and a contact on the other side who answers questions. Missing any of these turns a two-week task into a six-week wait. Access delays burn calendar time and team cost, and they belong in the plan.
How to count your integration surface before asking for a quote
You can run the test internally in an afternoon, before any vendor is involved.
- **List every connection.** Every system the new software reads from or writes to, including the accounting package, the email provider and single sign-on.
- **Look for the four hidden interfaces.** An API only the vendor can switch on, on the vendor's timeline. A nightly batch export that turns out to be the real interface. A "sync" that is actually a person moving a spreadsheet. An ERP customisation that makes the standard connector useless.
- **Split each connection into flows.** "ERP integration" is not one thing. Orders out, stock levels in and invoices back are three flows with different directions, volumes and failure modes.
- **Score each flow from zero to seven.** One point for every question above that has a written, owned answer.
- **Mark unknowns honestly.** "Probably" scores zero.
The output is a one-page table: flows down the side, seven questions across the top, gaps highlighted. It shows exactly where estimation risk lives. Teams that want help producing it usually start with a short business analysis engagement, which exists to turn unknowns like these into scope.
What the answers do to the price
The score does not tell you the cost. It tells you how far a cost estimate can be trusted.
**Flows scoring six or seven** can reasonably be fixed-priced. The behaviour is known, the failure handling is defined and the vendor is pricing real work rather than guessing. These suit a fixed-cost engagement.
**Flows scoring three to five** should be priced as a range with the assumptions written down. A good proposal will say something like: "This estimate assumes the ERP exposes stock levels through its existing API. If it does not, add a middleware task, estimated separately."
**Flows scoring zero to two** should not carry a fixed number at all. Fund a short discovery spike first, typically building one thin end-to-end path against the real system, then price the rest. Forcing a fixed number onto an unknown does not remove the risk; it moves it into change requests. For work with this much uncertainty a time and material model is usually the more honest structure.
Our enterprise software development work starts from this inventory because it decides which parts of a build can be committed to and which must be learned first.
Red flags in a proposal's integration line
Read the integration section of any quote, including ours, against this list.
- **A single line item for "integrations".** Each flow has a different cost profile. Bundling them hides which one carries the risk.
- **No mention of failure handling.** If retries, monitoring and reprocessing are absent, they are either unpriced or unplanned.
- **"Real-time sync" with no direction or conflict rule.** Two-way real-time sync is among the hardest things to build correctly. A proposal that treats it as routine has not looked closely.
- **No assumption about the other system's API.** Every integration rests on assumptions about the system you do not control. If none are written down, you will discover them together, at your expense.
- **No post-launch owner.** Who watches for API deprecations, renews credentials and handles a failed nightly job after the project team moves on?
A vendor who raises these points unprompted is showing you how it will behave when something unexpected happens mid-project.
Questions buyers ask about software integration cost
**Why can't a vendor give a fixed price for integration up front?** They can, for flows where the seven questions are answered. Elsewhere a fixed price is a guess with a buried contingency. Splitting known flows from unknown ones gets you firm prices where possible and honest ranges elsewhere.
**Is integration cheaper with a modern SaaS product than with an on-premise ERP?** Often, because modern SaaS products usually publish documented APIs, sandboxes and change logs, which answers questions 3, 6 and 7 quickly. Quotas, record matching and failure ownership still apply. The test, not the system's age, decides.
**What about integrating AI systems with our existing software?** The same seven questions apply, with an extra emphasis on question 5, because AI outputs can be wrong without failing. We cover the specifics in our AI platform integration practice, and buyers scoping wider AI work can start from our AI and ML development services.
**How do security reviews affect integration scope?** Every new connection is a new credential and a new data flow for your auditors. Moweb is ISO 27001 certified, and our integration design includes credential storage, least-privilege access and data-flow documentation as standard. Our security page sets out how we work.
Where the test matters most
Some projects are integration projects wearing a different label.
**ERP rollouts and extensions** are dominated by flows into finance, inventory and purchasing, so matching and source-of-truth decide the schedule. Our ERP services treat those flows as first-class scope.
**Supply chain platforms** connect warehouse, transport, supplier and order systems, each with its own owner and release calendar, which is why our supply chain implementation and integration work begins with a connection inventory.
**Legacy modernisation** often fails on undocumented integrations a person was running by hand. The Four-Week Cost Count pairs naturally with this test: one measures what the old system costs, the other prices what connecting the new one will take.
Run the Integration Surface Test on your project with us
If you are about to commission software that has to talk to systems you already run, send us the list of connections, even a rough one. A senior engineer from our team will work through the seven questions with you on a call, mark which flows can be fixed-priced, which need a range and which need a discovery spike first, and tell you where the real estimation risk sits.
You keep the scored table whether or not you work with us. If the honest answer is that your integration surface is small and any competent team can handle it, we will tell you that too.