Tably Team
En el inicio de Tably Team hay dos puertas: Constructor directo y Constructor con equipo de desarrollo. Son dos filosofías distintas, y elegir mal cuesta tiempo o dinero. Esta guía las compara sin venderte ninguna.
Qué hace cada una
Constructor directo
- Escribís el pedido (y, si querés, adjuntás contexto o apps de referencia).
- El prompt engineering convierte tu texto en un brief completo: objetivo, usuarios, pantallas, datos, reglas, criterios de aceptación.
- El constructor (Claude Code, Codex o un modelo por API) arranca de inmediato, con diseño incluido.
- Al terminar, ves una card de ahorro estimado: cuántos tokens, minutos y dólares te ahorraste frente a la vía con equipo, con los supuestos explicados.
No hay debate, no hay consejo, no hay aprobación intermedia del diseño. El equipo queda a un clic para auditar el resultado después.
Constructor con equipo de desarrollo
- Mismo pedido, mismo contexto.
- El equipo investiga las referencias y se presenta.
- Debate del consejo: CEO, CTO, Head of Engineering, Product, Diseño y QA discuten en turnos y dejan decisiones justificadas.
- Del debate sale el brief; del brief, el diseño (sistema, pantallas, mockup), que vos aprobás.
- El constructor escribe el código por etapas.
- El consejo revisa cada versión; pedís cambios; el equipo itera.
Comparación
| Directo | Con equipo | |
|---|---|---|
| Tiempo hasta el primer código | Minutos | Decenas de minutos (debate + diseño + aprobación) |
| Costo en tokens del consejo | Cero | Depende de los modelos; cada ronda suma |
| Decisiones justificadas por escrito | No (solo el brief) | Sí, turno por turno |
| Aprobación del diseño antes del código | No | Sí |
| Riesgo de construir lo equivocado | Mayor si el pedido es ambiguo | Menor: el equipo acota y pregunta |
| Calidad del código | La misma: depende del constructor | La misma: depende del constructor |
| Mejor para | Ideas claras, apps chicas, prototipos, pruebas | Productos que crecen, clientes, arquitecturas que no querés rehacer |
Un punto importante: la calidad del código no cambia entre las dos vías. Lo que cambia es la calidad de las decisiones que llegan al constructor.
Cuándo elegir el directo
- Sabés exactamente qué querés y podés describirlo en diez líneas.
- La app es chica: una calculadora, un formulario, un panel simple, una landing.
- Estás probando una idea o comparando constructores.
- Ya tuviste un debate del equipo en un proyecto parecido y querés reutilizar lo aprendido.
- El presupuesto es cero: con Claude Code por suscripción, el directo no gasta tokens.
Cuándo elegir el equipo
- La idea tiene partes que no están definidas («un marketplace», «una app para mi clínica»).
- Vas a tener que explicar las decisiones a un cliente, un socio o un inversor.
- Hay decisiones de arquitectura con consecuencias (multiusuario, pagos, datos sensibles, móvil y web a la vez).
- Querés aprobar el diseño antes de que exista código.
- Querés que alguien te diga «esto no entra en la primera versión».
Una regla simple
Si podés escribir los criterios de aceptación vos mismo en cinco minutos, usá el directo. Si no, usá el equipo.
Pasar de uno a otro
No es una decisión irreversible.
- Desde una construcción directa podés convocar al equipo para auditar: el consejo revisa lo construido, produce una lista de cambios y el constructor la aplica.
- Desde un proyecto con equipo podés pedir cambios chicos directamente al constructor, sin reabrir el debate.
Qué pasa con el ahorro estimado
La card que aparece al terminar una construcción directa compara contra una vía con equipo equivalente: estima los tokens de K rondas de debate y revisión, el tiempo de esas rondas y el costo a precio de lista. Son estimaciones con supuestos visibles, no mediciones de una corrida que no ocurrió. Sirven para dimensionar, no para facturar.
En resumen
El directo es la vía para construir rápido lo que ya tenés claro. El equipo es la vía para decidir bien lo que todavía no. Las dos construyen con el mismo constructor; la diferencia está antes del código.