Engineering resources

See what a well-defined project looks like.

Fictional scenarios, engineering decisions and sample deliverables you can inspect. These demonstrations do not represent client work.

EXAMPLE / DEMONSTRATION

Sample deliverables

These sample documents are provided in Spanish, with an accessible HTML version for reading and download.

EJEMPLO / DEMOSTRACIÓNDiscovery briefEntender el problema antes de definir pantallas.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Contexto

DEMO: solicitudes internas dispersas entre correo y hojas de cálculo.

Problema

No hay un estado central ni historial de quién autorizó una solicitud.

Usuarios

Solicitante, revisor, aprobador y administrador de la demostración.

Flujo actual

La solicitud viaja por correo, se revisa manualmente y se registra en una hoja.

Restricciones

Datos ficticios; sin pagos, compras reales ni envío de mensajes.

Preguntas abiertas

¿Una aprobación es suficiente? ¿Qué solicitudes requieren revisión adicional?

Decisión pendiente

Validar la separación entre quien solicita y quien aprueba.

Riesgo inicial

Trasladar excepciones del correo al sistema sin definirlas.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNScope / alcanceHacer explícito lo incluido y lo que queda fuera.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Objetivo

Centralizar solicitudes ficticias y hacer visibles sus cambios de estado.

Incluido

Registro, consulta, transición de estados según rol y auditoría.

Fuera de alcance

ERP, firma electrónica, archivos, pagos, usuarios reales y notificaciones.

Entregables

Interfaz React, API Spring Boot, migración, pruebas y guía de ejecución.

Supuestos

La demo utiliza un espacio temporal aislado por visitante.

Dependencias

PostgreSQL y un entorno Java/Node o Docker compatible.

Aceptación

Un solicitante no aprueba; las transiciones inválidas se rechazan; cada cambio se registra.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNArquitectura de referenciaMostrar límites y razones detrás del diseño.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Contexto

Demostración empresarial con reglas de autorización y auditoría.

Monolito modular

Permite una transacción para estado y auditoría; evita operación distribuida innecesaria.

Frontend separado

React presenta el estado; Spring valida permisos y reglas.

Persistencia

PostgreSQL mantiene las solicitudes y el historial de la demo.

Aislamiento

El espacio temporal de demostración no puede consultar leads, identidades ni facturas.

API

DTOs limitados, validación y respuestas sin detalles internos.

Estado

Las transiciones se validan en servidor, aunque la interfaz muestre las acciones disponibles.

Operación

Expiración y límites de datos para contener el costo de una demo pública.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNEstimación por rangosSeparar supuestos de precisión aparente.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Escenario

EJEMPLO ilustrativo: módulo de solicitudes con cuatro roles.

Definición

2–4 jornadas de esfuerzo para aclarar reglas y criterios.

Implementación

8–14 jornadas de esfuerzo bajo los supuestos del ejemplo.

Validación y entrega

3–6 jornadas de esfuerzo según regresiones y entorno.

Incertidumbre

La cantidad de excepciones, el acceso a ambientes y las integraciones pueden cambiar los rangos.

Cómo reducirla

Prototipo del flujo y revisión de tres solicitudes representativas.

Excluido

Integraciones reales, migración histórica y soporte continuado.

Límite

Estas cifras no son una cotización ni un plazo comercial de LoHacemos.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNRegistro de riesgosRelacionar cada riesgo con una señal y una mitigación.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Reglas ambiguas

Probabilidad media / impacto alto. Señal: la misma solicitud sigue rutas distintas. Mitigación: ejemplos de aceptación. Responsable del ejemplo: producto.

Doble aprobación

Probabilidad media / impacto alto. Señal: dos operadores actúan a la vez. Mitigación: transición atómica y auditoría. Responsable del ejemplo: backend.

Dependencia externa

Probabilidad alta / impacto medio. Señal: timeout. Mitigación: reintento limitado e idempotencia. Responsable del ejemplo: integración.

Acceso incorrecto

Probabilidad media / impacto alto. Señal: consulta fuera del espacio demo. Mitigación: pruebas de aislamiento. Responsable del ejemplo: seguridad.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNChecklist de desplieguePreparar el cambio y verificar su resultado.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Versión

Identificar commit, imagen y configuración exactos.

Pruebas

Validar reglas, integración, build y compatibilidad.

Datos

Revisar migraciones, copia previa y procedimiento de restauración cuando corresponda.

