Vuestra primera nómina es un presupuesto: decidid en qué se gasta el dinero que os inversores de ayer
Ayer formasteis equipos, presentasteis y recibisteis inversión ficticia. Hoy esa inversión se convierte en algo muy concreto: cada equipo administra su caja, decide su arquitectura según el tipo de producto que ha elegido (no es lo mismo un juego que un SaaS de facturación que una app con control por voz) y termina la clase con el sprint 1 en marcha: tareas repartidas y la primera pieza funcionando con vuestro agente. Tres horas, todas por equipos.
La sesión de hoy
| 0:00 | Recap de ayer y norma de la caja | El dinero que recibisteis no es un premio: es un presupuesto con consecuencias |
| 0:10 | La caja del equipo | Repartir el dinero por categorías y justificarlo en docs/presupuesto.md |
| 0:40 | Taller por tipo de producto | Juego · SaaS de servicio · control por voz: qué decidir antes de tocar código |
| 1:25 | Descanso | 10 min |
| 1:35 | Sprint 1: del MVP a las tareas | 3 tareas verticales, branches, vuestro agente y vuestras reglas |
| 2:25 | Mini-demo entre equipos | 3 min por equipo: qué habéis montado hoy |
| 2:50 | Cierre y deberes | Qué hay que traer el lunes 26 |
1 · La caja del equipo (30 min)
Ayer cada persona repartió 100 € ficticios entre otros equipos. Sumad lo que habéis recibido: esa es vuestra caja para todo el curso. Un equipo muy votado tendrá más caja; un equipo con dudas, menos. Como en la vida real: el dinero no cambia la calidad de la idea, pero obliga a decidir en qué se gasta.
1Sumad y repartid12 min
Con los votos de ayer sobre la mesa, rellenad esta hoja de presupuesto. Las cifras exactas importan menos que la conversación: cuando dos personas quieren gastar lo mismo en cosas distintas, ese es el conflicto que un equipo fundador tiene que saber resolver.
# Presupuesto del equipo — [nombre del proyecto] **Fecha:** 20/10/2026 · **Inversión recibida ayer:** ___ € ficticios | Categoría | € asignados | Para qué exactamente | Quién lo decide | |---|---|---|---| | Tiempo de desarrollo (vuestras horas, a 30 €/h ficticios) | | | | | Herramientas e IA (APIs, licencias, lo que consuma el agente) | | | | | Infraestructura (dominio, servidor, base de datos) | | | | | Assets y contenido (música, gráficos, textos, fotos) | | | | | Validación (entrevistas, pruebas con usuarios, pequeños anuncios) | | | | | Colchón para imprevistos | | | | **Regla:** nada puede llevarse más del 40 % sin una justificación escrita de dos líneas. **La decisión más cara de hoy** y por qué: ________________
2La decisión más cara8 min
Marcad la decisión más cara que habéis tomado hoy y escribid dos líneas de por qué vale lo que cuesta. Se va a docs/presupuesto.md del repo (o a vuestro documento compartido, si el repo aún no está creado — para el lunes lo tenéis).
3La IA os audita las cuentas10 min
Pasad el presupuesto por el chat del centro antes de darlo por bueno. Os dirá lo que un CFO aburrido pero útil os diría:
Audita este presupuesto de una startup de estudiantes (producto: [una frase], cliente: [quién]). [pega la tabla] 1. ¿Qué categoría está infravalorada para este tipo de producto y cuál sobra? 2. ¿Qué gasto obligatorio se ha olvidado? (piensa en dominio, HTTPS, copias de seguridad, tiempo de pruebas) 3. Con esta caja, ¿qué Feature del MVP deberíamos recortar primero? Sé concreto.
2 · Taller: la arquitectura depende del tipo de producto (45 min)
«Usad la IA y ya está» no es una arquitectura. Lo que habéis elegido —un juego, un servicio de facturación tipo electricistas, una app que se maneja por voz— obliga a decidir cosas distintas y en orden distinto. Cada equipo va a la sección que le toque, rellena las 5 decisiones y las escribe en docs/decisiones.md con fecha. Las otras secciones también se leen, en voz alta si hace falta: el lunes habrá preguntas cruzadas.
🎮 Si hacéis un juego
- • Loop de diversión primero: escribid en una frase qué hace el jugador cada 20-30 segundos y por qué sonríe (o se pica). Si eso no se sostiene, no hay juego, haya los gráficos que haya.
- • Género con precedente: decidid «como [juego conocido] pero [vuestro giro]». Copiar el loop de un juego probado no es trampear: es no reinventar la rueda.
- • Scope de una sentada: 3-5 niveles o partidas de 2-5 minutos, sin multijugador (el multijugador es otro producto entero), sin cuentas al principio. Un juego corto y terminado vale más que una épica inacabada.
- • Tecnología: canvas o DOM con un game loop simple basta. Pedid a la IA el esqueleto update → draw → input y tocadlo vosotros; un motor completo (Godot, Unity) solo si alguien del equipo ya lo maneja.
- • Caja: aquí tiene sentido la categoría «assets»: música y arte con licencia libre (opengameart, Kenney, Pixabay) o generados — siempre comprobando la licencia.
- • Y el dinero, ¿cómo entra? Un juego gratuito de un instituto no monetiza casi nada (la publicidad no paga el servidor). Vale como producto si lo declaráis: cartera publicable, concurso, o una versión premium (capítulos extra) en una tienda tipo itch.io. Decidlo y anotadlo.
🧾 Si hacéis un SaaS de servicio (facturación para electricistas, reservas, gestión…)
- • El modelo de datos es el producto: antes de pantallas, escribid las entidades y cómo se relacionan (cliente → presupuesto → factura → líneas → estado). En un gestor, el 70 % del trabajo de campo es ese modelo; la IA lo dibuja en un minuto pero lo tenéis que validar vosotros con un caso real.
- • Datos de prueba ANÓNIMOS: nunca nombres, teléfonos ni NIF reales de clientes de nadie en un repositorio de clase. Fingid clientes con nombres inventados.
- • El PDF es la entrega, no un detalle: lo que el profesional «saca» por la puerta es un presupuesto/factura en PDF bien impreso. Presupuesto y factura son el mismo documento con un campo más: haced primero ese PDF y que salga bien.
- • Lo que NO tocáis en el MVP: contabilidad, IVA complicado, rectificaciones legales completas, multiusuario fino. Una secuencia simple con número de factura correlativo y un PDF correcto es honesto y suficiente para que un electricista lo use una tarde.
- • Datos de verdad: hablad con UN electricista de verdad esta semana (el padre de alguien, el del pueblo) y preguntadle cómo factura hoy: qué papeles, qué app odia, cuánto tarda. La respuesta define vuestro MVP más que cualquier prompt.
- • Caja: la parte gorda va a «tiempo de desarrollo» y «infraestructura» (base de datos de verdad). Aquí el dinero de ayer se nota: un SaaS sin base de datos persistente no es un SaaS.
🎙 Si vuestro producto se maneja por voz («dame ordenes y que se genere solo»)
- • La voz no es la magia; la intención sí. «Haz una factura a Pepe de dos horas a 30 euros» tiene que convertirse en un formulario rellenado y mostrado para confirmar. Voz → texto → estructura → confirmación humana → acción. Nunca ejecución directa sin pantalla de confirmación: un «sí» mal oído no puede facturar 500 €.
- • Primero el formulario, después la voz: si el producto no funciona tecleando, la voz solo tapará el agujero. El MVP de verdad es la ruta sin manos: un campo de voz, transcripción y relleno automático.
- • Quién transcribe y a qué coste: la API de voz del propio navegador (Web Speech API) es gratis y vale para empezar en Chrome; Whisper de OpenAI (o similar) es mejor y cuesta céntimos por minuto — ese gasto va a la categoría «herramientas e IA» del presupuesto, con números. Medidlo: cuantos minutos/mes creéis que usará vuestro electricista y cuánto costará.
- • Ruido, acentos y valenciano: probadlo en el aula, no en casa en silencio. Enunciad 10 frases de dominio real con ruido de fondo y anotad cuántas se entienden. Esto es testing de verdad y sale en docs/entrevistas.
- • Privacidad: la voz de un cliente es dato personal. En clase, voces de prueba; en producción, aviso claro y mínima retención.
Somos un equipo de 1º DAM. Producto: [qué es] para [quién]. Presupuesto: [pega la tabla resumida]. Nuestra sección del taller de hoy: [juego / SaaS de servicio / voz]. 1. Con nuestras 5 decisiones escritas [pega docs/decisiones.md], ¿qué decisión nos va a explotar en la cara y por qué? 2. Proponed la arquitectura más aburrida que funcione (stack concreto y por qué), sin microservicios ni inventos. 3. Dividid nuestro MVP en exactamente 3 tareas verticales que quepan en un sprint de una semana para 5 personas dirigiendo agentes. Cada tarea: nombre, «dado X cuando Y entonces Z», quién la coge y qué criterio de aceptación. 4. Qué NO debemos construir todavía aunque nos tiemble el pulso.
3 · Sprint 1: que el proyecto exista de verdad (50 min)
Con las tareas ya definidas (o con las que os acabe de proponer la IA), cada equipo arranca el sprint 1hoy, aquí. El objetivo no es acabar nada: es que el repo exista, que haya commits de varias personas y que el primer Vertical Slice de uno de vosotros funcione en local. Reglas del sprint:
1Repo y organización10 min
Si aún no lo tenéis: organización de GitHub del equipo, repo con todos como miembros y el profe (aulaenlanube) como colaborador. README = la ficha de ayer. Primer commit: vosotros.
2Tareas asignadas con dueño8 min
Las 3 tareas del bloque anterior, cada una con dueño y revisor (el revisor es otra persona del equipo: nadie se aprueba su propio trabajo). Se anotan en el kanban del repo (GitHub Issues) con la etiqueta sprint-1.
3Cada uno, con su agente27 min
Vuestra tarea en dos partes: primero dirigís al agente (le pasáis criterio de aceptación, él propone, vosotros discutís y corregís); después lo comprobáis sin él: probáis la función a mano y escribís una línea de qué ha fallado. Cada uno hace su branch y su PR; se revisan en parejas antes de fusionar. Commits pequeños con mensaje que se entienda: mañana esto lo lee otro.
4 · Mini-demo y cierre (35 min)
Tres minutos por equipo, sin diapositivas: 1 cómo habéis repartido la caja y la decisión más cara,2 qué arquitectura habéis elegido y por qué (según vuestro tipo de producto), 3 qué funciona ya en local, aunque sea feo. El resto de la clase hace una sola pregunta por equipo: la que más dudas le haya generado.
Para el lunes 26 de octubre
- 1 · Repo completo: ficha v1 como
README.md,docs/presupuesto.mdydocs/decisiones.mdcon lo de hoy, y el kanban con el sprint-1 asignado. - 2 · Sprint 1 terminado en local: al menos una de las 3 tareas fusionada en main y funcionando.
- 3 · Las 5 entrevistas de la semana pasada (si aún no las tenéis): esta semana ya no vale «no hemos tenido tiempo» — la caja se justifica con evidencia, no con opiniones.