Professional work · Architecture
Webel
Home-services marketplace. I am responsible for the whole web platform: the B2C app that thousands of people use every day, the B2B platform behind company profiles, the internal dashboard, SEO, email, and the shared component library.
- Company
- Webel
- Period
- 2024 — present
- Role
- Responsible for the web platform
- Scope
- B2C app, B2B platform, internal dashboard, SEO, email, and the component library the three products share.
- Status
- Live
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 own the web area. I decide the architecture, write the implementation, and keep maintaining it afterwards. Requirements come from Product; the technical calls are mine.
The three applications
The B2C app, used by thousands of people a day. The B2B platform where company profiles manage staff, services, calendars, leads, chat, service areas, tax details, and payouts: those profiles generate close to 25% of Webel's GMV, over €500k a year. And the internal dashboard the team uses to run the whole marketplace.
One stack
I migrated the B2C marketplace from Angular to React, extracted the design system into a component library that B2C, B2B, and the dashboard now consume, moved email development to React Email, and built the SEO surface in Astro.
Working with agents
I write the specifications and skills the agents work from, and keep the design-system documentation current so I can review what they produce. The code, the tests, and the final call are mine.
What else it covers
- Programmatic SEO and structured data.
- Transactional email.
- DAC7 flows, claims handling, and lead capture.
- Responsive redesigns of applications that only worked on desktop.
Where my part ends
Product sets and prioritises the requirements. I get involved in scope and propose simpler alternatives when I see one, but the product call is not mine. I work the UI through with Design. Inside web, I review another developer's work and pull requests.
Decisions
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 large applications share a language, conventions, and people. The marketplace became the public storefront that points to the apps.
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. I did the extraction and the refactor, and that library is now the base for new work.
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
- SEO stopped dragging along the build times and page weight of the rest of web, and content ships without touching the applications.
Results
The main applications share React, the same component library, and the same review standards.
EvidenceB2C, B2B, and the dashboard all consume that library today.
Emails are built and reviewed as components rather than as standalone templates.
EvidenceEmail development moved to React Email.
What I delegate to agents arrives with a specification and criteria, so it gets reviewed like any other pull request.
EvidenceSpecifications with acceptance criteria, reusable skills, and design-system documentation.
About the numbersSEO template counts, email volumes, and total user numbers are internal and are not published here.
Inside
Click to enlarge
01 / 04
01The internal dashboard, with the breakdown that is hardest to get right: commissions and VAT on both sides. 02An organisation's calendar: one row per worker, each service in its slot. 03Balance on mobile: what's available, what's pending, and which service each euro came from. 04The service chat: moving a date is a proposal the customer accepts, not a change that just happens.