Systems integration
Every business has one. Somebody pulls a file out of one system, tidies it up, and loads it into another. It works perfectly until they take annual leave. We replace that with something that runs on its own.
That person is doing an integration. They just happen to be a human being with a spreadsheet and a recurring calendar reminder.
Done properly, a job created in one system appears in the others with the right fields populated. A signed variation updates the contract value. Hours approved on site reach payroll without anyone re-keying them. Nobody has to remember Thursday.
The hard part isn't moving the data. It's the decisions: which system owns a customer record, what happens when two systems disagree, and what should occur when something fails at 2am. Get those right and integration is boring in the best way.
How we connect things
In rough order of preference, because the cheapest reliable option wins.
Supported, documented, survives upgrades. If both systems have a decent API this is nearly always the right answer.
The system tells us when something changes rather than us asking every five minutes. Faster, and much kinder to rate limits.
Where an API exists but events don't. Fine for anything that doesn't need to be instant, which is more than people expect.
Some systems only offer a file drop. That's still automatable, with proper validation and alerting, and it beats a person doing it on Thursdays.
Being straight with you
If two systems overlap heavily, connecting them can be more expensive than retiring one. We'd rather tell you that. Sometimes the honest recommendation is that you're paying for three tools that do the same job.
And integration inherits whatever process you have. Connecting a broken process to another system gives you the same problem, faster and in two places.
Vendor lock-in is worth thinking about before you build. If a tool has no API and no export, an integration will always be fragile, and that's a reason to question the tool rather than engineer around it. Our software research covers API quality and data portability for exactly this reason.
Integrations also need an owner. Things change at the vendor's end, and something has to notice. We build alerting in, and we'll tell you honestly what ongoing attention it needs.
Real projects for Australian businesses, including what it actually took.
We helped Knight Solutions automate project communication by syncing task data from ClickUp to Procore, enabling efficiency and better customer experiences.
View the project
Using Power Apps, we helped Hyforce Engineering replace their rigid field service system with a flexible, integrated solution that streamlines time tracking, sales, and field operations.
View the project
How Odaptic transitioned from a manual, high-touch survey and reporting process to a scalable, self-service custom platform, delivering enhanced visuals, seamless client impersonation, and significant cost reductions.
View the projectName the file that gets exported and re-imported, or the thing that gets typed twice. That's the integration, and it's usually obvious to whoever does it.
Related: reporting and dashboards once the data is flowing, and business automation for the steps that shouldn't need a person at all.
Let's look at what it would take to remove it.
