Integration design before any code
Maps which system is the source of truth for each record, which direction it flows, and what must never be overwritten. The design is written down and agreed before anything is built.
Fractional Teammates · CRM & Systems
Make your systems agree, and tell you when they don't
A senior integration specialist from our Vancouver studio joins your team part-time, in your repositories and your standups. They build the connections between your systems, and the monitoring that catches a failure the same day.
A senior specialist, not a junior placement You own the work and the accounts Reply within one business day
Agent running - queue empty
Flow 04
01
Trigger
Webhook
02
Enrich
Normalise
03
Decide
Policy
04
Act
Resolve
Run log
> Matched 42 records
> Routed 7 exceptions to a human
> Closed 35 tickets automatically
35
Auto-resolved today
6h
Engineer time saved daily
What a systems integration specialist is
OlDevs embeds a senior integration engineer in your team for a defined share of each week, and their job is to make separate systems agree.They map the fields between your CRM, finance, booking, inventory and marketing tools, build and maintain the API and webhook connections or the middleware between them, and decide what happens when a call fails: retry, queue, or wake a named person. They own error handling, idempotency and reconciliation, so a duplicate record or a dropped order is caught in hours rather than found at month-end. They work in your repositories, your ticket queue and your standups. You own the code, the credentials and the accounts.
Key facts
- 01Group
- CRM & Systems
- 02Engagement
- An ongoing weekly share, quote-based
- 03Works in
- Your repositories, ticket queue and standups
- 04Common surfaces
- REST, GraphQL, webhooks, iPaaS, queues, file feeds
- 05Typical commitment
- 1 day a week
- 06Judged on
- Sync success rate · Time to detect a failure · Manual re-entry hours
CRM & Systems
The work this teammate owns
What this teammate takes off your plate
API and webhook connections
Builds and maintains the connections between your systems: REST and GraphQL calls, webhook receivers, scheduled syncs and file feeds, with authentication, rate limits and pagination handled properly rather than hopefully.
Middleware and orchestration
When two systems cannot talk directly, builds the layer between them, a small service, a queue, or a job in the automation platform you already run, and keeps it documented and testable.
Record matching across systems
Deciding when two records are the same person or order, how currencies and dates are normalised, which fields are required, and what happens to a record that fits none of the rules.
Error handling, retries and replay
Failed calls are retried with backoff, replayed safely without creating duplicates, and parked in a queue a person can inspect. Nothing is dropped quietly because a third party was down for ten minutes.
Alerting on failure, and on silence
Alerts when calls fail, and a scheduled count that compares record totals on both sides, because the harder fault is a sync that stops sending anything at all and raises no error.
Benefits
What changes once your systems stay in step
01
Staff stop re-keying the same record
Operations has been copying orders between two systems and keeping a reconciliation spreadsheet beside them. A designed connection retires that habit, and the hours it consumed go back to the work they were borrowed from.
02
One answer when two systems disagree
Finance, sales and support each quote a different total, and the meeting becomes an argument about sources. With one defined direction of travel between systems, a disagreement turns into a rule someone can inspect and correct.
03
A broken sync surfaces as an alert
Today a stalled feed is found by a customer chasing an order, or by finance at month-end. With the flow monitored, it surfaces from an alert instead, and the conversation becomes a fix rather than an apology.
04
Replacing a system becomes a decision
Organisations stay on software they have outgrown because nobody knows what would break if it left. Once every connection is mapped and written down, changing a vendor becomes planned work with a known list of what it touches.
05
Failure cases stop being discovered in production
Retries, duplicate events and partial failures are designed for by someone who has already met them in other organisations, instead of found in production. Integration work arrives in bursts, a migration or a new vendor, not as a steady full-time load.
06
The connections stay yours when people leave
Every credential, repository and scheduled job sits in your organisation's own accounts under names your staff recognise, not on a personal laptop or a departed contractor's login. When the seat changes hands, the knowledge stays with the systems.
How it works
How the work is sequenced
A conversation about what keeps breaking
We go through the systems involved, what is already connected, and which failures keep reaching your customers. If a fractional teammate is the wrong shape for it, we say so.
A written proposal, nothing implied
You get a quote, the share of the week proposed, who the specialist is, and what the first month covers. Nothing about the arrangement is left to be assumed later.
An inventory of everything already running
Week one lists every system, integration, credential and scheduled job that exists, including the ones nobody remembers owning. That list becomes the map the rest of the work runs against.
Monitoring before new connections
Alerting and reconciliation counts go on the existing syncs first. Until you can see whether something is working, adding another integration only widens the area you cannot see.
Stabilise, then extend
The first builds are usually the connections that already fail. New integrations start once the old ones are quiet, and each one ships with its own alert and runbook entry.
Who it's for
Where this fits, and where it does not
Integration work is never finished, because the systems on either side of it keep changing. That is what makes it suit a standing share of someone's week rather than a single build.
Organisations running five or more business systems
CRM, finance, booking, inventory, HR and marketing tools bought at different times, each holding part of the same record, and nobody responsible for the space between them.
Teams whose integrations were built by someone who left
Scripts on a laptop, an automation account under a personal email address, no documentation. The work starts by finding what exists and putting it back under your organisation's control.
Government bodies and regulated organisations
Registration, grant, case and finance systems that must reconcile, with personal records covered by privacy rules and an audit trail that has to survive staff turnover and a change of supplier.
Where a fixed-scope project is the honest answer
One integration to build, with no plan to keep changing it, is a project and we will quote it as one. A weekly share is the wrong shape for work that finishes.
12+
Years of studio experience since 2014
1
Typical commitment — 1 day a week
EN/FR
Languages this engagement can be delivered in
Other fractional roles
Often paired with
01
CRM & Automation Specialist
A senior specialist from OlDevs owns your CRM for an agreed share of each week: the data model, pipeline stages, lifecycle automation, routing and reporting.
Explore02Back-End Developer
Your APIs, data models, queues and integrations get an owner who joins your standups and works in your repositories.
Explore03DevOps & Cloud Engineer
A senior DevOps and cloud engineer from our Vancouver studio joins your team for a defined part of each week.
ExploreFAQ
Questions engineering leads ask
A set number of hours or days of one senior specialist, held to the same schedule each week so your team knows when they are available. The share can be renegotiated with notice, heavier during a platform rollout and lighter afterwards, so the studio can plan. What does not move week to week is the standup attendance, the build log and the written notes.
You do. The code sits in your repositories, the connections run in your accounts, and credentials live in your vault rather than ours. We keep no proprietary layer that stops working when the engagement ends. In the final month we write the handover: the integration map, the mapping catalogue, the alert runbook and the known weak points, so your team or another supplier can pick it up.
You can buy the tool. What you cannot buy is the decision about which system owns a record, what happens when a call fails at two in the morning, and who is told. Those questions, not the connectors, are where this work usually stalls. If you already run a platform, the specialist works in it rather than replacing it with something of ours.
When you need someone on call every day for incident response, a weekly share is too thin and you should staff it properly. When there is one integration to build and no plan to change it, buy the project. And when nobody internally can grant access or decide which system owns a record, the engagement stalls no matter how senior the person is.
Usually yes, and it is arranged your way. Accounts are created under your identity provider with named access for the specialist, scoped to the systems in the engagement, and revoked by you at any time. We do not create shared logins or route your data through anything we own. Where records are personal, we agree what may be copied between systems before anything is connected.
Failed calls raise an alert in a channel your team watches, not only ours. The harder case is a sync that stops sending anything and raises nothing, so a scheduled job counts records on both sides and reports the difference. We will not put a number on detection time before we have seen your systems, but the aim is the same day rather than month-end.
Let’s connect
Let’s talk about the systems integration specialist gap.
Tell us what is not getting done and roughly how much of a week it needs. We’ll reply within one business day with who would cover it and a tailored quote — no obligation.