Count the places your business’s facts live tonight. The website form dumps into an inbox. The chat app holds decisions. Invoices live in the accounting tool. The real order list is a spreadsheet two people maintain. The delivery photos are on phones. Five sources, five logins, no rule for what happens when they disagree.
Nothing is broken about any one of them. The cost is in between: the retyping, the checking, the “which one is right” that eats an hour here and an afternoon there. Multiply that by every week of the year and the number stops being small.
What a built system does differently
Custom software that handles many data sources is not magic and it is not one big program that owns everything. It is three disciplines:
- One source of truth per fact. A customer’s phone number lives in exactly one system, and everything else asks that system. Copies exist for convenience, but each copy knows where its master is. Most data pain in a small business is two systems both believing they are the master.
- Movement that is safe to run twice. The job that copies new orders into the invoice system will sometimes run twice (a retry after a network hiccup, a manual re-run). A safe job detects that it already moved order 4,182 and skips it. The technical word is idempotent, and the plain test is: run it twice, check nothing doubled.
- A record of what arrived when. When a number looks wrong, the log (the timestamped list of what each movement did) answers “when did this change” in minutes instead of an afternoon of guesswork.
Two systems, one number, no rule: that is how a Tuesday disappears. The disciplines above are what remove the Tuesday.
The experiment you can see in public
This site runs the pattern on itself, at a size you can inspect. Its content lives in two places: a CMS (the writing and storage system on its own server) and a set of built-in copies that ship with the site itself. The site reads the CMS, falls back to the built-in copies when the CMS is unreachable, and no page goes down either way. The source is public (github.com/Anito-Systems-Solution/anito-main-web), so the fallback is a thing you can read rather than a claim you must believe.
That is the small version of the discipline your business version needs: every reader knows its master, every reader survives its master being unavailable, and nothing important depends on two systems agreeing by luck.
Where integration actually bites
The hard part is never the copy step. It is the edges:
- The same customer, spelled three ways. Matching records across systems (the same human in the form tool and the invoice tool) is the real work. Ask any developer how they will match, and what happens to a mismatch.
- The tool with no door. Some systems have no way to read or write programmatically (no API, the term for a machine-to-machine door). The honest answers are manual export on a schedule, or replacing that tool. A developer who promises direct sync into a closed tool is promising the one thing it cannot do.
- Backfill. Moving yesterday’s history into the new system, cleaned. It is a project inside the project, and it deserves its own line in the quote.
Run the check yourself
- List your systems and pick your most important number (open orders, unpaid invoices, booked jobs). Write which system is the master of that number. If two systems both feel like the master, that is your first finding.
- Ask any developer you are quoting with: “if this job runs twice, what happens?” The ones who build real movements have a one-sentence answer and a test for it.
- Ask: “which of our tools have APIs and which do not?” A straight answer with a plan for the closed ones is worth more than any diagram.
If that list found something, you are looking at integration work, and it is most of what we build. Systems and API integration is where the mechanics above become working software. To talk about your specific tangle, discuss your project, or read why tools keep creating admin first. Bring the two-systems-one-number finding if you found it; it is the best brief you can hand any developer.
Common questions
Should we not just buy one big tool that does everything?
For standard workflows, often yes, and we will tell you so. The moment to build is when your workflow outgrows what the tools model: your quoting has rules the tool cannot express, or your dispatch works in a way the tool fights. One tool covering 80% verbatim beats a custom build; the remaining 20% that carries your specific workflow is where custom earns its price.
What is an API, in one sentence?
A machine-to-machine door into a system, so software can read and write it without a human clicking through the interface. Tools with good APIs can be connected directly. Tools without one need scheduled exports, a workaround, or replacement, and any honest quote says which of the three your tool gets.
How long does connecting our systems take?
The movement itself is days, not months. The honest drivers of the timeline are the edges: matching customers across systems, backfilling history, and the tools without APIs. A quote that prices only the copy step and ignores the edges is a quote that will grow. Ask for the edges to be named, even as exclusions.
Where does AI fit into integration?
In the reading and matching, with a human checking: reading unstructured documents, suggesting matches between misspelled customer records, drafting the exception report. The rules themselves stay plain automation, because rules do not hallucinate. An AI step that writes directly into your invoice system with no human review is a bet you did not agree to place.