Run it in shadow mode first

There's a standard way integration projects go live. You build it in a sandbox, you test with a handful of records, you flip it on, and then you spend two weeks finding out what real data looks like. Some of that finding-out involves invoices that went to customers.

There's a better way, and it costs almost nothing to build: run the whole thing, compute every write, and don't make any of them. Show the diffs instead.

What shadow mode actually is

Every flow executes normally. It reads from HubSpot, applies the rules, works out that deal 41208 should produce a Stripe subscription with these three items at these prices, and that the resulting invoice should post to QuickBooks against this customer and these GL accounts.

Then, instead of calling the API, it writes the intended result to a table and renders it as a before/after.

The customer looks at a list that says: "We would have created 43 subscriptions. Here they are. We would have posted 61 invoices. Here they are. Eleven of them we couldn't compute, here's why."

Why it finds more than testing does

Test data is data you made up, which means it conforms to the rules you had in mind. Real data doesn't.

The eleven that couldn't be computed are the valuable part. In practice they cluster:

• Deals closed-won with no line items at all — someone closed the deal before configuring products
• Products on a deal that have no counterpart in billing, usually one-off services or an implementation fee
• A custom field the rules depend on (billing_start_date, contract_term) that's blank on a third of records
• Currencies that don't match between the deal and the customer
• Historical deals with prices from a catalog that no longer exists

None of these are bugs in the integration. They're the gap between the rules someone stated in a kickoff meeting and the data the business actually generates. Shadow mode surfaces that gap in a day, against every record, without a single side effect.

The second thing it does, which is the sales argument

If the customer already has a Zapier or Make setup running, shadow mode runs beside it. Same inputs, two computed outputs — theirs, which actually executed, and yours, which didn't.

Now the comparison is concrete: "Your current setup created these 38 subscriptions. We computed the same 38, and on four of them we get a different number. Here's why."

That conversation is very different from "trust us, ours is more reliable." Nobody argues with a diff against their own records. And it cuts both ways honestly — if the four differences turn out to be your bug rather than theirs, you find out before you've touched anything of theirs.

How long to stay in it

Long enough to see a full billing cycle, which for most SaaS companies means a month. That's the only way to observe renewals, proration on mid-term upgrades, failed payments and retries, and a month-end close.

Shorter is possible if the customer's volume is high enough that a month's worth of variety shows up in a week. Longer is a sign that nobody's actually reviewing the diffs, and shadow mode stops being useful the moment it becomes a dashboard nobody opens.

Going live, one flow at a time

Not all at once. The order should follow blast radius:

1. CRM writes first. A wrong deal amount in HubSpot is embarrassing and fixable in ten seconds.
2. Billing second. A wrong subscription charges a customer. Recoverable with a credit, but the customer sees it.
3. Ledger last. A wrong posting is in the books and needs a reversing entry, which means it needs an accountant.

Each one stays in shadow until its diffs have been clean for a week.

What it costs to build

Less than you'd expect, if the architecture is right. A flow that computes an intended write and then executes it can be split at that seam: compute always, execute conditionally. The diff renderer is a small amount of UI. The storage is one table.

The expensive version is the one where the computation and the API call are the same line of code, which is what happens when the integration is a chain of automation steps rather than a program. That's not a tooling limitation exactly — it's that no-code builders have no concept of "do all of this except the last part."

Which is a decent reason to write integrations that move money as code, even if a builder could technically do the happy path.

Every TruelineHQ flow starts in shadow mode and stays there until you're satisfied. Nothing is written until you say so. See how it works.