Por Thomas Cohen, fundador de Maestro
Crear una aplicación sin programar: guía para tu primer proyecto
De la necesidad al primer uso real: elige un método, describe el proyecto, prevé los costes y comprueba el resultado. Un ejemplo completo para avanzar sin vocabulario técnico.
Quieres crear una aplicación sin saber programar. Puedes montar pantallas, encargar la construcción a una IA o buscar ayuda profesional. Todavía hay que precisar la necesidad y comprobar el resultado: una vista previa atractiva no basta para confiar tus citas a una herramienta nueva.
Esta guía sigue un ejemplo ficticio: una pequeña empresa de mantenimiento quiere organizar sus visitas. Nora prepara la agenda; Samir trabaja en las instalaciones de los clientes. Las solicitudes llegan por teléfono y acaban repartidas entre una hoja de cálculo y varios mensajes. Seguiremos las decisiones necesarias hasta el primer uso real. Las personas, la empresa y las situaciones son inventadas para explicar el método.
Puedes mantener abierta la plantilla gratuita de requisitos de una aplicación mientras lees. Se copia en Word o Google Docs sin registrarse. Al terminar, tendrás una forma de preparar tu primer proyecto, comparar maneras de construirlo y pedir ayuda concreta cuando haga falta.
1. Describe el problema antes de dibujar la aplicación
Al principio, Nora pide «una aplicación para gestionarlo todo». Esa frase no permite elegir un programa ni comprobar una entrega. El problema se vuelve concreto cuando cuenta un día de trabajo: cambia una visita en la hoja de cálculo, pero Samir sale con la dirección y la hora del mensaje recibido el día anterior.
La primera pregunta es, por tanto: ¿qué información debe ser fiable, para quién y en qué momento? Aquí, Samir necesita encontrar la última hora confirmada antes de salir. Nora necesita saber que el cambio se ha guardado. El primer objetivo se centra en la agenda; la facturación y el inventario pueden esperar.
Anota la acción, el obstáculo y su consecuencia en tu actividad. Para anunciar un ahorro de tiempo, mide primero el tiempo dedicado actualmente. Si no, elige un resultado observable: encontrar una visita sin preguntar qué archivo está actualizado.
2. Elige entre software existente, no-code, IA y un profesional
Adoptar un programa que ya existe
Empieza probando una herramienta de tu sector con el recorrido elegido. Nora le pide que cambie una visita de hora y muestre el cambio a Samir. También comprueba cómo exportar la información y retirar un acceso. Si funciona en las condiciones reales del equipo, quizá no necesitéis una aplicación a medida.
Montar una aplicación en un editor visual
El no-code consiste en construir con elementos visuales y reglas que configuras. Colocas una lista, un formulario y unos botones; después defines qué ocurre tras cada acción. Esta vía puede encajarte si te gusta ajustar las pantallas por tu cuenta y aceptas aprender cómo funciona el editor.
Antes de comprometerte, examina los límites respecto a tus necesidades concretas: quién puede ver cada visita, qué ocurre sin conexión y qué te llevas si abandonas el servicio. Poder exportar los datos no significa necesariamente que toda la aplicación pueda funcionar en otro lugar.
Encargar la construcción a una IA
Describes un resultado, la herramienta propone una solución y después la revisas y corriges. Algunas trabajan en el navegador; otras, sobre los archivos de tu ordenador. Una conversación puede producir rápidamente una pantalla convincente, pero aún hay que comprobar el guardado, los permisos y los errores. Nuestra comparativa de herramientas para crear con IA ayuda a examinar estas diferencias.
Confiar parte o todo el trabajo a un profesional
Un profesional puede definir el proyecto, construirlo o revisar una versión preparada con IA. Pide que concrete la entrega, las pruebas previstas y el mantenimiento. Puedes combinar las vías: preparar la necesidad por tu cuenta, probar una pequeña versión con IA y solicitar una revisión técnica antes de utilizarla con clientes.
3. Escribe una primera descripción que alguien pueda utilizar
Una descripción inicial explica el proyecto sin vocabulario informático. Nora podría enviar el siguiente texto a una IA, a un proveedor de software o a un desarrollador. Cada frase aporta una decisión o una pregunta por resolver.
«Organizamos visitas de mantenimiento a nuestros clientes. Actualmente, las solicitudes llegan por teléfono. Las introduzco en una hoja de cálculo y envío la agenda a los técnicos. Cuando cambia una hora, no siempre sabemos si se ha leído la información correcta. Quiero un lugar común para preparar y consultar la agenda confirmada.»
«Creo una visita con un cliente ficticio para las pruebas, una dirección, una fecha, una franja horaria y una persona asignada. Samir consulta las visitas que tiene asignadas y marca las terminadas. Yo puedo modificar la agenda y corregir una asignación. Los clientes no tienen cuenta en la primera versión.»
«Una visita cancelada sigue pudiendo consultarse con su estado. Si intento asignar visitas que se solapan a la misma persona, la aplicación debe avisarme e impedir que se guarden. Si Samir pierde la conexión, debe entender que la actualización no está confirmada. Decidiremos por separado si necesitamos funcionamiento sin conexión.»
«La primera versión no gestiona presupuestos, pagos ni inventario. La validaremos con datos ficticios creando, cambiando y cancelando una visita. También comprobaremos que un técnico no puede abrir la agenda privada de un compañero. Antes del primer uso real, habrá que decidir dónde funciona la aplicación, quién la mantiene y cómo restaurar una copia de seguridad.»
Todavía hay que precisar la duración de las visitas y los cambios de última hora. Conserva una lista de decisiones pendientes con una persona responsable de cada respuesta. La guía de requisitos permite desarrollar después esta descripción. Para comprobar la necesidad antes de detallar la solución, sigue el ejemplo de definición con Margaux.
4. Limita la primera versión a un recorrido completo
La primera versión debe prestar un servicio de principio a fin. Una página de acceso, un menú y tres pantallas vacías todavía no permiten trabajar. Para Nora y Samir, el recorrido útil empieza al crear una visita, continúa con su consulta y termina al confirmar que se ha realizado.
Dibuja tres columnas en una hoja: imprescindible ahora, útil después y excluido. En la primera, coloca la creación, asignación, cambio de horario, cancelación y consulta. Los adjuntos, las rutas y las estadísticas pueden ir en la segunda. La contabilidad queda excluida hasta que una necesidad distinta justifique añadirla.
Decide también en qué dispositivos se probará el primer recorrido. Samir lee su agenda en el teléfono y Nora trabaja en un ordenador: una pantalla cómoda para ella puede resultar difícil para él. Precisa qué información se debe leer en la calle, qué botones hay que tocar y qué mensajes deben entenderse rápidamente.
Cada petición añadida durante el proyecto debe responder a una pregunta: ¿su ausencia impide este primer uso? Si no, apúntala para más adelante. Si lo impide, describe qué sustituye o qué añade al plazo y al presupuesto. Así mantienes un alcance que puedes terminar y comprobar.
5. Define los datos y quién tiene derecho a utilizarlos
Un formulario no decide por sí solo qué información hace falta. Para una visita, empieza por un identificador, el lugar, la hora, la persona asignada y el estado. Describe cada campo con palabras corrientes. La fecha de la visita, la de creación y la de última modificación no significan lo mismo.
Después, escribe los permisos. «Samir tiene acceso a la aplicación» es demasiado impreciso. Indica qué puede leer, modificar y exportar, y sobre qué visitas. Para las primeras pruebas, el reparto podría ser este:
- Nora consulta y organiza todas las visitas del equipo.
- Samir consulta solo las visitas que tiene asignadas y marca su finalización.
- Una cuenta retirada ya no puede consultar la información.
- Ningún visitante sin cuenta puede abrir la agenda.
Prueba estas reglas con varias cuentas. OWASP recomienda comprobar los permisos en cada solicitud. En nuestro ejemplo, Samir no debe poder abrir directamente una visita asignada a un compañero. Pide a quien construye la aplicación que compruebe este caso y conserva el resultado. Una revisión técnica externa puede complementar tus pruebas.
Utiliza nombres, direcciones y notas inventados al principio. No copies tu archivo de clientes para que la demostración parezca más realista. Antes de usar datos reales, identifica los servicios que los recibirán, las personas con acceso y la forma de retirarlos. La guía de riesgos del desarrollo con IA profundiza en estas precauciones.
6. Pide un plan comprensible y valida resultados concretos
Pide un plan descrito por resultados: preparar los datos de prueba, crear una visita, mostrar la agenda, comprobar los permisos y verificar los cambios. Precisa qué revisarás: un documento, una pantalla o una prueba superada. Así podrás decidir sin comprender cada tarea técnica.
Un equipo de agentes de IA puede repartir estas actividades entre análisis, diseño, construcción y verificación. Eso no convierte sus conclusiones en una garantía. Si un agente anuncia «las pruebas pasan», pregunta qué comportamientos se han probado y qué partes siguen pendientes de revisión por una persona.
Maestro organiza este trabajo mediante documentos y validaciones. Margaux ayuda a definir el proyecto, Amélie construye y Félix interviene en la calidad. Descubre el recorrido en la visita de Maestro. La beta para Mac es por invitación; la aplicación es gratuita durante este periodo y el uso de IA se presupuesta aparte. La guía de la beta explica el acceso y cómo preparar tu primera prueba.
Para validar una etapa, cambia «parece que está bien» por una frase verificable: «He cambiado la visita y Samir encuentra la nueva hora después de volver a abrir su agenda». Conserva también las reservas. Una validación puede referirse solo a ese recorrido; no significa que toda la aplicación esté lista.
7. Elige asistente y modelo sin volver a empezar
El asistente es la herramienta a la que encargas el trabajo. El modelo es el motor de IA que utiliza para comprender y producir una respuesta. Según el asistente, puedes elegir ese motor o dejar que lo elija. Las opciones disponibles y su facturación dependen de tu acceso al servicio.
Para empezar, elige un asistente que puedas comprender e interrumpir. Dale una tarea pequeña cuyo resultado esperado conozcas. Observa la calidad de las explicaciones, cómo trata un error y qué te pide validar. El nombre del modelo no basta para elegir una forma de trabajar.
Si cambias de asistente o modelo, prepara un estado claro del proyecto: última versión que funciona, reglas validadas, trabajo en curso, pruebas realizadas y preguntas abiertas. Pide al nuevo asistente que reformule la siguiente tarea antes de modificar nada. Comprueba esa explicación como lo harías con un nuevo profesional.
No cambies el alcance, la herramienta y el modelo a la vez durante una prueba: ya no sabrías qué explica el resultado. Conserva los mismos datos ficticios y criterios para comparar. Una mejora solo interesa si puedes observarla en tu propia necesidad. La guía para elegir asistente y modelo propone un ejercicio para comparar dos opciones.
8. Prevé el presupuesto de construcción y el coste de uso
El precio de la herramienta de creación no cubre necesariamente todo el proyecto. Separa los gastos para construir de los que continuarán cuando se utilice la aplicación. Incluye tu tiempo y el de los compañeros que explicarán su trabajo, responderán preguntas y harán las pruebas.
- Construcción: herramienta, uso de IA, acompañamiento, revisión técnica y migración de datos.
- Funcionamiento: posible alojamiento, dominio, copias de seguridad y servicios externos.
- Seguimiento: corrección de problemas, actualizaciones y nuevas peticiones.
- Tiempo del equipo: preparación, validación, formación y gestión de incidencias.
Para cada línea, anota quién factura, qué genera el coste y dónde consultar el consumo. Una suscripción, una factura por uso y un presupuesto profesional no se comparan solo por el importe anunciado. La guía del presupuesto de una aplicación ayuda a preparar esa comparación. La guía de suscripciones, créditos y tokens explica cómo interpretar el consumo de IA.
Acuerda un límite para el primer recorrido y un punto de parada. Por ejemplo: si la agenda sigue sin respetar los permisos tras las pruebas previstas, se suspenden los añadidos y se solicita una revisión concreta. Si un gasto supera la cantidad acordada, no empieza ninguna función nueva sin una decisión explícita.
9. Prueba las situaciones habituales y las incómodas
Prepara tus pruebas antes de la demostración. Así sabrás qué observar en lugar de seguir solo el camino elegido por la herramienta. Para cada situación, escribe un punto de partida, una acción y un resultado esperado. Guarda el nombre de quien la probó, la fecha y la versión.
El primer escenario es sencillo: Nora crea una visita ficticia para Samir. Él la encuentra, la marca como terminada y Nora ve el nuevo estado. Cierra y vuelve a abrir la aplicación para comprobar que la información permanece. Después, prueba otra cuenta: la agenda de Samir no debe convertirse en la de todo el equipo.
- Falta un campo obligatorio: la aplicación explica qué completar.
- Dos visitas se solapan: se respeta la regla de la descripción inicial.
- Nora modifica la misma cita desde dos ventanas: ningún cambio desaparece sin avisar.
- La conexión se interrumpe durante una acción: el mensaje no afirma que todo se ha guardado.
- Se cancela una visita: sigue siendo consultable con el estado correcto.
Prueba también el uso habitual en el teléfono, con el teclado y con texto ampliado. Un botón difícil de alcanzar o un mensaje incomprensible puede bloquear tanto como un error de cálculo. Estas pruebas propuestas todavía no demuestran la calidad del producto: hay que ejecutarlas y anotar qué ha funcionado realmente.
10. Distingue el proyecto en tu ordenador de la aplicación que se utiliza
Los archivos del proyecto pueden estar en tu ordenador mientras la aplicación final funciona en un servicio en línea. También se puede diseñar una aplicación para usarla en una sola máquina. El lugar donde construyes no determina automáticamente cómo accederán los usuarios al resultado.
En nuestro ejemplo, Nora y Samir necesitan información compartida desde dos dispositivos. Por tanto, hay que decidir cómo se comparte, dónde se conserva y qué ocurre si el servicio deja de responder. Una aplicación «local» no resuelve por sí sola la colaboración o la sincronización.
Lo mismo ocurre con la IA: conservar el proyecto en tu Mac no significa que el modelo funcione sin conexión. Un asistente conectado puede enviar contexto a su proveedor. Para Maestro, consulta las explicaciones sobre los datos y las condiciones del asistente elegido antes de darle información confidencial.
Antes de ofrecer la aplicación, deja por escrito quién posee las cuentas de alojamiento, el posible dominio y los accesos a los servicios. Pide el procedimiento para recuperar el código, los datos y los documentos. Retomar el proyecto en otro lugar exige un material comprensible, no solo una carpeta de archivos cuyo contenido nadie conoce. Nuestra comparación entre construcción local y cloud te ayuda a examinar esos cuatro lugares por separado.
11. Pasa de la prueba al primer uso real
Elige un piloto limitado: una parte de las visitas, usuarios identificados y un periodo acordado. Anota quién puede autorizar el inicio y quién puede detenerlo. El primer uso real necesita una persona responsable y localizable; «la IA se encargará» no indica a quién llamar si falta la agenda. La guía para crear una aplicación para un equipo pequeño detalla las responsabilidades y las pruebas con varias personas.
Antes de empezar, comprueba los accesos, la posible migración de datos y una copia de seguridad que se haya intentado restaurar de verdad. Pide que te expliquen qué ocurre durante una interrupción y cómo comunicar un problema. Enseña a Samir a encontrar su agenda y confirmar que un cambio se ha guardado.
Decide qué herramienta es la referencia durante la transición. Si la hoja de cálculo y la aplicación siguen siendo editables sin una regla, Nora tendrá que adivinar qué hora es válida. Escribe dónde deben hacerse los cambios y cómo trasladarlos si se detiene el piloto. La guía de renovación de software de gestión detalla esta preparación cuando ya existe una herramienta.
Al terminar el piloto, reúne los problemas observados y las peticiones nuevas. Un fallo de acceso o información perdida pueden impedir continuar. Una preferencia de color puede esperar. Decide si seguir, corregir o volver a la organización anterior a partir de hechos registrados, no solo del entusiasmo de la primera demostración.
12. Prepara el mantenimiento y una entrega comprensible
Una aplicación en uso sigue necesitando decisiones. Alguien debe vigilar los errores, renovar los servicios, retirar accesos y organizar las actualizaciones. Puedes ser tú o un profesional, pero el papel debe quedar claro. Acuerda también qué ocurrirá si esa persona deja de estar disponible.
Prepara un expediente de entrega con las reglas validadas, el código, las instrucciones de arranque, las cuentas que hay que conocer sin sus contraseñas y las limitaciones pendientes. Añade los escenarios de prueba: sirven para comprobar que una modificación no rompe lo que funcionaba antes.
Para una función nueva, repite el mismo ciclo con un alcance pequeño: problema, regla, construcción, prueba y decisión. Si Nora pide después recordatorios automáticos, habrá que precisar quién los recibe, cuándo y cómo detectar un fallo de envío. Esa petición merece su propio recorrido; no se reduce a añadir un botón.
Empieza por las seis preguntas de la plantilla de requisitos y pide a un futuro usuario que revise las respuestas. Podrás probar un programa existente, construir o buscar ayuda con una necesidad comprensible y criterios para juzgar el resultado.