At iptiQ, we built insurance purchase journeys for different partners, countries, products, and brands.

The journeys looked different, but many parts were familiar: questions, pricing, customer details, legal text, payment, and confirmation.

We kept building similar pieces for every launch.

The obvious answer was a configurable frontend. The difficult part was deciding what should become shared and what should stay specific.

The first product came before the platform

I built the first Quote & Bind journey as a Senior Software Engineer.

We had a real partner, a real launch, and requirements that were still changing. Trying to design a complete platform before shipping that first product would have delayed both.

I split the work into two groups.

Some capabilities were already stable. Underwriting questions, for example, had a structure we understood. We could define question types and render them from configuration.

Other requests were still too specific. We kept those inside the first product until we understood whether they represented a reusable pattern.

That meant accepting some code we might later replace. I still think that was the correct tradeoff.

Growing the shared frontend

I started the journey-creator foundation and kept working on it after becoming Engineering Manager.

The frontend used React and TypeScript. It combined a reusable component catalogue with configuration for products, countries, branding, content, and flow decisions.

A sibling team owned the backend product configuration. We worked together on the structure and meaning of that configuration.

My team focused on how those decisions became a customer journey.

The platform eventually supported at least 18 product configurations across five countries and more than ten commercial brands or partner groups.

The configurable parts reduced technical implementation from months to weeks. That range only covers the software work. Regulatory, commercial, and external partner work followed their own timelines.

The smaller tool I would still build

Lifecycle emails created another bottleneck.

Content specialists needed engineers to change branded emails. Even a small text update could wait for a development sprint.

I built the first version of a self-service email tool. It let content specialists edit Markdown, preview the result, validate variables, send a test, and publish the email themselves.

That tool was much smaller than the Quote & Bind platform, but its value was easy to see. It removed a repeated dependency between two teams.

Where I spent too much time

We also built a custom component library.

It gave us consistency and helped the two products share interface patterns. I enjoyed working on it, which probably made the problem worse.

In retrospect, I spent too much time there.

The library had a real maintenance cost, and only two products used it. We had to own accessibility, documentation, upgrades, and every edge case ourselves.

Today, I would start with an established library unless custom components created clear product value and had explicit long-term owners.

What stayed with me

Reuse is useful when the product model is stable.

It becomes expensive when a team abstracts requirements it does not understand yet.

The Quote & Bind platform worked because we did not require every difference to fit the shared model on day one. We shipped the first product, learned from the next ones, and moved capabilities into configuration when the pattern became clear.

That approach is less tidy on a diagram. It is often much better for getting a real product out.