Secretos

Usar referencias del entorno; nunca incluir valores en este documento.

Despliegue

Aplicar el artefacto validado y esperar salud del servicio.

Verificación

Consultar rutas, permisos, persistencia y comportamiento visible.

Recuperación

Conservar imagen previa; evaluar compatibilidad de datos antes del rollback.

Observación

Revisar errores y recursos después del cambio.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNChecklist de handoffPermitir que otra persona continúe el trabajo.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Código

Repositorios, rama y versión acordados.

Documentación

README, arquitectura, decisiones y límites.

Ejecución

Requisitos, comandos, pruebas y configuración de ejemplo.

Operación

Ambientes, despliegue, migraciones, salud y recuperación.

Accesos

Inventario de permisos y responsables. Transferir secretos por un canal separado.

Pendientes

Problemas conocidos, backlog y decisiones abiertas.

Salida

Verificar accesos recibidos y revocar los que ya no correspondan.

Condición

Muestra de conversación de entrega; obligaciones finales según acuerdo.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNRoadmap por decisionesOrdenar fases sin inventar fechas de entrega.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Entender

Entrada: proceso actual. Salida: brief y preguntas.

Definir

Depende del brief. Salida: alcance y criterios de aceptación.

Probar el riesgo

Depende de reglas definidas. Salida: flujo mínimo y prueba de permisos.

Construir

Depende de la revisión. Salida: unidades revisables con pruebas.

Entregar

Depende de aceptación y entorno. Salida: versión, runbook y pendientes.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNPull request de muestraExplicar un cambio para alguien que no vio la conversación.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Problema

Dos aprobadores podrían resolver la misma solicitud.

Cambio propuesto

Transición atómica con control de versión; segundo intento devuelve conflicto.

Evidencia requerida

Prueba de dos transiciones concurrentes y auditoría con una sola aprobación.

Revisión

Confirmar alcance por espacio demo, rol y estado permitido. Revisor: por asignar en el ejemplo.

Riesgo de release

Revisar compatibilidad de la versión persistida y clientes que reintentan.

Estado

PLANTILLA DE MUESTRA; no representa una revisión humana completada.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNPipeline demostrativoConectar pruebas con una versión reproducible.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Frontend

Instalar desde lockfile; formato, lint, typecheck, tests y prerender.

Backend

Maven verify con PostgreSQL y pruebas de autorización.

Imagen

Construir y etiquetar con el commit validado.

Staging

Desplegar la misma imagen en un entorno de revisión.

Producción

Verificar autorización de release y salud; registrar digest y commit.

Límite

Secuencia de ejemplo. La evidencia de cada ejecución pertenece a su pipeline real.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNContrato API de muestraExplicar autenticación, errores e idempotencia.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Autenticación

La demo entrega un token temporal limitado a un espacio ficticio. No sirve para entrar al panel.

Creación

POST /api/v1/lab/workspaces inicia datos ficticios.

Consulta

GET /api/v1/lab/workspaces/{id} requiere el token del espacio.

Acción

POST /api/v1/lab/workspaces/{id}/actions valida rol y operación.

Errores

400 entrada inválida; 403 token o rol no permitido; 404 espacio inexistente; 409 transición incompatible.

Idempotencia

SyncFlow utiliza una clave de operación para no crear dos pedidos al repetir una solicitud.

Límite

Contrato de demostración; no incluye recursos de clientes.

Descargar ejemplo HTML

EJEMPLO / DEMOSTRACIÓNADR: monolito modularHacer visible una decisión y cuándo cambiarla.

EJEMPLO / DEMOSTRACIÓN — No corresponde a un cliente real.

Estado

Aceptado para el laboratorio; no es una política para todos los proyectos.

Contexto

Un flujo pequeño necesita actualizar estado y auditoría juntos.

Opciones

Monolito modular o servicios independientes con consistencia distribuida.

Decisión

Usar un módulo dentro de Spring Boot con persistencia transaccional.

Consecuencia

Menor costo operativo; los despliegues permanecen coordinados.

Cuándo revisar

Si aparecen equipos autónomos, escalamiento desigual o necesidades independientes de despliegue.

Evidencia

Pruebas de roles, transiciones y aislamiento de espacios temporales.

Descargar ejemplo HTML

The next step is simple

Let’s make
it work.

Tell us what you want to solve. We’ll find the next step together.

Let’s talk