Congelar el alcance aceptado en versiones.
- Por qué
- Un cambio posterior crea una versión nueva que el cliente debe aceptar; nada acordado se edita.
- Costo
- Más tablas y consultas por versión.
Hito
Caso de estudio · .NET 10 + React · 2026
Cada entrega aprobada, cada cobro claro.
Un freelancer acuerda hitos con su cliente, registra cada entrega y aprobación, y sabe en todo momento cuánto le deben. El cliente no crea cuenta: abre un enlace privado desde su celular.
Los acuerdos se pierden en el chat
El alcance de un proyecto freelance suele vivir en mensajes de WhatsApp: cambia sin registro, nadie sabe qué está aprobado y el cobro se discute al final.
Hito separa lo acordado de lo que pasa después: el alcance aceptado queda congelado, cada entrega se aprueba o se rechaza con un comentario y el panel dice qué se debe.
Mi aportación
Diseñé y construí todo el sistema: la API en capas con .NET 10, la interfaz en React, las pruebas y el despliegue automático a costo cero.
El recorrido completo
Es el mismo flujo que recorre la prueba end-to-end, con el freelancer y el cliente en navegadores separados.
Crear el proyecto
Hitos con título, monto en MXN, fecha y entregable; el total se calcula en el servidor.
Enviar el enlace
Privado, con vencimiento y revocable; en la base solo se guarda el hash del token.
El cliente acepta
Hitos y montos quedan congelados; un cambio posterior es una versión nueva.
Entregar
El freelancer agrega la URL de evidencia (solo http o https).
Aprobar o pedir cambios
Pedir cambios exige un comentario.
Registrar el pago
Solo sobre un hito aprobado y sin pagar de más.
Reglas de estado en el dominio
Las transiciones viven en el dominio y tienen pruebas unitarias; una transición inválida responde 409.
Proyecto
Borrador
Se arma el alcance.
Enviado
El cliente tiene el enlace.
Aceptado
El alcance queda congelado.
Completado
También puede pasar a Cancelado; los pagos registrados conservan su historial.
Hito
Pendiente
Aún sin entregar.
Entregado
Con evidencia; puede volver de Cambios solicitados.
Aprobado
Ya se puede cobrar.
Pagado
El pago no puede exceder el monto.
Arquitectura
React en Vercel llama por rewrite a una API ASP.NET Core en Render, con PostgreSQL en Supabase. La API está en capas: Domain, Application, Infrastructure y Api.
React + TanStack Query
Vercel Hobby; /api/* se reescribe hacia la API.
ASP.NET Core (.NET 10)
Render Free con el Dockerfile del repositorio.
EF Core + Npgsql
Migraciones versionadas; dinero en numeric(18,2).
PostgreSQL
Supabase Free por el session pooler.
Despliegue automático
build-test
Unitarias e integración con PostgreSQL real.
kind
Rollout en Kubernetes local con sondas live/ready.
Migraciones
Bundle de EF Core contra Supabase.
Deploy hook
Render publica la versión nueva.
Decisiones y lo que cuestan
Enlace privado para el cliente, guardando solo el hash del token.
- Por qué
- El cliente no necesita cuenta; el enlace expira y se puede revocar.
- Costo
- Quien tenga el enlace vigente puede aprobar; por eso vence y se revoca.
Pruebas
Cantidades tomadas del README en la revisión fijada.
- Unitarias (xUnit) · 53
- Transiciones de estado, cálculo de totales, reglas de pago, panel de cobros e historial mensual.
- Integración (Testcontainers) · 50
- API con PostgreSQL real, incluido el aislamiento entre usuarios y pagos simultáneos.
- E2E (Playwright) · 1
- El flujo crítico completo, con freelancer y cliente en navegadores separados.
- Kubernetes (kind) · 1
- Rollout con sondas live/ready, migraciones y llamada real a la API.
Límites declarados
- Es una demo de portafolio: Render Free se duerme y la interfaz avisa mientras despierta.
- Supabase Free no incluye respaldos automáticos.
- Kubernetes se prueba en kind dentro de CI; no es un despliegue en producción.
- No hay cobros con tarjeta, facturación ni correos: están fuera del alcance.
Fuentes
Archivos del repositorio público, fijados a la revisión que se revisó.