Why this CTO rebuilds every integration twice.

I asked Gil Feig what the secret sauce was at Merge. Not the strategy or the market timing — I meant the engineering decision that separates them from every other integration platform. He said it in three sentences, and then spent ten minutes explaining why.

“We rebuild the permission sync twice. So we sync all of it in one engine. We have another engine that was built by someone who did not see the original code base. And then those two have a task that runs between them and runs a statistically significant number of comparisons between them to make sure that the permissions are actually up to date.”

This is not what you do because you have time. This is what you do because the alternative is unacceptable.

Why permissions break everything

Permissions sound like a technical detail. It’s not. It’s the difference between shipping a product and shipping a liability.

Here’s the scenario: You sync all your company’s documents from Google Drive or Sharepoint into your system. An employee, fresh out of college, goes to ask an AI agent a question. They want to know something about the board deck from last month. The agent has access to that document.

That’s catastrophic. That’s sure-fire churn. That’s a call from your legal team.

“Permissions are really difficult,” Gil told me. “And this is for synced connectors. When you sync the full data set from a third party, you need to make sure that employee A, who just joined the company as a new grad, is not able to see the board deck from your last board meeting. And so in order to do that, these third party APIs also return the permissions. Who has the ability to view each specific file?”

The thing is: those APIs are often wrong. Not deliberately. Not even by design. They’re just incomplete. Permissions get cached. They don’t update instantly. They’re set at multiple levels (folder-level, file-level, via group membership). Edge cases exist that the API documentation doesn’t mention.

So you sync the permissions once, confident that you’ve got it right. Three months later, a user gets access to something they shouldn’t. Or worse, they can’t see something they should. Either way, you’ve broken their trust.

“If that’s wrong, the consequences are great. That is almost sure fire churn.”

The redundancy approach

This is where the dual-engine decision comes in. Instead of building one permission sync and hoping it’s right, Merge builds two. Independently. By different engineers who don’t see each other’s code.

Then they run comparisons. Statistically significant comparisons. Not just “do they match?” but “across thousands of permissions, across different customer setups, do they agree?”

“Those two then have a task that runs between them and runs a statistically significant number of comparisons between them to make sure that the permissions are actually up to date.”

This seems excessive. It is excessive. It’s also the cost of correctness.

When you have two independent implementations of the same logic, you’re not adding features. You’re building a verification system. If both engines agree, you have much higher confidence in the result. If they disagree, you’ve caught a bug that a single implementation would have missed entirely.

It’s the kind of engineering that doesn’t ship faster. It doesn’t look sophisticated in a demo. It’s boring. It’s exactly what infrastructure at scale requires.

What this teaches about system design

There’s a lesson here that goes beyond Merge. It’s about how to think about the systems you build when the cost of being wrong is high.

Gil described what happens behind the scenes: “While you’re seeing this really beautiful interface, you’re like, hey, what happened last week and while I was out and you’re getting all these answers back and whatever, behind the scenes, there’s a lot going on to make sure that you can only see the documents that you should be seeing.”

The visible part is clean. The invisible part is paranoid. That’s the right trade-off.

Most teams optimize for the opposite. They ship a clean interface with assumptions underneath that they hope are correct. They invest in looking good, not in being right. Then when a permissions issue surfaces, they’re surprised.

Merge invests in being right. That’s more expensive. It’s also the difference between a feature that works and a feature that enterprises will trust with sensitive data.

When redundancy becomes standard

The dual-engine approach is specific to permissions because the stakes are specific. But the principle applies anywhere you’re syncing data that determines access control. If an employee sees customer data they shouldn’t, that’s a problem. If a customer sees another customer’s data, that’s a much bigger problem.

For most of your system, redundancy is optional. For the permission layer, it’s essential. That’s the insight Gil’s decision surfaces. Not “always build things twice.” But “understand where being wrong causes real harm, and build differently there.”

That’s how you move from a product that works to a product that enterprises will stake their compliance on.

---

FAQ

Isn’t rebuilding everything twice inefficient? Yes, it’s inefficient to build. It’s necessary for correctness. When the cost of a permissions bug is losing a customer (or worse, a legal issue), the efficiency of building it once doesn’t matter.

How do you catch disagreements between the two engines? Automated testing. They run a statistically significant set of test cases and compare results. If the engines disagree, they investigate. If they agree consistently, they have high confidence.

Does this apply to non-permission data? It depends on how serious the consequences are if the data is wrong. For permissions, where the consequences are severe, dual implementations make sense. For syncing user metadata, maybe once is enough.

How much slower does it make the sync process? It doesn’t slow the sync itself (that’s still one engine). It adds a verification step afterward. That’s an acceptable trade-off for correctness.

What if the two engines disagree? You’ve caught a bug. You investigate. You fix it. That’s the whole point. Without the redundancy, you wouldn’t know there was a bug until a customer hit it in production.

Is this overkill for most teams? For enterprise data infrastructure, no. For a smaller product, yes. But the smaller products aren’t handling sensitive enterprise permissions either.

How does this relate to the context graph that Merge is building? The context graph also needs to respect permissions. The dual-engine approach ensures that the permissions feeding into that graph are correct. It’s the same principle applied at a different layer.

Can you do this in the cloud with automated testing? Yes. The dual engines don’t have to be separate physical systems. They’re separate codebases running in parallel. Merge probably uses CI/CD to orchestrate them.

---