Custom integrations: fitting around the systems you are keeping

No agency replaces everything at once, and the ones that try are the ones whose projects run to three years. The realistic question is not which system wins. It is which system becomes the place the operation is controlled from, and how everything else reaches it.

That makes integration the substance of most bespoke engagements rather than an afterthought bolted on at the end. Here is what that work actually consists of.

Four shapes, in ascending order of effort

Migration is the most common and the most underestimated. The work is rarely the import; it is deciding what the data means. An acquired book arrives with tenancy dates in three formats, deposits recorded against properties rather than tenancies, and a “notes” column carrying twelve years of information that is genuinely important and structured by nobody. We map it with you rather than guessing, because a guess here becomes a compliance deadline computed from the wrong date.

Exposure is where we made a deliberate architectural bet. Rather than building a bespoke connector per tool, Tekniti ships an MCP connector — an open standard for letting an AI assistant reach an application. Connect your account to ChatGPT or Claude and you can query your own portfolio from the tool already open on your screen. Anything that speaks the protocol can connect, which means what you build around it is your decision and not a queue item on our roadmap.

The integration we will argue against

Two-way sync between two systems that both consider themselves authoritative is, in our experience, the single most reliable way to turn a six-week project into an eighteen-month one.

The reason is not technical difficulty. It is that every two-way sync eventually asks a question with no good answer: the tenancy end date was changed in both systems, four minutes apart, by two different people. Which one is right? There is no algorithm for that. Whatever you pick, somebody’s correction gets silently discarded, and the person who made it will not find out for months.

So we scope integrations with a single authority per field. Some fields are ours, some are theirs, and the direction is written down before any code exists. It is less impressive on a diagram and considerably cheaper to live with.

The one we recommended against building at all

Worth including because it shows how we scope rather than what we sell.

Reading a customer’s mailbox — full OAuth access to Gmail or Microsoft 365 — was scoped properly, with the costs on the table, and then not built. Gmail’s restricted scopes require an annual third-party security assessment with real cost and lead time. More importantly, ingesting an agency’s whole mailbox makes the agency controller and us processor over correspondence from third parties who never consented to any of it — solicitors, applicants, people who emailed once. For a product whose entire pitch is evidentiary rigour, that is a liability surface before it is a feature.

The outcome that integration was meant to deliver — “email comes from us, not from a vendor” — shipped instead as a per-agency sending domain, which reads nobody’s mail. Same result for the client, none of the exposure.

How we scope it with you

We would rather tell you at the scoping stage that something is a build, or that we think you should not do it, than discover it together after a contract is signed. If you have a list of systems and a view on what has to survive the transition, send it to hello@tekniti.ai and we will mark it up honestly — including the parts that are not us.