Trabajo profesional · Arquitectura
Webel
Marketplace de servicios a domicilio. Soy responsable de todo el departamento web: la app B2C, la plataforma B2B, el dashboard interno, SEO, emails y la librería de componentes compartida.
- Empresa
- Webel
- Periodo
- Finales de 2024 — actualidad
- Papel
- Lead Frontend Engineer
- Alcance
- Todo el departamento web: app B2C, plataforma B2B, dashboard interno, SEO, emails y librería compartida.
- 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 todo el departamento web. Decido la arquitectura, sigo escribiendo la implementación y mantengo lo que llega a producción. Producto define los requisitos; yo cierro las decisiones técnicas.
Las tres aplicaciones
La app B2C, que usan miles de personas al día. La plataforma B2B permite a las empresas gestionar equipos, servicios, calendarios, leads, chat, áreas de servicio, datos fiscales y cobros. El dashboard interno completa la operación del marketplace.
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 y criterios. Dejamos de repetir el mismo trabajo entre Angular y React y resulta más sencillo mantener lo que ya está en producción.
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. Los cambios de marca, accesibilidad y comportamiento se hacen una vez, con menos inconsistencias y menos cambios repetidos.
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ó
- Las páginas de contenido cargan HTML estático con menos JavaScript y se publican sin depender de los ciclos de las aplicaciones.
Resultado
Unificar Angular y React eliminó trabajo duplicado y simplificó el mantenimiento de las aplicaciones existentes.
EvidenciaB2C y B2B comparten ahora React, convenciones y herramientas de revisión.
La librería compartida redujo inconsistencias y cambios repetidos entre B2C, B2B y dashboard.
EvidenciaLos tres productos consumen hoy los mismos componentes base.
Astro mejoró el rendimiento de las páginas de contenido y permitió publicarlas sin tocar las aplicaciones.
EvidenciaHTML estático, datos estructurados y JavaScript solo donde hay interacción.
El flujo con agentes aumentó la frecuencia de entrega y redujo errores y retrabajo.
EvidenciaCada tarea parte de una especificación, contexto y skills; después pasa por pruebas y revisión del código y del resultado.
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.