GUIDE
Build vs buy: integrations cost worksheet
A line-by-line model of build, maintenance and support cost per integration, with every assumption written out so you can replace it with your own.
By Unify Int teamUpdated 7 min read
Every product team that serves businesses eventually faces the same decision: build each accounting, ERP and commerce integration in-house, or buy a platform that provides them. The decision is usually made on the cost of the first build, which is the most visible number and the least important one.
This worksheet models the full cost of one integration over its life. It is deliberately explicit. Every number below is an example assumption — replace it with your own. We have not used industry averages, because they would hide the inputs that matter for your team.
How to use this worksheet
- Fill in the inputs in the next section with your own rates and estimates.
- Work through the line items for one representative platform, such as QuickBooks Online or NetSuite.
- Multiply by the number of platforms on your roadmap, adjusting for platforms that are harder or easier than the first.
- Compare the result with the quoted cost of a platform, plus the engineering time you would still spend integrating with it.
Do this with an engineer who has shipped an integration before. Estimates from people who have not tend to omit the second half of the table.
Inputs
Example assumptions — replace with your own.
| Variable | Meaning | Example input |
|---|---|---|
R | Fully loaded cost of one engineer-week | $5,000 |
B | Weeks to build one integration to production quality | 8 |
P | Platforms on your 24-month roadmap | 6 |
M | Engineer-weeks per platform per year on maintenance | 6 |
S | Support hours per platform per month on connection issues | 10 |
H | Fully loaded cost of one support hour | $60 |
O | On-call cost per year for integrations (stipends plus incident time) | $15,000 |
Y | Years in the model | 2 |
The arithmetic is simple on purpose. The value is in arguing about the inputs, not in the formula.
Line items: the first build
The build estimate B should cover all of the following. If your estimate only covers the first two rows, it is too low.
| Line item | What it includes | Share of B (example) |
|---|---|---|
| Auth | OAuth app registration, consent flow in your product, token storage, refresh, revocation, reconnect UX | 15% |
| Data mapping | Reading the platform's objects, mapping them to your model, handling custom fields, currencies and entities | 25% |
| Sync | Initial backfill, incremental sync, change detection, pagination, rate-limit handling | 20% |
| Writes | Create and update paths, validation, idempotency, closed periods, partial failures | 15% |
| Error handling | Mapping platform errors to something your code and support team can act on, retries with backoff | 10% |
| Testing | Sandbox companies, fixtures, contract tests, a test plan for each write | 10% |
| Launch | Partner or app marketplace review where required, docs, support runbook | 5% |
With the example inputs, one integration costs B × R = 8 × $5,000 = $40,000 to build. Six platforms cost $240,000, before anything breaks.
Some platforms are much harder than others. NetSuite's subsidiaries, custom records and governance limits, or Amazon's Selling Partner API roles and reports, can double B. Lighter platforms can halve it. Adjust per platform rather than using one number for all.
Line items: running it
This is the half of the model that teams leave out.
| Line item | What drives it | Formula | Example per platform per year |
|---|---|---|---|
| Platform API changes | Version deprecations, new required fields, auth changes, sunset endpoints | part of M × R | |
| Bug fixes and edge cases | Data your fixtures did not contain: odd tax setups, multi-currency, deleted records | part of M × R | |
| Maintenance total | M × R | 6 × $5,000 = $30,000 | |
| Customer connection support | Expired tokens, permission changes, "why didn't this sync" tickets | S × 12 × H | 10 × 12 × $60 = $7,200 |
| On-call share | Incidents when a sync fails at month-end | O ÷ P | $15,000 ÷ 6 = $2,500 |
| Running cost per platform | $39,700 |
Over the two years in the model, running one platform costs about $79,400 with these inputs, roughly twice its build cost. Your ratio will differ. The point is that it is rarely small.
The total
Example assumptions — replace with your own.
| Formula | Example | |
|---|---|---|
| Build, all platforms | B × R × P | $240,000 |
| Run, all platforms | (M × R + S × 12 × H) × P × Y + O × Y | $476,400 |
| Total cost of ownership | $716,400 | |
| Per platform, per year | total ÷ P ÷ Y | $59,700 |
Now compare that with a platform. The platform's cost is its subscription plus the engineering time you still spend: integrating your product with the unified API once, building your own write paths and UX, and handling the cases where the unified model does not reach and you use raw records or passthrough requests. Be honest about that last part. A platform does not take integration work to zero; it takes the per-platform work down.
Opportunity cost
The table above counts money. The larger cost is usually what your engineers did not build.
Write down what the same engineer-weeks would have produced on your core product. If the answer is "the feature that wins the next three deals", the integration build is more expensive than the worksheet says. If the answer is "nothing urgent", the opposite is true.
Also count calendar time. A deal that needs NetSuite this quarter is not helped by a NetSuite integration that ships in two quarters. Time to first live integration is a cost line even if it is hard to price.
When building wins
Buying is not always right. Building in-house is often the better call when:
- You need one or two platforms. The per-platform savings of a unified API matter less when
Pis small. - The integration is your product. If your differentiation lives in the depth of one platform's data, own it.
- You need something no vendor models. If the objects you depend on are niche, a unified layer adds little.
- You have the people. Engineers with spare capacity who have shipped integrations before, and who will stay with the code.
- Your constraints rule out a third party. Some data and contracts cannot pass through another processor.
Buying tends to win when the platform list keeps growing, when writes need to be safe across many ledgers, and when your support team already spends real time on connection tickets.
A hybrid is normal
Many teams end up with a mix: a unified API for the long tail and for categories they do not want to own, plus a direct integration for the one platform that defines their product. Plan for that from the start. Choose a vendor whose model you can extend with custom fields and passthrough, so the line between the two can move.
Questions that sharpen the estimates
The worksheet is only as good as its inputs. Before you trust the total, put these questions to the people who would do the work.
- How many write paths do we need? Reading invoices is one job. Creating invoices, applying payments and posting journal entries are three more, each with its own validation rules and failure modes.
- What does a bad write cost us? A duplicate bill in a customer's ledger is a support ticket at best and a lost customer at worst. If the answer is "a lot", raise
Bfor testing and add review time. - Who answers the connection tickets today? If support escalates to engineering,
His an engineering rate, not a support rate. - How often has this platform changed its API in the last two years? Read the vendor's changelog. Frequent deprecations push
Mup. - What happens when the engineer who built it leaves? Knowledge loss is a real cost. Count the ramp-up time for whoever inherits the code.
- Which customers are waiting? Put names and deal sizes next to each platform. It turns the opportunity cost line from a guess into a list.
Checklist before you decide
- Inputs filled in by someone who has shipped an integration.
- Build estimate covers auth, sync, writes, errors, testing and launch.
- Maintenance and support included for every year in the model.
- Hard platforms estimated separately.
- Platform cost includes your own remaining engineering time.
- Opportunity cost written down in terms of features or deals.
- The case for building stated as clearly as the case for buying.
How Unify Int fits
Unify Int is designed to take the per-platform lines down: one data model across accounting, ERP, payments, commerce and PIM systems, with auth through Unify Connect, sync and webhooks through Unify Sync, and logs and connection health in Unify Monitor. Escape hatches, raw records, custom field mapping and passthrough, cover the cases the model does not. If you want the build done for you, the Unify Technology Center runs strategy workshops that produce this worksheet with your numbers. Our build-in-house comparison and pricing give you the other side of the table.