Mirror Mirror · Webinar · Chapter 6

Integration: Where Your Systems Talk

How the stack holds together when no one is watching.

Friday, June 12, 2026 · 10:30 AM MST

Brady Hugins · Witch Haven Grove LLC

Where we are in the arc

Six chapters in. One to go.

Ch 1 · May 1
Spine: Contact Profile
Ch 2 · May 8
Plan: Rental → Ownership
Ch 3 · May 15
Rhythm: Weekly Checks
Ch 4 · May 22
Engines + Automation
Ch 5 · May 29
Delivery: Shipping It
Ch 6 · TODAY
Integration
Ch 7 · Jun 19
Owning the System

You've built the spine, the plan, the rhythm, the engines, the delivery. Today is the chapter where they stop being five separate things and become one system.

What we mean by integration

Integration is not more tools. It's agreement.

Every system you connect is a chance for two of them to disagree about the truth. Integration is the discipline of making sure they can't — that for every fact, exactly one system gets to be right.

A broken integration doesn't crash. It drifts. Two systems quietly hold two different versions of the same customer, and you don't find out until one of them sends the wrong email to the wrong person.

Principle one

Single source of truth. One owner per fact.

For each shape of data — a contact, an order, an event — exactly one system owns the canonical version. Everything else is a projection: a cache, a view, a copy that knows it's a copy. When you need the answer, you go to the owner. Never to a copy.

THE OWNER
The one table allowed to change the fact. Email subscribed? One place decides. Lifetime value? One place.
THE PROJECTIONS
Everything downstream reads from the owner. A page, an email merge, a dashboard — they reflect, they don't decide.

The moment two systems both think they own a field, you have a bug that's been shipping for weeks before anyone notices.

Principle two

Observability beats reaction. See it in 24 hours, not 24 days.

The dangerous failures are the quiet ones — the job that runs every hour, returns "success," and does nothing. Integration without observability is a smoke detector with the battery out.

A TRUE STORY FROM MY STACK — THIS WEEK

My social publisher fired every 4 hours for 37 days and returned "success" every time — while posting nothing. A filter silently skipped every approved post. No alarm, because nothing errored. I only caught it when I built a monitor that asked the right question: "fired, but published zero?" Now that gap surfaces in 24 hours, forever.

Send logs · daily digests · scheduled audits that count what should have happened vs what did. The audit is cheaper than the apology.

Principle three

Webhooks are how systems talk. Retry is how they forgive.

A webhook is one system tapping another on the shoulder: "this just happened." But the tap can be missed — the receiver is down, the payload is malformed, the third stage throws. Resilient integration assumes the tap will be missed, and builds the catch-net first.

IDEMPOTENCY
Same event twice = one result. Keyed on the event id, not the clock.
RETRY
Failed once, try again with backoff. Most failures are transient.
DEAD-LETTER QUEUE
The ones that still fail land in a DLQ — not the void. You replay them tomorrow.
REPLAY
A button that re-runs yesterday's failures once the bug is fixed. Nothing is lost.

Every payment, every signup in my stack flows through one DLQ writer. A failed Stripe webhook is a row I can replay — not a customer who paid and got nothing.

Real-stack walkthrough

Eight brands. ~245 workflows. One contact spine.

HOW A SIGNUP STAYS COHERENT ACROSS 8 BRANDS
  1. One door per form: every signup hits one Standard Form Handler.
  2. One owner: it upserts the person into one contacts table — keyed on email.
  3. Append, don't overwrite: a new brand tag is added, prior engagement is never erased.
  4. Profile vs operations split: the public profile lives in one place, the email/SMS state in another — each with one owner, by a written rule.
  5. Everything downstream reads the spine: pages, blasts, dashboards — projections, all of them.

The brands feel separate to the customer and are one system underneath. That's the whole game: looks like eight, runs like one.

The discipline behind it

Write the rule down before you wire the systems.

Integration drift doesn't come from bad code. It comes from an unwritten decision — "which table owns this?" — that two builders (or one builder, two months apart) answered differently. The fix is boring and it works: a canonical-home rule, in writing, that the audit enforces.

CANONICAL HOME
For each field: one table owns it. Written down. Not "felt right."
AUDIT ENFORCES IT
A script that flags when a workflow writes to a field it doesn't own.
DEPRECATION REGISTRY
Renamed a field? The registry catches every stale reference within a day.

Q&A

Your stack. Where does it disagree with itself?

Which fact in your business lives in two places — and what happens when they disagree?
If a job ran "successfully" but did nothing for a month, would you know? How?
When a payment webhook fails, where does it go — a queue you can replay, or the void?

Bring the specific. We'll map your real integration, not the ideal one.

Next Friday closes the arc · Ch 7 · Jun 19 · Owning the System Forever

Build what you saw today.

COURSE · $297
7-day Data Sovereignty Course. The whole arc, delivered as a build path.
For: ready to build solo, self-paced.
LIVE COHORT · $497 (or team from $499/mo)
6-week guided cohort. Live sessions, small room, real accountability — the course as a sprint.
For: wants a room and a deadline.
MEMBERSHIP · $33/mo
Live office hours + the Mirror Mirror operator newsletter. Direct access for ongoing questions.
For: wants ongoing accountability.

mirrormirror.roseinthegrove.com

1 / 10