Integration is where
the demo becomes real.

Your prototype worked beautifully on the sample CSV. Then you pointed it at the customer’s real system and everything the sample data hid showed up at once: fields that are sometimes null and sometimes “N/A”, an auth flow stricter than your test key, an API that 403s from inside their network, and a service that times out one call in fifty. This is the moment most deployments stall — not because the idea was wrong, but because the last mile to real data is genuinely hard.

The FDE response is counter-intuitive: attempt a real connection early, before the solution is polished. Getting one live system connected in week one — even read-only, even ugly — surfaces the auth, network, and data-shape realities while you still have time to design around them. Saving integration for the end is how a great demo becomes a dead POC.

The choice is as much political as technical. The cleanest design is worthless if the customer won’t grant the access it needs. Often you’ll take the second-best integration because it’s the one their security team will approve this quarter — a nightly SFTP drop instead of live DB access, say. Design for what you can actually get.

Before any data flows, you have to authenticate into systems that were built to keep strangers out. The mechanism varies, and matching it correctly is half the battle.

When auth fails — and it will — it’s almost always one of a few things: the token in the wrong place or format, a missing scope, clock skew breaking a signed request, or the customer’s network not allow-listing you. The integration debugging playbook is the checklist; OAuth specifically is worth a deep read in the auth handbook.

Every external call can fail — time out, rate-limit, 500, or silently double-deliver. Design as if they will, and a fragile integration becomes a durable one. These patterns are so central to FDE work that each has a hands-on challenge in the track.

None of these is exotic. Together they’re the line between “it worked in the demo” and “it’s been running at the customer for six months.” If you internalize one thing from this handbook, internalize idempotency: it’s the pattern that makes every other retry safe.

Once bytes are flowing, they’re rarely in the shape you want. Customer data is a museum of history: inconsistent field names, mixed date formats, nulls that mean five different things, and encodings from three decades of systems. Two jobs recur on every deployment.

Both jobs are deceptively important. A silent mapping bug corrupts trust in the whole system; a good reconciliation report is often the artifact that convinces a skeptical customer the migration actually worked. Practice both in the CSV schema mapper and reconciliation diff challenges — they’re modeled on exactly this work.

Finally, a truth every FDE learns the hard way: it works on your laptop and fails from the customer’s box. The environment is different — different network, different egress rules, different clock, different certificates. So debug from where the code actually runs, not from your machine.

Integration is unglamorous, and it’s the FDE’s highest-value skill precisely because it’s where the value gets real. Get through it and you’ve earned the right to the fun parts: the demo, and turning the POC into something the customer depends on. Next in the track: turning a working integration into a scoped, demoable deliverable — and beyond, deployment in the customer’s own environment.