Maintenance Release · July 2026 · In Progress

Patch Notes

Making the consolidated platform safe to change, possible to see into, provably correct, and formally reviewable — a staging-first pipeline, error monitoring and a status page, a schema-drift correctness batch, and a SOC 2 review. These notes cover work through mid-month.

Release Window July 2026 · In Progress
Theme Hardening
Upgrades 11 so far
Coverage Platform-wide

June consolidated the platform; July hardened how we ship to it. The through-line this month is making every change safe, observable, and provable.

Staging-First Delivery Pipeline

What
Every change now flows through a fixed path: feature branch → reviewed pull request → staging → promotion → production, with required automated checks and separation-of-duties approvals before anything reaches production.
Why
Shipping straight to production means every deploy is a bet. A staging-first pipeline with required checks and two-party approval turns deploys from a bet into a routine — and gives us the change-management trail a security review expects.
Impact
Changes reach production only after review, automated checks, and staging. Deploys are routine and auditable.

Staging Environment

What
Stood up a full staging environment with its own isolated database and its own vendor credentials, separate from production.
Why
Testing against production data is how you turn a test into an incident. An isolated staging environment lets us exercise real changes end-to-end with zero risk to live agencies.
Impact
Every change can be validated against a production-like environment before it goes live.

Local Dev Environment + Onboarding

What
Built a one-command containerized local environment (full schema plus seed data) and a developer onboarding guide, so a new engineer can run the whole platform locally on day one.
Why
If standing up the platform locally takes a week, every new contributor is slow and every environment is slightly different. A reproducible local stack plus a written onboarding path makes ramp-up fast and consistent — and keeps prod access on a need-to-have basis.
Impact
New engineers ramp on a reproducible local stack instead of touching production to learn.

You can't run what you can't see. July wired in the missing eyes.

Error Monitoring

What
Instrumented the application with end-to-end error monitoring so failures surface with context instead of being discovered by a client.
Why
Without error monitoring, the first report of a bug is a complaint. With it, the team sees the error — and the stack trace — before the client does.
Impact
Application errors surface proactively, with the context needed to fix them.

Public Status & Uptime Page

What
Stood up a public status and uptime page for the platform's services.
Why
A status page is table stakes for a platform others depend on: it answers "is it down for everyone or just me?" without a support ticket, and it's a standing signal that uptime is monitored.
Impact
Platform uptime is publicly visible and continuously monitored.

A batch of real production bugs, caught by a full audit of the data layer.

Schema-Drift Bug Batch

What
Fixed a cluster of bugs where application queries pointed at database columns that no longer existed — including lead distribution and plan/seat entitlements — added the missing columns, and removed dead code paths. Closed out with a full data-layer drift audit and a green test suite.
Why
Schema drift is silent: the database evolves, an old query keeps referencing a renamed or removed column, and the feature quietly returns nothing or errors on every call. One query in this batch was failing every lead-distribution call; another was silently collapsing every client's seat allocation. These don't announce themselves — they just underperform until someone audits.
Impact
Lead distribution and entitlements query real columns again. The data layer was swept end-to-end for drift.

Lead Sync — Snapshot Correctness

What
Republished lead-capture and nurture workflows that were sitting in draft across most sub-accounts, and baked them into the base snapshot so newly-provisioned agencies inherit them automatically.
Why
A lead-capture workflow stuck in draft looks fine in the builder but never runs — leads land as contacts and never enter the pipeline. Fixing the live accounts stops the bleeding; baking the workflows into the snapshot stops it from ever coming back on the next new agency.
Impact
Lead capture and nurture run across the roster, and new agencies inherit working workflows by default.

Following June's auto-refresh work, the connection-token path got the monitoring and recovery it still needed.

Connection Token Reliability — Hardening

What
After a recurring token-expiry pattern kept dropping CRM connections, added batch recovery plus a monitor that alerts when tokens lapse and when an agency's visible calendar count drops abnormally low.
Why
June's auto-refresh reduced the lapses but didn't end them, and a silently-expired token means an agency goes dark on lead sync. A monitor that catches both the lapse and its downstream symptom (calendars vanishing from view) means the team is alerted before the agency notices.
Impact
Token lapses are caught and recovered quickly, with alerting instead of silent failure.

We put the platform through a formal security review — and this page is part of the result.

SOC 2 Readiness

What
Worked the platform through a formal SOC 2 readiness program: access reviews across every role, a complete vendor and subprocessor register, documented change management, and security-awareness training.
Why
SOC 2 is how a platform proves — to agencies and their clients — that access, vendors, and changes are governed rather than improvised. It turns "trust us" into "here's the evidence."
Impact
The platform's access, vendors, and change process are documented and reviewable against a recognized standard.

Vulnerability Scanning + Penetration Test

What
Enabled continuous dependency and vulnerability scanning on the codebase and commissioned an independent third-party penetration test.
Why
Automated scanning catches the known issues continuously; an independent penetration test catches the ones a scanner can't. You want both, and you want the second one run by someone who doesn't work here.
Impact
Known vulnerabilities are surfaced continuously, and the platform was probed by an independent external team.

Public Change Log

What
Promoted this release-notes archive to the platform's public change log — the page you're reading is now the canonical, ongoing record of every maintenance release.
Why
A public change log is both a compliance control and a courtesy: agencies can see exactly what changed, when, and why, without asking. It's the difference between maintenance that happens to the platform and maintenance the platform is transparent about.
Impact
Every monthly release is now documented in the open, here.
Cross-Month Theme

Consolidation, then hardening

June was consolidation — one template, one widget set, one home for credentials. July is hardening — making the consolidated platform safe to change (staging-first pipeline, isolated environments), possible to see into (error monitoring, a public status page), provably correct (the schema-drift batch), and formally reviewable (SOC 2, penetration testing). Correctness → infrastructure → audit → consolidation → hardening: five months of turning a working system into a governed one.