Webel

Problem and context

Webel connects people who need a service at home with the professionals who provide it. That operation runs through three applications with different users and different rhythms — customers, professionals, and the internal team — plus the SEO surface and the emails around them. Each one came from a different era of the product and shared very little with the others.

Who it's forCustomers booking a service, professionals and companies delivering it, and the internal team running the marketplace.

What I owned

I am responsible for the web department. I decide the architecture, still write implementation code, and maintain what reaches production. Product defines the requirements; I make the technical calls.

Decisions

1. 01

   Settle on React across the stack

   Situation

   The B2C marketplace ran on Angular while the rest of web was already React. Every new convention had to be decided twice, and the older codebase got touched as little as possible.

   What I decided

   Migrate the marketplace to React instead of keeping two platforms alive in parallel.

   Why

   The migration had a bounded, estimable cost. Carrying two frameworks got more expensive with every feature.

   What changed

   The main applications share a language and conventions. We stopped repeating the same work in Angular and React, and the existing applications became easier to maintain.

2. 02

   Pull the design system into a shared library

   Situation

   B2C, B2B, and the dashboard each carried their own slightly different buttons, forms, and tables.

   What I decided

   Extract the UI foundations into our own component library and consume it from all three products.

   Why

   An accessibility fix or a brand change should happen once, not three times.

   What changed

   All three products start from the same components. Brand, accessibility, and behaviour changes happen once, with fewer inconsistencies and repeated edits.

3. 03

   Build SEO in Astro rather than React

   Situation

   The SEO surface is content: many generated pages, very little interaction. Building it in the same React as everything else was the convenient option.

   What I decided

   Build it in Astro, with static HTML and structured data.

   Why

   On content pages, shipping a React runtime to the browser is cost with nothing in return. Astro serves HTML and only hydrates what needs it.

   What changed

   Content pages load as static HTML with less JavaScript and can ship independently of the applications.

Results

• Consolidating Angular and React removed duplicate work and made the existing applications easier to maintain.

  EvidenceB2C and B2B now share React, conventions, and review tooling.

• The shared library reduced inconsistencies and repeated changes across B2C, B2B, and the dashboard.

  EvidenceAll three products now consume the same base components.

• Astro improved content-page performance and let us publish those pages without touching the applications.

  EvidenceStatic HTML, structured data, and JavaScript only where interaction needs it.

• The agent workflow increased delivery frequency while reducing errors and rework.

  EvidenceEach task starts from a specification, context, and reusable skills, then goes through tests and a review of both code and output.

About the numbersSEO template counts, email volumes, and total user numbers are internal and are not published here.