The problem
We kept building similar insurance purchase journeys for different partners. Each product had its own branding, questions, content, and flow. Repeating the implementation became a delivery bottleneck.
At the same time, not every difference belonged in a shared abstraction. Some partner needs were still too specific or too uncertain.
What we changed
I started the journey-creator foundation as a Senior Software Engineer and kept building it after becoming Engineering Manager. The team used a configurable frontend and a reusable component catalogue to support different products, countries, partners, and flows.
I focused much of my coding work on the shared frontend pieces. A sibling team owned the backend product configuration, and we worked together on the structure and meaning of the configuration.
The platform supported at least 18 product configurations across five countries and more than ten commercial brands or partner groups. The configurable capabilities reduced technical implementation from months to weeks. That range does not include external regulatory or commercial work.
A smaller tool with a large effect
I also built the first version of a self-service email tool. Content specialists could edit Markdown, preview the rendered email, validate variables, test it, and publish branded lifecycle emails without waiting for a development sprint.
What I would change
I spent too much time on our custom component library. It created consistency and reuse, but its ownership cost was too high for two products.
Today I would start with an established library unless a custom system created clear product value and had explicit long-term owners.