Should we use Zapier or build a custom integration?

Start with the no-code tool and be honest about when you have outgrown it. Platforms like Zapier and Make are cheap, fast to change and editable by people who are not engineers, and for a large amount of ordinary business plumbing they are the correct answer: modest volume, simple field mapping, a human who would notice within a day if it stopped, and a missed record that costs an apology rather than money. Five things push you off them. Volume, because per-task pricing that was trivial at a hundred records a day becomes a real line item at fifty thousand. Logic, because branches, loops and lookups assembled in a visual editor are still software, only without tests, version control or review. Error handling, because retries, ordering, partial failure and a reconciliation report are engineering rather than settings. Data rules, because regulated or contractual data often cannot pass through a third-party platform at all. And ownership, because the person who built the flow has left and it now runs a business process nobody wants to touch. A sensible middle exists: keep no-code at the edges for low-stakes notifications, and build the flows that move money, customers or commitments properly.

How long does a software integration project take?

It depends far more on the shape of the integration than on the systems involved. A one-way feed, where data moves from one system into another and never comes back, is the fast case: with documented APIs on both ends and a sandbox to test against, it is days to a couple of weeks, because there is nothing to reconcile. A two-way sync, where both systems can change the same record, is a different project, because every shared field needs an owner, every conflict needs a rule and the two sides must not bounce updates back and forth. A process that spans several systems, where one event triggers conditional work across four tools, is a small application and should be estimated as one. Three things stretch any of them: an end with no usable API, so you fall back to file exchange, a database replica or driving the interface with a script; a real-time requirement that brings queues, ordering and replay; and a matching problem, where the two systems share no identifier and records have to be paired on data that is inconsistent. Ask for the field map before you accept a timeline. If nobody has written down which fields move, in which direction, at what frequency, the estimate is a guess.

What if one of the systems has no API?

You still have options, in descending order of how much you will enjoy them. A scheduled file exchange, where one system drops an export and the other picks it up, is unglamorous and genuinely robust, and it covers a great deal of real business integration. A read replica or direct database access gives you the data without the vendor's blessing, and it is only safe when someone owns the risk that a schema change breaks you silently. The vendor's own export or reporting feed is often better than it looks and worth asking about before anything custom is built. At the bottom of the list is driving the user interface with a script, which works, is fragile, and breaks whenever the vendor redesigns a screen. Anyone proposing it should say so plainly rather than presenting it as equivalent to an API. Two things matter regardless of the route. Freshness drops, so decide what actually breaks if the data is a few hours old, since the answer is often nothing. And the failure path matters more, not less, because the fallback routes fail in quieter ways: you need a queue for what did not transfer, an alert that reaches a named person, and a reconciliation report someone reads.

Making Your Systems Talk: How to Scope a Software Integration Project

TL;DR: Integration projects are rarely hard because the APIs are hard. They are hard because nobody decided which system owns which field, how fresh the data has to be, and what happens on the day one side is down. Five things set the size of the job: what each end gives you to work with, who owns each piece of data, how fast it has to move, how the same customer is recognized in both systems, and what happens when a transfer fails. Here is how to scope one, and how to tell when a no-code tool would have done instead.

Almost every integration request arrives in the same sentence: we just need this system to talk to that one. It sounds like a connector, it gets quoted like a connector, and then it turns into a project, because the connection was never the work. The work is agreeing on the behavior: what happens when both sides change the same record, when the receiving system rejects a row, and when someone edits by hand what the automation is also editing. That agreement is a business decision wearing technical clothes, and it is the part that goes unmade in the first meeting.

What an integration project actually is

There are three shapes, and they cost very different amounts. Naming yours in the first conversation is the single most useful thing you can do.

A one-way feed

Data moves from one system to another and never comes back. Orders land in accounting, leads land in the CRM, transactions land in a reporting warehouse. It is the cheapest and most predictable shape: there is nothing to reconcile, because the source is right and the destination is a copy.

A two-way sync

Both systems can change the same record and both changes have to survive. This is where the cost is: every field needs an owner, every conflict needs a rule, and the two systems must not bounce the same update back and forth forever. Most sync requests turn out to be a one-way feed plus two or three fields that genuinely go both ways, and finding that out is worth weeks of budget.

A process that spans systems

A new order triggers a credit check, a stock reservation, a notification and an invoice across four tools, with conditions and exceptions at each step. That is not a connection but a small application whose interface happens to be other people's software, and it should be scoped as one.

The voice work we do for CallGuard AI is mostly the third kind. The agent on the phone is the visible part, and what makes the system worth anything is where the outcome lands: the pipeline, the calendar, the record the team works from next morning. More in what an AI receptionist does for a business.

The five things that decide how hard yours is

1. What each end actually gives you to work with

Two documented, modern APIs with a working test environment is the good case. What you meet in practice is an API that covers the reads you need but not the writes, a rate limit that quietly caps how fast you can move history, or no API at all.

When there is no interface, the honest options are a scheduled file exchange, a read replica of the database, the vendor's own export, or, at the bottom of the list, driving the user interface with a script. That last one works, it is fragile, and anyone offering it should say so. Confirm sandbox access and rate limits before agreeing a date, because both routinely change the plan.

