Trabajo profesional · Arquitectura
Webel
Marketplace de servicios a domicilio. Soy responsable de todo el web: la app B2C que usan miles de personas al día, la plataforma B2B de los perfiles de empresa, el dashboard interno, el SEO, los emails y la librería de componentes compartida.
- Empresa
- Webel
- Periodo
- 2024 — hoy
- Papel
- Responsable del ecosistema web
- Alcance
- App B2C, plataforma B2B, dashboard interno, SEO, emails y la librería de componentes que comparten los tres productos.
- Estado
- En producción
Problema y contexto
Webel conecta a quien necesita un servicio en casa con el profesional que lo hace. Esa operación pasa por tres aplicaciones con usuarios y ritmos distintos —clientes, profesionales y el equipo interno—, más la superficie de SEO y los emails que las acompañan. Venían de épocas distintas del producto y compartían poco entre ellas.
Para quiénClientes que contratan un servicio, profesionales y empresas que lo prestan, y el equipo interno que opera el marketplace.
Mi responsabilidad
Llevo el área web entera. Decido la arquitectura, escribo la implementación y me quedo con el mantenimiento. Los requisitos llegan de Producto; las decisiones técnicas las cierro yo.
Las tres aplicaciones
La app B2C, que usan miles de personas al día. La plataforma B2B desde la que los perfiles de empresa gestionan empleados, servicios, calendario, leads, chat, áreas de servicio, datos fiscales y cobros: esos perfiles generan cerca del 25 % del GMV de Webel, más de 500.000 € al año. Y el dashboard interno con el que el equipo opera el marketplace completo.
Un solo stack
Migré el marketplace B2C de Angular a React, extraje el design system a una librería de componentes que hoy consumen B2C, B2B y dashboard, llevé los emails a React Email y monté la superficie de SEO en Astro.
Trabajo con agentes
Escribo las especificaciones y las skills con las que trabajan los agentes, y mantengo al día la documentación del design system para poder revisar lo que producen. El código, las pruebas y la decisión final los reviso yo.
Qué más incluye
- SEO programático y datos estructurados.
- Emails transaccionales.
- Flujos de DAC7, reclamaciones y captación de leads.
- Rediseños responsive de aplicaciones que solo funcionaban en escritorio.
Dónde acaba mi parte
Producto define los requisitos y prioriza. Entro en el alcance y propongo alternativas cuando veo una más simple, pero la decisión de producto no es mía. La UI la trabajo con Diseño. Dentro de web reviso el trabajo y las pull requests de otro developer.
Decisiones
Unificar el stack en React
- Situación
- El marketplace B2C estaba en Angular y el resto del web ya era React. Cualquier criterio nuevo había que tomarlo dos veces, y la parte antigua se tocaba lo justo.
- Qué decidí
- Migrar el marketplace a React en lugar de mantener dos plataformas en paralelo.
- Por qué
- El coste de la migración era acotado y se podía estimar. El de sostener dos frameworks crecía con cada funcionalidad nueva.
- Qué cambió
- Las aplicaciones grandes comparten lenguaje, criterios y personas. El marketplace quedó como escaparate público que dirige a las apps.
Sacar el design system a una librería compartida
- Situación
- B2C, B2B y dashboard repetían botones, formularios y tablas con tres versiones ligeramente distintas de cada cosa.
- Qué decidí
- Extraer las bases de UI a una librería de componentes propia y consumirla desde los tres productos.
- Por qué
- Un arreglo de accesibilidad o un cambio de marca tenía que hacerse una vez, no tres.
- Qué cambió
- Los tres productos parten de los mismos componentes. Hice la extracción y el refactor, y esa librería es hoy la base de lo que se construye.
Llevar el SEO a Astro y no a React
- Situación
- La superficie de SEO es contenido: muchas páginas generadas y poca interacción. Montarla con el mismo React que el resto era la opción cómoda.
- Qué decidí
- Construirla en Astro, con HTML estático y datos estructurados.
- Por qué
- En páginas de contenido, mandar un runtime de React al navegador es coste sin contrapartida. Astro sirve HTML y solo hidrata lo que lo necesita.
- Qué cambió
- El SEO dejó de arrastrar los tiempos de build y el peso del resto del web, y el contenido se publica sin tocar las aplicaciones.
Resultado
Las aplicaciones principales comparten React, la misma librería de componentes y los mismos criterios de revisión.
EvidenciaB2C, B2B y dashboard consumen hoy esa librería.
Los emails se desarrollan y se revisan como componentes, no como plantillas sueltas.
EvidenciaMigración del desarrollo de emails a React Email.
Lo que delego a agentes llega con especificación y criterios, así que se revisa como cualquier otra pull request.
EvidenciaEspecificaciones con criterios de aceptación, skills reutilizables y documentación del design system.
Sobre las cifrasLas cifras de plantillas de SEO, volumen de emails y usuarios totales son internas y no se publican aquí.
Por dentro
Pulsa para ampliar
01 / 04
01El dashboard interno, con el desglose que más cuesta cuadrar: comisiones e IVA de las dos partes. 02El calendario de una organización: una fila por trabajador y los servicios en su hora. 03El saldo en móvil: lo disponible, lo pendiente y de qué servicio viene cada euro. 04El chat del servicio: cambiar una fecha es una propuesta que el cliente acepta, no un cambio a secas.