Pick an API. Design a model. Implement a connector. Ship.

In reality, shipping integrations safely has very little to do with the happy path.

It depends on:

• Security boundaries
• Rollout discipline
• External vendor constraints

The code matters, but the safety around the code matters just as much.

The First Boundary: Credentials Are Not Normal Data

One of the earliest decisions that shaped the system was how to handle credentials.

Dealership-level tokens and secrets cannot be treated like ordinary application data.

If secrets leak into:

• Databases
• Logs
• Admin tooling
• Temporary configs

…you lose control of your system's security model.

So the separation needs to be explicit:

• Application state → normal storage
• Credentials → dedicated secret storage
• Access → tightly scoped and controlled

This is not just about protection.

It's about preventing bad patterns from becoming normalized as integrations scale.

Security Shapes Architecture

A clean secret model has second-order effects:

• Service boundaries become clearer
• Deployment permissions become stricter
• Debugging workflows change
• Adding new providers becomes safer

Security is not a layer you add later.

It is something that actively shapes how the system evolves.

Why Big-Bang Integration Launches Fail

At some point, it becomes tempting to ship everything together:

• Architecture
• Sync logic
• Credential handling
• UI flows
• Provider-specific behavior

All in one large change.

Even if the code is correct, this is risky.

Because:

• It's hard to review deeply
• It's hard to test in isolation
• It's hard to roll back safely

And most importantly:

You cannot tell which part caused a failure.

The Case for Phased Rollouts

Breaking integration work into smaller phases changes the outcome:

• Review becomes more effective
• Dependencies become visible
• Failures become easier to isolate
• Rollbacks become possible

But more importantly:

It forces better design.

When you cannot hide complexity inside a single PR, boundaries become explicit.

Vendor Reality Is a First-Class Constraint

Not all CRMs behave the same.

Some are easy to prototype against. Others require long approval cycles.

Some support flexible schemas. Others enforce rigid models.

Some align with real workflows. Others don't.

These differences are not edge cases.

They directly affect:

• Product behavior
• Mapping strategies
• Engineering timelines

Ignoring this leads to unrealistic plans and fragile abstractions.

Integration Is Not Just Backend Work

At scale, integration work sits across multiple domains:

• Product design (what should happen)
• Engineering (how it works)
• Operations (how it fails and recovers)
• Vendor coordination (what is actually possible)

That leads to non-obvious decisions:

• Sometimes you introduce a backlog instead of forcing real-time sync
• Sometimes you fall back to manual workflows
• Sometimes you delay features until abstractions are ready
• Sometimes you refuse provider-specific behavior that weakens the core product

These are product decisions as much as engineering ones.

Controlling Blast Radius

The common thread across all of this is simple:

Good integration design is about controlling blast radius.

• Security limits what can be exposed
• Phased rollouts limit what can break
• Abstractions limit where complexity spreads
• Vendor awareness limits unrealistic assumptions

Each decision reduces how far failures can propagate.

Final Thought

Integration work is often framed as:

"Connecting systems."

In practice, it's something else:

"Building systems that stay stable while everything around them is unpredictable."

If your integration increases system fragility, the design is wrong.

If it contains failure, limits risk, and scales safely, you've done it right.