In this article (7)
The cost of systems that cannot talk
A typical mid-sized company runs an accounting package, a CRM, a warehouse or project tool, a website and a pile of spreadsheets. None of them share anything, so a person copies between them several times a day. That person is the integration layer, and they are slower, more expensive and more error-prone than software. API-first is the decision to stop hiring humans for that job by insisting every system you buy or build can be read and written by another one.
What API-first actually means
It means the functions of a system are exposed as an interface other software can call, and that interface is designed first rather than bolted on once the screens are finished. In buying terms it is simpler: before you commit to any tool, ask whether it has a documented API, whether your plan includes access to it, and whether you can get your own data out without asking their support team. A tool that fails those three is a future migration project you have not budgeted for.
Where it pays off first
The wins are boring and immediate. An order placed on the website appearing in the system that fulfils it, without retyping. A customer record updated once instead of in four places, which is also what makes a client portal worth building rather than another place to retype things. A report that is already correct on Monday morning because it reads from the source rather than from a copy of a copy. Each of these removes a recurring manual task, which is exactly the profile of work that repays automating first.
Decide where the truth lives
Before connecting anything, name the one system that owns each piece of information. Customers live here, orders live there, stock lives in the third. Everything else reads from the owner rather than keeping its own version. Skip this and integration makes the problem worse: now four systems disagree automatically, at speed, and nobody can tell which started it. This is the same underlying discipline that separates a company that has outgrown spreadsheets from one that has simply bought more tools.
Talk to us about connecting your systems on WhatsAppConnecting is not the same as building
Integration does not mean replacing what you have. Most companies get most of the benefit by leaving their accounting and CRM where they are and building a thin layer that moves information between them correctly. Whether that layer should be assembled from connectors or written properly depends on volume and how much the rules matter, which is the real substance of no-code versus custom software. Start by connecting; replace only what genuinely blocks you.
Ask the API questions during procurement
The moment to settle this is before signing, when you still have leverage. Is the API documented publicly. Is it included in this plan or an upgrade. What are the rate limits. Can we export everything we put in, in a usable format, without a support ticket. Who owns the data. Vendors answer these clearly or evasively, and the evasion is the answer. Asking late is how businesses discover their five years of history is only retrievable as a PDF.
Build it so somebody can fix it at 9am
Integrations fail quietly, which is what makes them dangerous: an order stops syncing on Friday and nobody notices until a customer calls on Tuesday. Whatever you build needs logging, an alert when a step fails, and a documented way to replay what was missed. That operational plumbing is unglamorous and it is the difference between a connected business and one that has simply automated its next crisis. It is a large part of what a custom platform is really for.
Written by
Idennex
Strategy-first agency, Istanbul