Ari, and trunk-based delivery on a customer-facing surface

The lead role was a chance to do two things at once: ship a product surface operators would actually adopt, and tighten the delivery system underneath it so the team could move with confidence.

The framing

Two threads. One was a product question — what does the dashboard look like if it is designed around the decisions an operator is actually making? The other was a delivery question — what does the release loop look like if every change is small and shipped against the same environment production runs in?

What changed — Ari and the workflow

• Led the architecture and launch of Ari end to end.
• Redesigned operator workflows into intuitive single-page UIs — fewer hops, fewer modals, fewer screens that exist only to bridge other screens.
• 60% growth in dashboard adoption post-launch.

What changed — delivery

• Trunk-based development as the default; long-lived branches treated as a smell, not a strategy.
• Containerized CI so every change shipped against an environment that matched production.
• 85% reduction in production bugs.
• 99.9% uptime sustained on a customer-embedded widget.
• Code review to production deploy compressed from days to minutes-to-hours.

The harder work

Most of the harder work was not technical. It was building the team’s confidence to push small changes without ceremony — and being willing, as the lead, to be the person who reviewed the first ten of those small changes carefully so the eleventh felt safe.

Outcome

A surface operators chose to use, on a delivery pipeline that stopped surprising the people who depended on it. Mentored engineers carried the new defaults forward after I rolled into the post-acquisition work.