Very little software lives on its own. The system we build for you will almost always need to talk to something you already have: an accounting package, a payment provider, your email, a stock system, or a spreadsheet someone still swears by.
Those connections are often where a project's real value lies, because they're what stop people typing the same thing twice. They're also where things go wrong, quietly, months after launch. Here's what we've learned about making them dependable.
Decide which system owns each fact
One healthcare supplier we work with runs an online shop alongside separate systems for its catalogue, its stock and its accounts. The first question wasn't technical at all: for each piece of information, which system is the source of truth?
Settle that for products, prices, stock, customers and invoices, and each connection becomes simple: read what another system owns, and write back only what this one is responsible for. When two systems both think they own the same thing, you get two versions of it, and sooner or later they disagree.
Expect connections to expire
Most modern services connect through a login that's granted once and then renewed automatically behind the scenes. That renewal doesn't last forever. With one accounting package, a connection that used to keep going for months started lapsing every couple of weeks after the provider changed its rules.
We can't change another company's policy, but we can make its effects painless. So reconnecting is now a button inside the client's own system: sign in to the accounting package, approve, done. No support call, and no waiting for us.
Trust the right messenger
With online payments, it's tempting to treat the customer arriving back on your "thank you" page as proof that they've paid. It isn't. People close tabs, lose signal and press back.
The payment provider's own servers tell yours when a payment succeeds, and that's the message the order should hang on. Built that way, a customer who pays and then closes their browser still gets their order, and nobody can reach the thank-you page without paying.
An integration isn't finished when it works. It's finished when you know what happens when it doesn't.
Send email as yourself
Order confirmations and notifications should come from your own address and land in the inbox, not the spam folder. For organisations on Microsoft 365, we send through your own mailbox, with permission limited to only the mailboxes the system needs, so it can't send as anyone else in your organisation.
Keep a record of every conversation
When something does go wrong, the first question is always "what was sent, and what came back?" We keep a log of every message our systems exchange with the outside world: every email sent, and every payment request and response. It turns a mystery into a five-minute fix.
Leave room for the spreadsheet
Not every connection needs an API. Sometimes the most useful integration is a good import, so existing data comes in cleanly, and an export that opens in Excel exactly the way people expect. Meeting people where they already work is half of what makes a new system feel easy.
If you're wondering whether your systems could talk to each other, ask us. The answer is usually yes, and we'll be honest about the parts that need care.