Inventario de componentes
Qué existe, qué se usa, qué está muerto. Contabilidad honesta, no una lista de deseos.
// desarrollo react
React, hecho con disciplina.
Trabajo React para equipos cuya base de código tiene tres versiones de gestión de estado pegadas con cinta. Reconstruimos lo frágil y enviamos lo que faltaba.
// donde los equipos se atascan
Vuestra app React se publicó. Y ha seguido publicándose.
- Tres librerías de estado peleándose por el mismo store.
- Proliferación de componentes — doce botones, cuatro de ellos muertos.
- Tests que pasan en local y fallan en CI por razones que ya nadie recuerda.
- Ingenieros junior que tienen miedo a refactorizar porque nada tiene tipos.
// qué incluye
Qué dejamos atrás.
Decisión de estrategia de estado
Un patrón de store, escrito, defendido en el documento de arquitectura.
Disciplina de hooks
Custom hooks donde pagan, no como decoración. Reglas de hooks aplicadas en lint.
Cobertura de tipos en la frontera
Respuestas de API, inputs de formulario, parámetros de ruta. Los sitios donde los tipos pillan bugs reales.
Camino de migración hacia adelante
RSC donde tiene sentido, client-only donde no. Documentado en cualquier caso.
// cómo trabajamos
Tres fases. Construido para durar.
01 · Calibrar
Auditoría de la base de código. Alcance escrito. Qué se queda, qué se reconstruye, qué se borra.
02 · Construir
Demo semanal. PRs revisados contra el documento de arquitectura. Nada de "un refactor más".
03 · Entregar
Documento de arquitectura actualizado. Tests en verde. Ventana de soporte abierta. Vuestro equipo es dueño.
// preguntas frecuentes
Lo que los equipos preguntan antes de firmar.
Sí. Hemos hecho 17 → 18, 18 → 19. Con un plan de migración escrito, probado por etapas, no un fin de semana big-bang.
Sí. Cada proyecto incluye una ventana de soporte tras el lanzamiento. Después, planes opcionales de cuidado continuo cubren correcciones, actualizaciones de dependencias y mejoras pequeñas — dimensionados a vuestro equipo y pausables mes a mes.
Usamos RSC donde las ganancias de fetching de datos son reales y los evitamos donde la complejidad client-side no compensa. El documento de arquitectura explica cuál es cuál.
Donde pagan. No perseguimos números de cobertura. Probamos fronteras — pagos, auth, integridad de datos.
Murcia, España. Remoto con clientes de Europa, Reino Unido y Norteamérica.
¿Tienes un problema difícil?
Respondemos en menos de 24 horas. Cuéntanos qué estás construyendo.
Hablemos →