Most businesses do not need new software. They need the systems they already own to talk to each other, and the manual work between them to stop. This is how XOR Services approaches application integration and process automation — what building inside someone else's API actually costs you, why bridging two proven platforms usually beats building a third, and how we scope the work so the result is predictable rather than hopeful.
First, the hard part: you are building on ground you do not own
Writing an application from scratch is, in one narrow sense, easy. You control everything. Every rule, every field, every behavior is yours to define.
Integration work is not like that. When you build against a vendor's API, you are building on a foundation somebody else controls and can change. The constraints are real and worth naming plainly before anyone signs anything.
| Constraint | What it means in practice |
|---|---|
| You do not own the contract | Fields, endpoints and behaviors are the vendor's to change. Deprecation notices arrive on their schedule, not yours. |
| The API exposes a subset | What the interface offers is rarely everything the product does. A capability visible in the user interface may simply not be reachable programmatically. |
| Rate limits are a design input | Throughput ceilings shape architecture. A nightly sync of fifty thousand records is a different system than one of five hundred. |
| There is no transaction across systems | Write to system A, fail writing to system B, and you are left inconsistent. Reconciliation has to be designed deliberately — it does not come for free. |
| Error semantics vary wildly | Some APIs return clean, specific failures. Others return success with an empty payload. Each integration needs its own handling. |
| Debugging crosses a boundary | When something breaks at 2am, part of the evidence lives in a system you cannot see inside. |
| Authentication expires | Tokens rotate, credentials lapse, permissions get revoked by an administrator who did not know what depended on them. |
None of this is a reason to avoid integration work. It is a reason to scope it properly, because these are precisely the details that get skipped in an optimistic estimate and then surface as overruns.
What you get in return
The constraints buy you something substantial, and the trade is usually strongly in your favor.
- You inherit years of hardening. A mature platform has been beaten on by thousands of customers across edge cases you have not thought of yet. That reliability is already paid for.
- The domain logic is not yours to maintain. Tax rules, payment handling, compliance reporting, industry-specific calculations — these change constantly, and letting a vendor absorb that churn is worth real money every year.
- Improvements arrive without a project. The vendor's roadmap becomes your roadmap. Their new features show up in your operation without you funding them.
- Certifications ride along. SOC 2, PCI, HIPAA posture — earning these yourself for custom-built software is expensive and ongoing.
- The surface you own is small. You maintain the bridge, not the buildings on either side of it. That is a fraction of the code and a fraction of the risk.
The economics of bridging rather than building
This is where the cost difference becomes structural rather than incremental.
When you build a system from scratch, you are not buying software once. You are taking on permanent ownership of a domain: the initial build, then the defect backlog, the security patching, the compliance updates, the platform upgrades, the feature requests, and the institutional knowledge required to keep it all alive. That obligation does not end. It compounds.
When you take two market-proven systems and bridge them, you fund the seam. That is it.
| What you pay for | Build from scratch | Bridge two proven systems |
|---|---|---|
| Core functionality | You build it | Already exists, already licensed |
| Ongoing maintenance | Yours, permanently | The vendors', for their side |
| Security patching | Yours to find and fix | Handled upstream |
| Compliance changes | You fund every one | Absorbed by the vendors |
| Feature improvements | New project each time | Arrive with vendor releases |
| Your actual scope | Everything | Data mapping, error handling, reconciliation |
Why this matters for continuity, not just cost
A bespoke system is a single point of failure with exactly one maintainer: you. If the developer who understood it moves on, or the framework it was written in falls out of support, you have a problem with no vendor to call.
Two proven platforms joined by a well-documented bridge behave very differently. Each side has a vendor, a support contract, a patch cadence and a user community. The integration layer is small, documented and replaceable. If one platform stops serving you in three years, you swap that side and rebuild one bridge — rather than discovering that a decade of business logic is welded into software nobody left at the company understands.
Integration preserves optionality. A monolith removes it. That is a continuity argument as much as a financial one.
Process automation: the manual work between the systems
The other half of this work is not about systems at all. It is about the people currently acting as the integration.
In most operations, someone is the bridge. They export a report from one system and import it into another. They re-key orders. They reconcile two sets of numbers every Friday. They chase approvals by email and update a spreadsheet that three departments quietly depend on.
This work is invisible on the org chart and expensive in practice. It also has the exact profile that automation handles well: repetitive, rule-based, high volume, and unforgiving of the small human errors that inevitably creep in.
The return usually comes in three forms — hours given back to people who should be doing judgment work instead of data entry, errors eliminated at the source rather than caught downstream, and latency removed from processes that previously waited for someone to get to them.
One caution we will always raise: do not automate a process you have not examined. Automating a broken workflow produces bad outcomes faster and at greater scale. Frequently the right first move is to simplify or correct the process, and only then encode it. That conversation happens before we write anything.
How we scope it — the XOR way
Integration and automation work runs through the same CADD methodology as everything else we build: Collect, Analyze, Design, Deliver. The specifics matter here.
Collect
We map the flow as it actually runs — what moves between systems, who moves it, what they do when it fails, and which exceptions get handled by hand. We ask what the spreadsheets are for. The answer is almost always a requirement nobody documented.
Analyze
We verify what each API can genuinely do, against the API itself rather than the vendor's marketing page. Which fields are exposed, what the rate limits are, how errors are reported, what the sandbox behaves like. Where a needed capability is not reachable, we say so during analysis — when it is still a design decision — rather than discovering it mid-build.
Design
You approve an integration design that specifies the data mapping field by field, the error handling, the retry behavior, the reconciliation approach, and — critically — what the business does when one system is unavailable. Failure is a design requirement in integration work, not an afterthought.
Deliver
We test against the measurable criteria agreed in Analyze, and we test the failure modes rather than just the happy path: partial writes, expired credentials, throttling, malformed data. An integration that only works when everything is healthy is not finished.
What you have at the end
- A documented bridge — data mappings, error handling, dependencies — that a future developer can pick up.
- Two systems you still own outright, with their vendors and support intact.
- Manual steps removed, with the exceptions still handled deliberately rather than ignored.
- Test results demonstrating the criteria you approved were met, including the failure cases.
- The freedom to replace either side later without starting over.
If you are looking at a proposal to build something your existing systems could probably already do together, that is worth a second opinion before you commit. Get in touch, or read more about how we approach application development.