Most budget blowouts on software projects don’t happen in the features everyone’s watching. They happen in the integrations. The accounting sync. The CRM webhook. The payment gateway that has three different API versions in the wild and a PDF from 2019 as documentation. We’ve seen integrations quoted at two weeks turn into six, not because anyone was incompetent, but because nobody scoped them honestly at the start.
Here’s the uncomfortable truth: integrations are not features. They behave differently, fail differently, and need to be priced and scoped as their own category of work. If your agency – or your in-house team – is lumping them in with product build estimates, you’re going to feel it when the invoice arrives.
Why Integrations Are a Different Animal
When you build a feature, you control the inputs and outputs. When you build an integration, you’re at the mercy of a third-party system that was designed by someone else, for someone else, and may not have been updated since your counterpart’s last developer left the company.
The variables you don’t control include: authentication quirks (OAuth flows that time out in unexpected ways, API keys that only work in specific IP ranges), rate limits that don’t surface until you’re in production with real load, data shape mismatches between what the docs say and what the API actually returns, and – our personal favourite – sandbox environments that behave completely differently to production.
We built a payroll integration last year where the sandbox returned clean, well-structured JSON every time. Production returned the same data wrapped in an extra layer of XML for certain account types, with no mention of this in the documentation. That’s half a day of debugging that no one budgeted for. Multiply that across four or five integrations in a single build and you’ve found your blowout.
The Scoping Questions You Have to Answer Before You Touch Code
Before we write a single line of integration code, we run through a set of questions that most teams skip. They feel like overhead. They’re not.
- Is there an official API, and how mature is it? A REST API with proper versioning and a changelog is a different beast from a SOAP endpoint your integration partner “still supports.” Maturity of the API is the single biggest predictor of integration effort.
- Who owns the third-party relationship? If you need a partner API key, a sandbox account, or approval from their team to go live, who is chasing that? It almost always falls on the client and it almost always takes longer than expected.
- What is the volume and frequency of data exchange? A nightly batch sync is architecturally simple. Real-time bidirectional sync is not. Know which one you’re actually building before you price it.
- What happens when it fails? This is the question teams answer last but should answer first. If the integration goes down, what does your product do? If the answer is “nothing, it just fails silently,” that’s a product decision, not a technical one, and it needs to be made before build, not after.
- Who holds the integration long-term? Third-party APIs change. The provider will push a new version, deprecate an endpoint, or alter their auth flow. Someone needs to own that maintenance. If it’s your dev team, that’s ongoing cost you should factor into your unit economics now.
The Real Cost Ranges, Honestly
People ask us what integrations cost and the honest answer is: it varies so much that a single number is almost meaningless. But ranges from experience are useful, so here they are.
A simple read-only integration against a well-documented REST API – something like pulling data from a CRM into your platform on a scheduled basis – sits somewhere in the $3,000-$7,000 AUD range for design, build, and basic error handling. That assumes the API is sensible, the data shape is clean, and there’s no custom auth weirdness.
A bidirectional sync with conflict resolution – where both systems can write, and you have to decide which one wins when they disagree – is a fundamentally different problem. Budget $10,000-$25,000 AUD depending on complexity. If you’re syncing financial records where accuracy is legally important, assume the higher end and add a buffer.
Payment gateway integrations land in a wide range depending on what you’re doing. Stripe for a standard subscription flow is well-trodden and fast – call it $5,000-$12,000 AUD including the subscription logic, webhook handling, and failed payment retry flows. If you’re adding split payments, multi-currency, or connecting to a less common Australian gateway with a mediocre API, double that estimate and you might still be short.
What inflates every one of those numbers? Undocumented edge cases, sandbox/production environment differences, waiting on third-party sandbox access, and any requirement for the integration to be “real-time” that turns out to mean “within 200 milliseconds.” That last one changes the architecture entirely.
Build the Error Handling First, Not Last
This is the mistake we see most often. Teams treat error handling as a polish step – something you bolt on at the end when the happy path is working. For integrations, error handling is the product. The happy path is maybe 70% of what happens in the wild. The other 30% is timeouts, malformed responses, expired tokens, duplicate event delivery from webhooks, and the occasional completely undocumented HTTP 422 that the third-party API throws for reasons that are never explained.
When we scope integrations at Amora, we build the failure modes into the spec before we write the success path. What does a timeout look like to the end user? Do we retry, and if so, how many times and with what backoff? Do we log the failure silently, surface it in the UI, or send an alert? Do we queue the failed operation and retry it later, or do we drop it and make the user retry manually?
These are not technical questions. They are product questions that have technical consequences. If you can’t answer them during scoping, you’ll answer them in production, under pressure, and you’ll usually answer them wrong.
When to Build Your Own Integration Layer vs Buying One
There’s a class of integrations where the right answer isn’t to build anything. Platforms like Zapier, Make, or the more developer-oriented options like Merge or Apideck exist precisely because common integrations have been solved many times over and the marginal cost of building them yourself is hard to justify.
The case for buying an integration layer: you need a broad set of integrations fast, you’re early-stage and your integration requirements are still changing, or the integrations are supporting features rather than core product. A B2B SaaS that needs to sync with “whatever CRM the customer uses” is a good candidate for Merge or a similar unified API layer, rather than building native integrations with Salesforce, HubSpot, and Pipedrive separately.
The case for building your own: the integration is core to your product’s value, you need fine-grained control over the data flow, your volumes or data sensitivity make a third-party layer a risk, or the specific integration isn’t supported by the abstraction layer at the fidelity you need. A fintech product that needs real-time transaction data at high volume is probably not well served by an abstraction layer that introduces latency and limits your access to raw fields.
The honest answer is that most early-stage products should be buying before they build, and most mid-stage products that are still buying everything are leaving performance and reliability on the table. Know where you are on that curve.
The Conversation to Have With Your Agency Before You Sign
If you’re about to engage an agency on a build that includes integrations, ask them these questions directly:
- How are integrations priced – as part of the overall estimate or as a separate line item with their own assumptions?
- What happens to the estimate if we get into the integration and discover the API is worse than the documentation suggests?
- Is sandbox access included in the timeline, or is that contingent on us getting credentials from the third party?
- Who owns integration maintenance after launch, and what does that cost?
- Have you built against this specific API before?
The last one matters more than it sounds. An agency that has already wrestled with Xero’s OAuth quirks or Afterpay’s webhook retry logic will take a fraction of the time of one approaching it fresh. Prior experience with a specific API is worth real money on your invoice.
If you’re staring down a build with two or more integrations and you’re not sure whether the scope is realistic or the estimate is honest, talk to Amora about your build – we’ll tell you what we’d actually expect to find, and what it would cost to do it properly.
Integrations are solvable. They’re just not simple, and the teams that treat them like they are tend to find out at the worst possible time.
Got something you want built?
Amora Digital is an Australian software and AI agency. We scope it, build it, and ship it – live in 28 days. No offshore teams. No surprises.