The Old System Has No API. Here's What Actually Fixes That.

The hour your team keeps losing

Somewhere in your company, someone opens two windows side by side. One is the old system: the dispatch platform, the claims database, the ERP nobody quite remembers installing. The other is the new one, or the spreadsheet, or the portal a customer expects to see updated. They read a number off one screen and type it into the other. All day. Every day. And everyone calls it part of the job.

In logistics it's freight status. In healthcare it's a patient record that lives in two places and occasionally disagrees with itself. In field services it's a job marked done in one system and left open in another until a customer calls asking why. It's rarely dramatic. It's just the hour your team keeps losing, every day, to a gap between two systems that were never built to talk to each other.

Sales decks call that gap "no API." That's not one thing.

What 'no API' actually means

Sometimes the vendor is gone. The company that built the system folded or got bought out years ago, and nobody's coming to add an API because nobody's home.

Sometimes the software predates the idea. It was built before webhooks and REST endpoints existed, so it has no concept of either. Not a design flaw at the time. Just old.

And sometimes the API exists and the vendor charges a fortune for it: rate-limited, license-gated, sold as a tier above what you're already paying for. We're not going to guess at why a vendor prices it that way. We just tell you what it'll cost to work around, or through, it.

Each of these needs a different fix. Knowing which one you're facing changes the conversation before it starts.

Before you build anything, ask this

Is there an off-the-shelf tool that already does this for a tenth of the price? Two common CRMs with a documented connector between them. A payment processor with a standard adapter. An accounting package everyone already integrates with. If the tool exists and it's built for your exact pairing, buying it beats building it, every time.

We say so if there is. We turn down projects a specialist would do better, or that an existing product already solves for a tenth of the price. You'll hear that in the first call, not the third, and not after a discovery week has already been billed.

Custom integration work earns its cost when the systems involved are old enough or specific enough that nobody built a connector for them: a legacy database with no vendor left to ask, a scheduling system that only exports via file drop, a pairing too uncommon for a vendor to have bothered with. That's most of what we actually get called about.

What a real integration project actually includes

A script that pulls a nightly export into a new table is not an integration. It's a one-way trickle. It works fine right up until someone edits a record on the new side and the old side never finds out.

A real integration project runs two-way sync, so changes on either side reach the other. It includes retry logic that can tell the difference between "this record failed" and "this system is temporarily unreachable," because those need different responses. It includes reconciliation, so both sides can be checked against each other on an ongoing basis rather than assumed to match because the sync ran. And it includes failure alerts that name the specific record: not "sync error," not a line buried in a log file, but a message that says which invoice, which patient record, which shipment failed, and why.

Skip any one of these and you haven't built an integration. You've built a faster way to lose track of the same data.

One record failing shouldn't take the whole sync down

We see this constantly in inherited systems: one malformed record, a date field with a typo, a duplicated customer ID, halts an entire batch sync. Ten thousand records were supposed to move overnight. None did, because record 4,417 had a field the receiving system didn't like.

That shouldn't happen. The other 9,999 should go through. The one that failed should get flagged and surfaced with enough detail that someone can fix it in minutes. "Sync failed, code 500" tells your team nothing. "Invoice #88213 failed: customer ID mismatch" tells them exactly where to look.

Reconciliation doesn't end at go-live

Most write-ups treat reconciliation as a migration step: move the data, check it matches, move on. Fine as far as it goes. But the moment two systems are syncing both ways, drift becomes a permanent risk, not a one-time one.

Six months after launch, a bad deploy or an untested edge case can cause the two systems to quietly disagree. Nobody notices until a customer calls about an invoice that doesn't match what your team sees.

That's why we treat reconciliation as ongoing, not a checkpoint. Both sides get checked against each other on a schedule, with a clear rule for which system wins when they disagree. It's a feature of the project, running for as long as both systems are live.

Once two systems are talking, stop stitching spreadsheets

You know the spreadsheet everyone secretly runs the business on. Someone rebuilds it every Friday from exports out of two or three systems, formulas nobody fully trusts, and it somehow ends up in a board deck anyway.

Once systems talk to each other reliably, that spreadsheet's job can move into one warehouse for cross-system reporting, a single place finance can query without knowing which system holds which piece of the truth. It's usually not why people fix the integration problem. It's why they're glad they did, three months later, when someone asks for a number and gets it in a minute instead of a day.

What it actually costs and how long it takes

Integrations & data work typically runs 4 to 10 weeks and starts from $22k. That range is wide on purpose. A two-system sync where one side has a modern API is a very different job from a legacy database with no documentation and three overlapping coding schemes from past migrations. It's priced after scoping the actual systems, not before.

That scoping is what a discovery week is for: flat $4,800, credited back in full if you continue, ending in a written scope, an architecture sketch, and a fixed estimate you can hold us to.

Why this is usually the first project worth doing

If you're weighing a bigger build, a full CRM or a custom web app, integration work is usually the smarter place to start. Partly because it's cheaper: 4 to 10 weeks and from $22k, against 10 to 20 weeks and from $45k for a custom web app, or 8 to 18 weeks and from $38k for a CRM.

Mostly because it's lower risk. A smaller, well-scoped project shows you how we scope, how we communicate, and whether the estimate holds, before you commit to something bigger. If it goes well, you've fixed a real daily cost and you know what the next phase looks like. If it doesn't feel right, you've lost a few weeks, not a year. See pricing for the full breakdown.

For the regulated-adjacent: NDA and security review, honestly stated

If you're in healthcare, fintech, insurance, or logistics, this question comes up before pricing does: can we trust you with this data. We work under NDA by default, and we complete vendor security questionnaires as part of onboarding, because that's standard for getting approved by procurement in these industries.

We don't hold formal compliance certifications. No SOC 2, no HIPAA certification, no PCI-DSS attestation, and we won't tell you otherwise. If a certification is a hard requirement for your project, that's worth knowing before discovery week, not after. Say so, and we'll tell you plainly whether we're the right fit.