2. Who owns which field

Source of truth is decided per field, not per system: the CRM owns the phone number, the billing platform owns the payment terms. Where two systems both let a human edit the same field, either pick a winner or write a rule. Leaving it unstated is what makes a sync flap between two values while each team insists its system is right. It is a half-day conversation with the people who use both systems, and skipping it is the most common reason this work runs over.

3. How quickly the data has to move

Nightly batch and event-driven within seconds are different builds, not different settings. Real time brings webhooks, queues, ordering guarantees and a replay path for events missed while the receiver was down. So ask what actually breaks if the data is an hour old. Often the answer is nothing, and the flow that truly needs to be instant is one of six. Set freshness per flow, not for the project.

4. How the same thing is recognized in both systems

Two systems almost never share an identifier. The same customer is a record in one and a contact in the other, matched on an email that has since changed or a phone number stored in three formats. Your integration needs an explicit matching rule and a place for the records that do not match, with a person who checks it.

Data that does not reconcile is worse than data that is missing, because people keep trusting it. On Fyuel, the accounting platform we build for the fuel trade, customers, suppliers, tankers, ledgers and banks all have to line up against numbers the business already believes, a discipline covered in building financial software.

5. What happens when a transfer fails

Not if. A destination will be down, a record will be rejected for a validation rule nobody knew about, a credential will expire. What separates an integration that survives from one that quietly stops working is the failure path: retries with sensible backoff, idempotency so a retry does not create a second invoice, a queue holding what did not go through, an alert that reaches a named human, and a reconciliation report someone reads.

That is roughly half the engineering in a serious integration and it never appears in a quote. As with monitoring an AI voice agent after launch, someone has to watch the exceptions, or nobody finds out until a customer does.

No-code automation versus a custom integration

No-code automation platforms earn their place. They are cheap, fast, changeable by non-engineers, and for a lot of ordinary business plumbing they are the right answer. If the volume is modest, the mapping is simple, and a missed record costs an apology rather than money, use one and spend the budget elsewhere.

Five signs you have outgrown that:

Volume. Per-task pricing that was trivial at a hundred records a day is a line item at fifty thousand.
The logic became a program. Branches, loops and lookups assembled in a visual editor are still software, only without tests, version control or review.
Error handling beyond a red icon. Retries, ordering, partial failure and a reconciliation report are engineering.
The data is not allowed through a third party. Regulated or contractual data often settles it on its own.
Nobody can safely change it. The person who built it has left, and the flow now runs a business process nobody wants to touch.

A sensible middle exists: keep no-code at the edges for low-stakes notifications, build the spine properly, and make sure the result is yours, the argument in software ownership and handover.

How AI changes the integration math

The build side compresses hard. Field mapping, transformation logic, adapters, retry handling and the volume of tests an integration needs are the mechanical work AI coding agents do well under senior review, which is why this class of project now takes weeks rather than months, using the approach in our ship-in-days playbook.

Some integrations also stop needing to exist, because a flow whose only purpose was moving information between two systems can become an agent that handles the task instead, which is much of what we build in custom AI agent development.

One caution. An agent that reads your CRM, checks availability and books an appointment is an integration project wearing new clothes, and all five questions above still apply. Two apply harder, because the agent acts on its own: idempotency, so a retried booking does not become two, and permissions, so it can only touch what it should. In the intake systems we build for Fortell, where Community Action Agencies take calls in more than a hundred languages, landing that information in the right record is what makes the language coverage useful.

What AI does not compress is deciding who owns which field and how fresh the data has to be. That needs the people who run the operation, and they are usually the critical path.

How we scope an integration build

Read the documentation for both ends before quoting. Confirm sandbox access, rate limits and which operations are genuinely supported.
Write the field map. Every field that moves, in which direction, at what frequency, and which system wins a conflict. This document is the project.
Set freshness per flow. Instant where the business acts immediately, batch everywhere else.
Design the failure path first: retries, idempotency, a queue for rejects, one named person who gets alerted.
Build the smallest end-to-end slice with real data, one record type, all the way through, in production conditions.
Run it alongside the manual process and reconcile before the manual step is switched off. The comparison finds the rules nobody wrote down, as it does in a legacy system replacement.

Buyer checklist

Which of the three shapes is this? One-way feed, two-way sync, or a process spanning systems. A quote that has not answered it is a guess.
Show me the field map. If it does not exist, neither does the scope.
Which system wins when both change the same field? Every disputed field needs a named owner.
How fresh does each flow have to be, and why? Real time should be justified, not assumed.
How are records matched across systems, and where do the unmatched ones go?
What happens when the other side is down for two hours? Expect retries, a queue and an alert, not optimism.
Who watches this in month six? An integration with no owner is a future outage.

An integration is not a wire between two boxes. It is an agreement about who owns what, how fast it travels and what happens when it does not arrive. Make those decisions deliberately and you get a boring system that runs for years. Skip to the connector and you get one that works in the demo and needs a person watching it forever.

Null Studio builds the integrations that hold businesses together: field maps agreed before code, failure paths designed first, AI leverage on the build. Book a demo and we will tell you honestly whether you need a custom integration, a no-code flow, or to stop syncing two systems and replace one.