Obie’s authorization system couldn’t handle program‑level restrictions, staged rollout, or underwriting constraints. I reframed the data model, skipped Figma, shipped a clickable prototype in 48 hours, and led the redesign that kept launch on track.
On Feb 2, the head of engineering asked me to fix “every possible scenario.” This wasn’t a UI polish request — it was a structural problem that could derail the homeowners launch.
We were preparing to roll out to 1,300+ partner agencies in staged waves (12 → 1,300). The authorization system created 300+ database rows per partner, relied on massive joins, and couldn’t express program‑level restrictions, staged rollout controls, or layered underwriting rules.
“Ever since we ripped out the real functionality, it’s been one fire drill after another. If this lands on homeowners and we blow the deadline, it’s on me.”
Lead Engineer (anonymized)AD, Underwriting, and Compliance each had different constraints — and the system had to satisfy all of them on day one, not “later.”
Instead of tracking everything a partner couldn’t do, I proposed an allowances model: define baseline capability, then layer explicit exceptions. That shift aligned with how admins think and gave engineering a structure that could actually scale.
carrier_partner_restrictions 1 partner × 51 states × 6 carriers = 306 records per partner Problems: • Massive table joins • No program-level support • Slow to maintain
partner_programs (JSONB) 1 partner = 1 record Allowances model: • Missing = restricted • Explicit exceptions • Rules-engine compatible
{
"EVANSTON_HO-3": true,
"EVANSTON_HO-5": {
"allEnabled": true,
"States": { "CA": { "aura": false }, "FL": { "aura": true } }
}
}
The existing restrictions UI assumed a provider‑only model. Homeowners introduced program‑level constraints (HO‑3 vs HO‑5) that didn’t map cleanly to the carrier structure, and the system couldn’t express those rules without hacks.
Markel REI = ProviderId + Carrier Markel HO = ProgramId + Carrier HO‑3 + Evanston HO‑5 + Evanston
Instead of drafting screens, I built a clickable, web‑hosted prototype in 48 hours and walked each stakeholder through their real use cases on the call. We made changes together as they interacted with the prototype — no “go back to Figma, schedule another meeting” loop.
Over 2.5 weeks, the interface evolved based on constant feedback from engineering, PM, and underwriting. Each version solved a specific scaling or clarity problem the last one exposed.
Mid‑project, I discovered the AD team and Engineering had opposing interpretations of how restrictions should work. AD wanted fast rollout controls without state complexity; Engineering needed a durable system that could handle edge‑case restrictions. I facilitated a level‑set that reframed the conflict as layered systems, not competing requirements.
AD Team model - State licensing = access - Programs managed separately - “Why program-level state restrictions?”
Engineering model (Swiss cheese) - Licensing, moratoriums, program rules - Any layer can block access - Needs state-by-program granularity
The final system supported bulk operations, state‑level overrides, and a clear audit trail without overwhelming admins who only needed simple enable/disable workflows.
When the lead engineer asked for “every possible scenario,” I didn’t stall or scope‑reduce. I reframed the data model, built working prototypes in days, and aligned cross‑functional teams around a system that could scale. This is the kind of work I love: high‑stakes, high‑ambiguity, and deeply technical — and it’s the kind of leadership I bring to founding‑team environments.