La misión: tu idea, hasta el final
Elige una aplicación que tú o alguien real necesite de verdad —el control de clientes de tu trabajo, la agenda de reserva del consultorio familiar, el tablero de entrenamiento del club—. Nada de inventar una idea bonita para la tarea: el proyecto final se sostiene con usuarios auténticos. Las siete fases son las del curso completo, pero caminadas sin guion: definir, especificar, diseñar arquitectura, dirigir el código por capas, probar, proteger, desplegar. Y una octava que casi ningún curso enseña: sostener —mantenimiento, costos y métricas durante al menos dos semanas públicas—.
La ruta, siete tiempos
Ruta del proyecto final
1 · Definir y especificar (M2, día 1-2)
ESPECIFICACION.md completa: problema, usuario, casos de uso, pantallas, flujo, reglas de negocio y criterios de aceptación numerados. El recorte es parte del ejercicio: saca del alcance todo lo que no quepa en dos semanas —un «no por ahora» escrito vale más que un sí invisible.2 · Arquitectura antes que código (M3+M4, día 2)
Diagrama de componentes, modelo de datos, lista de APIs externas y funciones de IA con su hoja de costos. Divide en capas con fronteras probables (proyectos 1-5 te enseñaron el tamaño correcto de un bocado) y escribe el plan de construcción ordenado.3 · Documento maestro y construcción por capas (M18-M19)
El documento maestro al día, prompts de capa con criterios de aceptación numerados, un paso por vez con diff revisado. Si la IA propone saltarse una capa o «arreglar» dos a la vez, tú mandas: ese es el hábito, no la velocidad.4 · Auditoría con las siete señales (cnf)
Antes de probar funcionalidad: clave en el navegador, dependencia inventada, endpoint inexistente, sql directa con interpolación, permisos solo de menú, cero validación de entrada, borradura sin condición. Las siete pasadas con ctrl-f sobre el código real.5 · Pruebas que incomodan (M15)
PRUEBAS.md: casos felices, límites, estados feos de cada integración, y la prueba de datos —un borrado que solo toque lo suyo, en una base con copia de seguridad de verdad—. Si algo rompió el usuario de prueba, es un hallazgo de HALLAZGOS.md, no un fracaso.6 · Despliegue real (M16)
Dominio propio o subdominio, HTTPS, variables de entorno en el servidor, base migrada con respaldo probado (restaurar una vez, no solo respaldar), logs encendidos y una página de estado honesta si algo se cae.7 · Sostener y defender (M17, semana 3)
Dos semanas pública con tu rutina mensual activada: revisar logs, backups, dependencias, costos. Luego la defensa de quince minutos ante alguien técnico: tres decisiones que defendiste, dos que la IA te hubiera colado sin auditoría, una que cambiarías. Grábala: se cuenta en tu portafolio.
Paso 1 de 7
El prompt de arranque (el que ya sabes escribir)
El punto 3: la IA detecta el alcance inflado, pero el recorte lo firmas tú
Proyecto final. Adjunto ESPECIFICACION.md completa (la mia, escrita por mi) y el\ndocumento maestro del stack elegido. No empieces a programar: primero construimos\nel plan.\n\n1. devuelve el DESGLOSE por capas con fronteras probables, en orden de construccion,\n con que criterio de aceptacion numerado prueba cada capa\n2. marca cada capa que toque dinero, datos sensibles o una API externa: esas van con\n auditoria antes de integrarse\n3. senala los puntos del alcance que ves recortables si el tiempo aprieta, SIN\n recortarlos tu: la decision es mia y va escrita en ESPECIFICACION.md\n4. por cada capa esperame: te dare el si, y al terminar mostraras diff y la salida\n de sus pruebas corriendo\n\nReglas del proyecto (del maestro): nunca clave en frontend, nunca DELETE sin WHERE\nverificable, nunca dependencia sin comprobar que existe, validacion en cada entrada.\nEmpieza por el desglose. Nada mas.Qué entrega este proyecto
| Entregable | Barra alta del curso completo |
|---|---|
| ESPECIFICACION.md | problema real con usuario real, criterios numerados y los «no por ahora» escritos |
| ARQUITECTURA.md | el diagrama, el modelo de datos y la hoja de costos de cada función de IA |
| HALLAZGOS.md | lo que la IA intentó colarte en las siete señales: con fragmento de código y fecha |
| PRUEBAS.md | estados feos provocados, borrado auditado y la restauración del respaldo ejecutada una vez |
| App publicada | dos semanas en producción con rutina de mantenimiento cumplida (logs, backup, costo) |
| Defensa grabada | quince minutos explicando decisiones a un interlocutor técnico, sin leer |
Prueba
En la defensa de quince minutos, el evaluador pregunta: «¿por qué tu app tarda en responder a veces y qué hiciste en el diseño por eso?». La respuesta que demuestra el curso entero es:
Si tu aplicación nunca muestra un error en las dos semanas de producción, el proyecto demuestra calidad.
Antes del prompt de arranque, escribe en una línea para qué usuario real existe tu app y cómo sabrás en la semana dos que le sirvió. Ese renglón es tu criterio de éxito: todo lo demás —las capas, las señales, la defensa— es la forma de llegar a poder decirlo con evidencia.
El curso termina donde empieza cualquier software de verdad: alguien lo usa, algo se rompe, tú lo sostienes.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.