Web Applications

Quote-and-bind rebuild for a pet insurer

Built by Bianca Yumul

Rebuilt a pet insurer's single 40-field quote form into a resumable multi-step flow, lifting completion 18 points — my first time leading a frontend team.

  • Builder email verified

    Verification

Type
Professional
Category
Web Applications
Published
Jul 26, 2026
Updated
Jul 26, 2026
Built withNext.jsReact Hook FormZodTypeScript
TopicsInsurance

About this project

The problem

The insurer's quote flow was one page with about forty fields, a progress bar that lied, and a premium calculation that arrived whenever the vendor rating engine felt like it — three to eight seconds, during which the page simply sat there. Abandonment was above sixty percent, and the call centre was quoting by phone for people who had given up online, which cost more per policy than the marketing that had acquired them. The brief was a full rebuild of quote-and-bind, from pet details to payment.

My role

Lead frontend developer — my first lead role — with two other frontenders, a designer, and a business analyst, for six months. Leading meant I wrote less code and reviewed more of it than I expected, and that the architecture decisions were suddenly mine to defend in the client's fortnightly steering call, which is a different skill from making them.

What I owned

I owned the flow architecture: the step engine, form state and validation strategy, the save-and-resume mechanism, and the integration contract with the rating engine. I also owned the frontend delivery plan, which meant being the person who said what was cut when the vendor API's quirks consumed two sprints — a kind of ownership nobody warns you about.

Technical & product decisions

Form state runs on React Hook Form with Zod schemas per step, and the same schemas generate the payload contract the backend validates against, so the frontend and backend could never quietly disagree about what a complete application was — that single decision erased a whole category of bug I'd fought on every previous form project. Resume lives server-side behind an emailed link rather than in localStorage, because the data showed people quote pets on their phone at the vet and buy on a laptop at home. We tested a one-question-per-screen design and abandoned it — completion looked worse in the prototype tests, people wanted to see progress in chunks — and shipped grouped steps instead, which the analytics later justified.

Constraints

The rating engine was a third-party vendor product that could not be changed or fronted, with its three-to-eight-second responses and an undocumented habit of returning a different premium for identical inputs if a breed synonym was used — we normalized breeds on our side and cached by normalized payload. Underwriting rules changed twice mid-project by decree of the client's actuary, which is exactly the kind of change the per-step schemas made survivable.

Result & impact

Quote completion rose eighteen percentage points in the first quarter after launch, and median time-to-quote landed under four minutes. Call-centre quote volume dropped enough that the client redeployed two staff from quoting to claims. The resume-by-email link — the feature I had to argue for hardest — is used by roughly a fifth of completed purchases, which I bring up whenever anyone calls a feature niche in a planning meeting.

Who else worked on it

The designer and I pair-tested every step on real phones, which is where the one-question-per-screen idea died and deserved to. The business analyst kept the underwriting rules honest between the actuary's revisions, the two frontenders on the team built half the steps and all of the payment integration, and the client's backend team met us in the middle on the shared schema contract, which not every client team would have.