Esta es la objeción que impide comenzar a la mayoría de las personas, y se basa en una suposición falsa: que su descripción pasaría directamente a código sin posibilidad de retroceder. Ese no es el flujo. Su descripción genera primero un PLAN, la lista de datos, pantallas y su tipo, que se le muestra y que puede corregir ANTES de que exista una sola línea de código: renombrar una entidad, cambiar el nombre de un campo, añadir o eliminar un valor de estado e incluso cambiar el tipo de pantalla. En esta fase, equivocarse no cuesta nada. Tras la generación, seguirá pudiendo realizar modificaciones describiéndolas en español, pero eso reconstruirá toda la aplicación y volverá a someterla a validación automática: es una acción más compleja, no un simple ajuste.
El error que tememos no es el que realmente ocurre
Lo que se teme es entregar una descripción imprecisa y recibir una herramienta desajustada al objetivo, sin posibilidad de recurso. En los proyectos tradicionales ese temor está justificado: el cahier des charges se envía a un proveedor, la primera pantalla llega semanas después y la corrección del desfase se paga en días de desarrollo. Es ese retraso, no la dificultad de escribir, lo que hace angustioso el ejercicio.
La bibliografía sobre la formulación de requisitos dice, por otro lado, lo mismo desde otra perspectiva: lo difícil no es redactarlo, sino saber qué se quiere antes de haber visto algo. No se adivinan los propios hábitos de uso; se reconocen cuando se ven materializados.
El plan se muestra antes del código y se puede corregir
Entre su descripción y la aplicación hay una etapa intermedia: un plan. Enumera los datos que gestionará la herramienta, sus campos y las pantallas con el TIPO de cada una, una tabla, un calendario, un panel de control o un mapa. Este plan se visualiza y se edita.
En la práctica, en este momento puede renombrar una entidad y su nombre mostrado, corregir los campos que contiene, añadir o eliminar un valor de una lista de estados («En espera», «Aprobado», «Cancelado»), renombrar una pantalla, cambiar su icono e incluso cambiar su tipo: una lista que debería haber sido un calendario se corrige aquí, de una sola vez.
Es precisamente este paso lo que vuelve irrelevante la objeción. Una descripción aproximada no compromete nada: genera una propuesta que usted revisa, y corregir una palabra en el plan equivale exactamente a haberla escrito bien desde el principio.
Tras la generación: sigue siendo posible, pero ya no es el mismo gesto
Una vez generada la aplicación, cualquier cambio sigue solicitándose en español: «añade un campo para la fecha de recordatorio», «separa los presupuestos de las facturas». La diferencia está en otro lugar: esa solicitud regenera el plan, reconstruye la aplicación y la somete de nuevo a validación automática antes de devolverla a producción. Es fiable, pero no es instantáneo.
De ahí el único consejo práctico de esta página: releer el plan merece cinco minutos de atención real. Son los cinco minutos más económicos del proyecto.
Qué conviene saber antes de modificar una aplicación ya en producción
Hay dos aspectos que no se deducen por sí mismos y que conviene aclarar antes de aplicar una modificación a una herramienta que ya contiene sus datos reales.
El primero: qué ocurre con los datos ya introducidos cuando cambia la estructura (un campo eliminado, un tipo de dato dividido en dos). No lo afirmo aquí, es una pregunta que debe plantearse explícitamente antes de modificar una aplicación en producción, tanto aquí como con cualquier otro proveedor.
El segundo: no existe un botón «volver a la versión anterior». Restaurar una versión anterior requiere preparación, no se improvisa; de ahí la importancia de exportar sus datos antes de un cambio estructural, algo que la pantalla de Configuración permite hacer en formatos CSV y JSON.