Soluciones
La capa que nadie ve y de la que depende todo lo demás.
APIs, modelo de datos, permisos e integraciones. Es donde se decide si un sistema se puede cambiar dentro de tres años o hay que reescribirlo.
Cuándo hace falta
Síntomas de una capa de datos que ya no sostiene.
Casi nunca llega alguien pidiendo «un backend». Llega describiendo esto:
- Cada cambio pequeño rompe algo en otra parte y nadie sabe predecir dónde.
- La misma regla de negocio está escrita en tres sitios, y ya no coinciden.
- Hay una integración que funciona porque alguien la reinicia cada mañana.
- La aplicación móvil y la web dan números distintos sobre el mismo dato.
- Nadie puede responder quién cambió un registro ni cuándo.
- Se valida en el navegador y se confía en que nadie llame a la API por su cuenta.
Qué construimos
Piezas de la capa de servicio.
APIs de producto
Contratos versionados, con autenticación, autorización por rol y validación en el servidor. Documentadas para que otro equipo pueda consumirlas sin preguntarnos.
Integraciones
ERP, CRM, facturación, pagos o sistemas internos, por API o por intercambio de archivos, con límites explícitos de responsabilidad.
Modelo de datos
Estructura, restricciones y migraciones controladas. Las reglas del negocio viven en un solo lugar y se pueden leer.
Identidad y permisos
Inicio de sesión propio, corporativo o federado, con roles de granularidad real y no dos niveles de administrador.
Procesos en segundo plano
Trabajos programados, colas y reintentos para lo que no puede ocurrir dentro de una petición del usuario.
Trazabilidad y reportes
Registro de quién hizo qué y cuándo, y las exportaciones que el área operativa pide todos los meses.
Cómo se construye
Decisiones que se toman una vez y se pagan durante años.
Decisiones que se toman una vez y se pagan durante años.
Un backend no se juzga el día que se entrega, sino el día que hay que cambiarlo con el sistema en producción y con datos que no se pueden perder. Estas son las decisiones que hacen que ese día sea un martes normal y no una crisis.
- Validación y autorización en el servidor. El navegador es una comodidad, no una defensa.
- Operaciones idempotentes: reintentar no duplica un cobro ni un registro.
- Contratos versionados, para que un cambio no rompa a quien ya consume la API.
- Migraciones reversibles y probadas antes de tocar producción.
- Auditoría de las operaciones sensibles, desde el primer día y no cuando se pide.
- Ambientes separados y datos de prueba que no son una copia de los reales.
- PHP
- MySQL
- Firebase
- REST
- GraphQL
Cómo se entrega
Del contrato a la operación.
Contrato
Qué expone el sistema, para quién y con qué garantías. Antes de escribir código.
Modelo
Datos, estados y reglas. Documentado y revisado con quien conoce el negocio.
Construcción
Incrementos utilizables, con pruebas automatizadas sobre las reglas críticas.
Verificación
Carga, permisos, casos límite y revisión de seguridad antes de publicar.
Operación
Observabilidad, alertas y traspaso de conocimiento a quien lo va a mantener.
Este trabajo existe dentro de los sistemas que aparecen en /casos: son plataformas con su capa de servicio, no interfaces sueltas. Lo que todavía no hay es un caso publicado donde el backend sea el proyecto en sí. Es práctica documentada, no una línea con caso propio.
Revisemos la capa que ya tienes.
Con acceso al código y a la base de datos se puede decir bastante en una semana.