Integration work that starts by deciding which system is right
Audit, architecture and build for the gaps between the tools you already pay for: webhook pipelines, two-way syncs, custom REST connectors and legacy data recovery.
The tools are rarely the problem. The gaps between them are: data re-keyed between a CRM and an accounts system, a spreadsheet that has become the integration layer, and nobody quite sure which system holds the truth. The first deliverable in an integration engagement is a decision, not code. Which system owns each record, and in which direction does data flow?
Three of our builds are integration work at heart, and they look nothing alike. An order intake system parses inbound orders onto live monday.com boards. A form platform was given a token-secured REST API and an outbound webhook so Make could read from it and react to it. And a legacy desktop ledger had its history decoded out of a format nobody supports and loaded into a new system. Integration problems come in shapes, and the shape decides the approach.
We do both halves: the consulting, meaning the audit and the architecture, and the build. If what you need turns out to be one Make scenario, or a connector that already exists and works, we will say that rather than propose a project.
What the problem usually is, and what we do about it
The same word, integration, covers jobs that share almost nothing. These are the four we have shipped.
| Shape of the problem | What we build | Where it shipped |
|---|---|---|
| A system you own with no connector, and an automation platform that needs to talk to it | A bearer-token REST API (list forms, read a schema, create, read, update and delete entries) and an outbound webhook on insert, so the platform is notified instantly instead of polling. The token is separate from the database credentials, so it rotates on its own. | FormCraft |
| Documents arriving that must become records on a live board | A webhook receiver and parser that fill the row, matched against existing records so a resend updates rather than duplicates, plus an ingest ledger of what arrived and what it changed. | Fleet order automation |
| A credential that reaches far more than the integration needs | A single server-side process that owns every credential and all board access, with the front end fetching server-side and the module that talks to it importing server-only, so a client component reaching for it is a build failure. | Fleet order automation |
| An old system with no usable export | A decoder for the file format, calibrated against a known document, with idempotent loads and reconciliation against a source you can verify. | Trading ERP |
From audit to cutover
- 01
Map what is connected, and who believes they own what
The deliverable is an integration architecture: systems of record, direction of data flow and failure modes. Two things drive the estimate: the exceptions, which are the main driver, and how many systems believe they own the same information. Pushing data one way from the owner to a display is well-understood work; two systems that both hold the customer and can both be edited is a reconciliation.
- 02
Decide the join key
If the key is an identifier both systems store, the work is mechanical. If it is the customer name, you are now building fuzzy matching, a review queue for near misses and a way to merge two records that turned out to be one. Better to know before the build than during it.
- 03
Build the unglamorous parts
Idempotency keys and find-or-create so a retry does not duplicate; back-off so a rate limit does not become a lost message; unique constraints where the destination is a database you control; and a run log with the trigger, each step's input and output, and the error, so a failure is diagnosable.
- 04
Run it in shadow mode first
On the fleet build the whole allocation and SLA layer shipped behind a shadow-mode flag and a go-live cutoff, running alongside the manual process and logging what it would have done without doing it. Comparing the two on real orders is what made the cutover uneventful.
The ways an integration quietly stops being true
A retry writes twice
A webhook is delivered twice (senders retry when they do not see an acknowledgement), a scheduled run overlaps its predecessor, or someone re-runs a failed execution. If creating a record is unconditional there are now two. Derive a stable key from the payload and search first; where the destination is your own database, a unique constraint is a guarantee where a search-then-create is a race.
Two systems, both edited, no owner
The expensive shape. It needs conflict rules, a matching key, a merge policy and a reconciliation report, and it keeps costing. Naming a system of record per entity, syncing one way, and making the receiving side read-only for those fields is almost always cheaper than the alternative.
The token in the wrong place
An account-wide token that reaches commission columns should live in exactly one process. A credential typed into a module field is part of the scenario, so it can travel with an exported blueprint, and it cannot be rotated without editing each place it was pasted, so it never is.
The system has no API
Rarely a dead end. File-based exchange, scheduled exports, email parsing and, as a last resort, headless browser automation usually give a supportable path. What matters is saying which of those is robust and which needs monitoring, and choosing deliberately instead of discovering it later.
What moves the cost of an integration
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, and none of the three case studies above states a price or a duration, so the range is not attributed to them. Our build-versus-buy article says a focused automation or integration is typically two to four weeks, as a typical range and not a quote. What moves the number is below.
| What changes | Why it matters | Effect |
|---|---|---|
| Exceptions | Each way a record can depart from the happy path needs a decision, a state to hold and a test | The main driver; follows the number of paths, not steps |
| Systems that believe they own the same data | One owner pushing outward is a mapping; two systems both edited is a reconciliation with conflict rules and a merge policy | Close to linear with one owner, multiplies without one |
| Rules that need a database | A once-only guarantee, memory of earlier events, per-user visibility or a permanent audit trail | Usually the step change in an estimate |
| The join key | A shared identifier is mechanical; a customer name means fuzzy matching and a review queue | The question that best predicts the effort |
A project grows beyond what was first expected for predictable reasons: history that must be migrated and reconciled, a system with no interface worth the name, or an organisation where getting a single answer takes several rounds of meetings. That last one matters more than it sounds: the biggest multiplier on a small project is often a question that takes several meetings to answer, so one person who can decide which system wins is worth a great deal.
When an integration consultant is the wrong call
If both systems already have a maintained native connector and it does what you need, use it. If the job is one linear automation, a workflow platform will carry it for less than a project, and our platform pages say where each one stops. A platform is usually cheaper for the first version of an integration; the arithmetic flips when per-operation cost overtakes ownership, when the rules need memory or a guarantee, or when the effort to keep several tools agreeing has grown larger than the thing they imitate.
At the other end, a database in the middle holding the truth is a larger build up front, but it grows more slowly as systems are added: linking every system to every other needs up to n(n-1)/2 connections, while a hub needs n. And if the real problem is that nobody has decided which system is right, no connector will fix it. That conversation, not code, is what we would start with.
Where it has shipped
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
The disciplines behind it
Platforms that bear on it
Related reading
Systems & API integration, specifically
An architecture first: which system owns each record, which direction data flows, and what happens when each step fails. Then, if you want it, the build: webhook receivers, REST connectors, parsers, migrations, and a run log with a retry policy and alerting. You can take the architecture and give the build to someone else.
Rarely. File exchange, scheduled exports, email parsing and, as a last resort, headless browser automation usually give a supportable route. We would tell you which is robust and which would need monitoring, and choose deliberately.
A platform is usually the cheaper route for the first version. A custom component earns its place when the rules need memory, a guarantee or an audit trail, or when per-operation billing has stopped tracking the value of the work. The middle option is usually right: keep the platform and build only the piece it cannot express, like the API in front of a form platform or the parser in front of a board.
By making running it twice leave the same result as running it once: a stable key derived from the payload, find-or-create or upsert semantics, and a unique constraint where the destination is a database we control. Webhook senders generally retry when a delivery is not acknowledged (monday.com's developer documentation describes retries after a failed delivery), which is correct on their side and a duplicate on yours unless the write is idempotent.
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, once we have seen the process, its exceptions and the systems involved. Our build-versus-buy article says a focused automation or integration is typically two to four weeks. What moves the number is the exception count, how many systems believe they own the same data, and whether the rules need a database. Send the happy path, the exception list and the systems involved and the reply can say which variable would move it.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Webhooks · monday.com (API reference)
- Scenario blueprints · Make (Help Center)
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no