From Code to Configuration

The Situation

Launching a new insurance product took two years.

Business users (product owners and analysts) at Haven Technology maintained detailed checklists of every underwriting requirement: if the applicant is in the armed forces, decline. If BMI is above a certain threshold, adjust the rate class. If they've had a specific diagnosis within a lookback period, flag for review. They knew the logic cold.

But every change required a Jira ticket to engineering. Engineers translated those requirements into nested if-then trees in code. The more complicated a rule, the longer it took to code correctly with all the edge cases. Miscommunication between a business requirement and its code implementation meant potential underwriting errors, which in insurance is a serious risk.

Haven Technology's leadership wanted to sell more insurance products faster. The existing workflow was the bottleneck.

The Diagnosis

Hundreds of unique rules. Three structural patterns.

The obvious framing was "business users can't self-serve, so build them a form builder." But the problem was deeper than access.

I started by mapping the full underwriting org to understand who knew what and who was blocked from acting on what they knew. Then I audited the existing codebase and the business users' own artifacts: their annotated application questions, their spreadsheets mapping rules to conditions, and the handwritten notes they used to track underwriting logic. Engineers were building each rule as a custom implementation with bespoke logic. Hundreds of rules, each coded as if it were unique.

Before: How business users tracked underwriting rules

Business users maintained detailed spreadsheets mapping application questions to underwriting logic. They annotated conditions, lookback periods, and edge cases by hand. They knew the rules cold but had no way to implement them without filing tickets to engineering.

But they weren't unique. When I looked at the underlying structure rather than the surface-level variety, nearly every rule was a variation on one of three patterns:

This was the key diagnostic insight: the business didn't need a general-purpose rule builder. They needed constrained interfaces designed around these three structural patterns. Constrained was the point. A form that knows it's building a Lookback rule can guide the user, validate inputs, and prevent errors in ways a generic builder can't.

The Intervention

Constraint over flexibility.

The engineering team's instinct was to build a general-purpose rule builder that could model anything. I argued for the opposite: three specific rule-creation interfaces, each tailored to one structural pattern.

Each interface constrained what users could input in ways that matched how the underlying logic actually worked. A Standard rule form offered condition/outcome pairs with dropdowns for valid data types and operators. A Lookback rule form added a time window selector that enforced valid lookback periods. Aggregation rules got a different interface entirely, letting users select which existing rules to aggregate and define thresholds.

After: Standard rule (constrained form)

A Standard rule: condition → decision → output. The form constrains inputs to valid options. A business user can configure this in minutes.

After: Lookback rule (constrained form)

A Lookback rule adds a time window and property checks. The interface enforces valid lookback periods automatically.

This covered roughly 80% of underwriting rules. For the remaining edge cases with logic too complex for the constrained forms, I designed Freestyle mode: a structured frontend that let engineers configure rules faster without dropping back into raw code. This was a deliberate scoping decision. Rather than trying to make the business-facing UI handle every possible case, I drew a clear line: constrained interfaces for the patterns that repeated, and a faster engineering tool for the exceptions.

Freestyle mode: engineering's fast path for edge cases

For the ~15-20% of rules too complex for the constrained forms, Freestyle mode gave engineers a structured frontend. Faster than raw code, without compromising the simplicity of the business-facing interfaces.

The design went through five or six major iterations, each tested against real underwriting rules from Haven Simple. Early versions explored basic if-then toggles, which broke down as soon as rules got conditional on time windows or on the outputs of other rules. That's what forced the structural-pattern approach. Surface-level simplification wasn't enough. The tool needed to understand the types of rules it was helping users build.

Rule dependencies made visible

The Workflow view made rule dependencies visible for the first time. Business users could see how rules connected and executed in sequence, rather than treating each one as isolated.

What Changed

Business users could configure rules directly.

Business users could configure the majority of underwriting rules directly, without filing tickets or waiting for engineering cycles. Engineers kept a faster path for edge cases through Freestyle mode, but were no longer the bottleneck for routine rule changes. The dependency between rules became visible through the Workflow view, so users could understand how rules interacted rather than treating each one as isolated.

The Outcome

Haven Simple: 90 days instead of two years.

Haven Simple was configured through the Rules Manager in approximately 90 days, compared to the roughly two-year timeline previous products had required. Business users adopted the tool for rule configuration, and engineering tickets for routine rule changes dropped significantly.

The company dissolved before the tool reached full commercial rollout across multiple products. But the system worked: validated against a real product, used by actual business stakeholders, and demonstrated that the structural-pattern approach could handle real-world underwriting complexity.

My Role

Sole designer. Codebase auditor. System architect.

I was the sole designer embedded in an engineering team. I personally audited the codebase and the business users' own artifacts to identify the three rule patterns, which was the diagnostic move that shaped the entire product direction. I designed every iteration of the rule configuration UI, tested against real underwriting rules, and made the scoping decision to split between constrained business interfaces and Freestyle engineering mode.

The call I owned: choosing constraint over flexibility. The engineering team's instinct was to build a general-purpose rule builder. I argued that understanding the domain well enough to constrain the tool was the higher-leverage move, and the 90-day Haven Simple configuration validated that bet.