The questions we ask before we say yes to an integration project
Not every integration project is a good fit for us. Not because of the technology — we can work across most stacks — but because of what we find when we start asking questions about what the project actually is.
These are the questions. If you're evaluating us, or evaluating any integration vendor, they're worth knowing.
Who owns the systems on both sides?
An integration connects two or more systems. Each of those systems has an owner — a team or a person who controls access, makes decisions about schema changes, and can authorize the work that needs to happen on their side. Before we start, we need to know who those people are and whether they're in the room.
Integration projects that fail usually fail because of ownership gaps, not technical problems. A team on one side that doesn't know the integration is happening, or doesn't have the authority to expose the data it requires, will stop the project. Not immediately — slowly, in the form of delayed access, missed review cycles, and scope changes that surface six weeks in.
We ask this question first. If the answer is unclear, that's information.
What does the data actually look like?
We need to see the schema before we scope the work. Not a description of it — the schema.
This isn't distrust. It's that the description of a data model and the data model itself are almost always different, and the differences are almost always in the places that matter: how legacy records are structured, where the exceptions live, what fields are used inconsistently across record types, whether the identifier that seems like a primary key is actually unique.
We've scoped integrations based on a data description and then seen the schema and understood why the previous vendor's estimate was half of what it should have been. We're not willing to do that to a client or to ourselves.
What's the failure mode?
If the integration fails — if data stops flowing, if a sync runs twice, if a record gets dropped — what happens? Does a payment get delayed? Does a customer not receive a confirmation? Does a compliance record go missing?
The answer to that question determines how we build the error handling, the retry logic, the alerting, and the audit trail. A low-stakes integration where a failed sync means a dashboard number is stale for an hour gets built differently from one where a dropped record means a regulatory filing is incomplete.
We ask this before we start, not after, because the cost of getting it wrong is very different depending on what the failure mode is.
What's the expected lifespan?
We build integrations to last. That means making choices — about data contracts, about versioning, about how changes on either side are communicated — that add time to the build but reduce operational cost over the life of the system.
If you need something running in three weeks and expect to replace it in six months, that's a legitimate use case, and it calls for a different kind of build than a system that's expected to be running for five years. We can do either. We need to know which one we're building.
The question we're really asking
Underneath all of these is a single thing we're trying to establish: whether both sides understand what the project actually is. Integration work has a way of looking simpler than it is from the outside. The questions above are how we find out, before we start, whether that's the case here.
If the answers are clear, we'll scope accurately. If they're not, we'll tell you that the discovery needs more time. That's not a delay — that's the work.