Crear una aplicación: elegir entre una herramienta local y la nube

Distingue cuatro lugares: construcción, archivos, procesamiento de IA y aplicación final. Compara accesos, costes y recuperación mediante una prueba concreta.

Quieres crear una aplicación: ¿conviene construirla en tu ordenador o desde el navegador? ¿Adónde van las peticiones a la IA? ¿Quién conserva los archivos? ¿Cómo accederán los usuarios al resultado? La elección entre una herramienta local y una en la nube empieza por estas respuestas, que pueden ser distintas dentro del mismo producto.

Esta guía sigue a una pequeña galería ficticia. Inès prepara las exposiciones, Paul recibe a los visitantes y Salomé trabaja a distancia. Quieren controlar las obras prestadas, su ubicación y su devolución. Los personajes y las situaciones son inventados para comparar decisiones concretas; no representan a un cliente de Maestro ni un proyecto real.

1. Distingue los cuatro lugares del proyecto

«Local» suele indicar que una parte del trabajo ocurre en tu dispositivo. «Nube» se refiere a recursos accesibles a distancia que funcionan en otros ordenadores. Estas palabras no describen todo el recorrido del proyecto. Una aplicación instalada puede contactar con un servicio remoto; una herramienta del navegador puede permitirte descargar tus archivos.

• La construcción: la interfaz donde describes, modificas y pruebas el proyecto.
• Los archivos: el código, las imágenes, los documentos y el historial necesarios para seguir construyéndolo.
• El procesamiento de IA: el lugar donde se analizan tus peticiones y los elementos enviados.
• La aplicación final: lo que abren tus usuarios, junto con los datos que introducen.

Inès podría construir en su Mac, conservar los archivos en una carpeta con copia de seguridad, utilizar una IA remota y publicar una aplicación accesible a los tres compañeros. Estos cuatro lugares no tienen por qué coincidir. Por eso, una promesa como «todo en local» necesita una explicación de los intercambios reales.

Dibuja cuatro casillas en una hoja. Anota en cada una el lugar, la cuenta utilizada y la persona responsable. Una casilla vacía se convierte en una pregunta que resolver antes de introducir datos reales. El dibujo también te ayudará a entender qué deja de funcionar cuando un dispositivo, una cuenta o una conexión no están disponibles.

2. Elige dónde quieres construir

La herramienta de construcción es tu taller. En ella haces peticiones, revisas propuestas y examinas cambios. Empieza por tu manera de trabajar: ¿siempre en el mismo ordenador, desde varios lugares o con alguien que interviene puntualmente? La experiencia diaria importa tanto como la lista de funciones anunciadas.

Para Inès, una herramienta instalada en su Mac puede encajar si dirige la construcción y quiere encontrar fácilmente su carpeta de trabajo. Aun así, debe comprobar la compatibilidad del equipo, los programas necesarios y cómo otra persona podría retomar el proyecto. Instalar algo no tiene por qué ser un problema; una instalación sin explicar sí puede serlo.

Una herramienta en la nube puede permitirle abrir su entorno desde distintos dispositivos compatibles. Conviene comprobar qué seguirá disponible si suspenden su cuenta, cambia el servicio o decide trabajar de otra forma. El navegador puede facilitar el comienzo, pero no elimina las decisiones sobre recuperación y traspaso del proyecto.

Durante la prueba, pide el mismo cambio a ambas soluciones: añadir un estado «devolución por confirmar» para una obra. Observa dónde queda guardada la decisión, cómo revisas el resultado y qué debes hacer para corregir un error. Compara un recorrido completo, no solo la rapidez con la que aparece la primera pantalla.

3. Encuentra los archivos necesarios para continuar

Una imagen del resultado no es el proyecto. Para retomar la construcción pueden hacer falta el código, las imágenes, documentos de preparación e instrucciones de arranque. Los datos introducidos en la aplicación forman otro conjunto distinto. Pide que te enseñen estos elementos por separado, con nombres que puedas entender.

Inès crea un proyecto de prueba llamado «Galería de prueba». Debe poder encontrar los archivos sin adivinar qué carpeta contiene la última versión. Si la herramienta permite exportar, realiza la exportación. Si el proyecto ya está en su ordenador, comprueba que contiene lo anunciado y pregunta cómo ponerlo en marcha en otro equipo.

Tener los archivos no equivale a retomar el trabajo con facilidad. Otra persona puede necesitar instalar componentes, configurar servicios o sustituir accesos. Pide una estimación de ese trabajo. La guía sobre la propiedad del código de una aplicación con IA detalla las preguntas sobre recuperación y dependencias.

Para comparar, conserva una relación sencilla: archivos recuperados, elementos ausentes, instrucciones disponibles y ayuda necesaria. Una demostración de traspaso aporta más que un botón «exportar» cuyo resultado nadie ha abierto. El objetivo es saber qué podrás entregar realmente cuando cambie la persona encargada de construir.

4. Entiende qué recibe el proveedor de IA

El lugar de la interfaz no indica dónde trabaja la IA. Una petición escrita en tu ordenador puede enviarse a un proveedor remoto junto con archivos o fragmentos útiles para responder. Lo que se transmite depende del asistente, de los ajustes y de las acciones permitidas. Pide una explicación que corresponda a tu configuración.

La galería prepara una lista de obras completamente ficticia para su primera prueba. Incluye títulos, fechas y estados representativos, sin contratos ni datos de contacto de prestadores reales. Eso basta para probar el recorrido. Copiar todo el expediente administrativo no ayudaría a este primer objetivo y dificultaría examinar los intercambios.

Haz preguntas concretas: ¿qué puede enviarse, a qué proveedor, con qué cuenta y bajo qué condiciones? Si falta una respuesta, limita la prueba a los datos preparados para ella. Una suscripción profesional y una cuenta personal pueden tener condiciones diferentes; no las consideres equivalentes sin comprobarlo.

5. Decide dónde se utilizará la aplicación final

Cuando termine la construcción, Paul necesita consultar los préstamos en recepción y Salomé preparar una exposición desde casa. No tienen por qué necesitar la herramienta con la que Inès creó las pantallas. Necesitan una aplicación utilizable, accesos adecuados e información coherente entre sus dispositivos.

Estudia tres situaciones: una aplicación utilizada en un solo ordenador, una aplicación accesible en la red de la organización o un servicio disponible a distancia para personas autorizadas. Cada opción exige una preparación diferente. Elige según los lugares y situaciones de uso y después confirma la solución técnica correspondiente.

En este caso ficticio, limitar la herramienta final al Mac de Inès dificultaría el trabajo de Paul cuando ella no está. Una aplicación accesible a distancia podría responder al problema si se prepara su funcionamiento y sus accesos. Puede construirse igualmente en el Mac. Eso no implica automáticamente que ese ordenador deba permanecer encendido.

La CNIL recuerda que la seguridad en la nube también implica al cliente. Pide que se definan por escrito las tareas del proveedor y las de tu organización.

El resultado esperado es concreto: Paul abre la herramienta desde su puesto habitual, Salomé desde el suyo y ambos encuentran el mismo préstamo de prueba. Superar esta comprobación no valida toda la seguridad, pero confirma que estás comparando el modo de uso adecuado.

6. Prueba las interrupciones de conexión

«Funciona sin conexión» puede significar consultar una página ya abierta, crear nuevas fichas o realizar todo el trabajo. Pregunta qué acciones siguen disponibles y cómo sabe el usuario que un cambio se ha guardado. Una promesa general no permite prever qué ocurrirá cuando la red sea inestable.

Prepara una prueba con datos ficticios. Abre una ficha, corta la conexión, intenta una acción prevista y vuelve a conectarte. Anota el mensaje mostrado y comprueba el resultado desde otro dispositivo. No hagas esta prueba en plena actividad real con un expediente que otros compañeros estén modificando.

Para la galería, el requisito mínimo podría ser consultar la lista de obras presentes durante una avería breve. Registrar una devolución sin conexión y conciliarla después con los cambios de otras personas es una petición adicional. Debe describirse, construirse y probarse por separado, con una regla para los desacuerdos.

Distingue también una interrupción de la IA de una caída de la aplicación final. Puede que no puedas pedir cambios a los agentes mientras la aplicación publicada sigue funcionando. A la inversa, un servicio esencial para la aplicación puede fallar aunque la herramienta de construcción continúe disponible.

7. Prepara el uso compartido y los cambios simultáneos

Dos personas pueden participar de varias formas: hablar de las necesidades, revisar una pantalla, modificar el código o utilizar la aplicación final. Estas cuatro actividades requieren funciones distintas. Antes de buscar un plan «para equipos», concreta cuál te interesa y describe una situación real.

Inès puede reunir las peticiones de Paul y Salomé y después trasladarlas a la herramienta de construcción. Esto no exige que los tres den instrucciones simultáneas a los agentes. Para revisar un recorrido puede bastar una sesión conjunta o un entorno de demostración, si sus condiciones de acceso son adecuadas.

La aplicación final plantea otra pregunta: ¿qué ocurre si Paul marca una obra como devuelta mientras Salomé cambia su ubicación? El lugar de construcción no resuelve ese conflicto. Hacen falta una regla de funcionamiento y pruebas con varias cuentas. Una interfaz compartida no garantiza que todos los cambios se conserven correctamente.

Escribe quién puede construir, quién valida y quién utiliza la aplicación. Si tu prioridad es organizar el trabajo colectivo, la guía para dirigir un proyecto de aplicación ayuda a repartir las decisiones. Valora después el precio y la sencillez según los accesos que realmente necesita tu equipo.

8. Cuenta con la instalación y el mantenimiento

Para una solución local, pide los detalles del primer arranque: ordenador compatible, espacio disponible, cuentas necesarias, permisos solicitados y persona que puede ayudar. Pregunta después cómo se actualiza. Una solución agradable el primer día puede complicarse si cada cambio exige una intervención improvisada.

Para una solución en la nube, examina también el trabajo pendiente: preparación de cuentas, configuración de accesos, posible dominio, servicios conectados y seguimiento de gastos. Una interfaz lista para abrir no significa que la aplicación final esté lista para el equipo. Pregunta qué incluye y qué habrá que añadir.

La galería prepara una pequeña guía de funcionamiento. Explica dónde abrir la aplicación, a quién avisar en caso de avería y cómo comprobar que el servicio se ha recuperado. Inès no debe ser la única que sepa encontrarla. Una ausencia programada permite probar el relevo sin esperar a una urgencia.

9. Compara los gastos con el mismo alcance

Separa el coste de construcción del coste de uso cotidiano. El primero puede incluir la herramienta, la IA y el acompañamiento. El segundo puede incluir el alojamiento, los servicios conectados, el mantenimiento y las cuentas de usuario. Algunas suscripciones agrupan varios conceptos; pregunta cuáles antes de concluir que una opción es más barata.

• Al empezar: preparación de las necesidades, instalación, pruebas y posible traslado de datos.
• Durante la construcción: herramienta, consumo de IA, ayuda y tiempo dedicado a verificar.
• En funcionamiento: posible alojamiento, copias de seguridad, servicios necesarios y mantenimiento.
• Al salir: recuperación de elementos, traslado y puesta en marcha en otro lugar.

Haz dos cálculos con los precios realmente ofrecidos: uno para el equipo actual y otro para los cambios que prevés. En la galería podría ser la incorporación de otra sala de exposiciones. No inventes cientos de usuarios futuros solo para que una opción parezca más ventajosa sobre el papel.

Pregunta también cómo se detiene un gasto variable. ¿Quién recibe el aviso? ¿Quién puede interrumpir las peticiones a la IA o desactivar un servicio innecesario? La guía del presupuesto de una aplicación permite reunir estos conceptos. Ningún precio universal decide entre local y nube sin conocer este alcance.

10. Ensaya la recuperación antes de necesitarla

Elige un motivo plausible de traslado: cambiar de ordenador, sustituir a la persona responsable del proyecto o abandonar un proveedor. Prepara la recuperación mientras todo funciona. Tu interlocutor podrá mostrar los pasos con calma y explicar qué partes requieren su intervención.

Para un proyecto construido en local, prueba una copia preparada para la recuperación sin tocar el original. Para un proyecto en la nube, recupera los elementos permitidos y comprueba qué puedes poner en marcha con ellos. En ambos casos, pregunta por los datos de la aplicación final: su copia de seguridad puede ser distinta de la del código.

Inès selecciona tres fichas ficticias y una imagen y pide encontrarlas después de una recuperación de prueba. Paul revisa el contenido, no solo el número de archivos. Si falta información, anotan qué falta y cómo recuperarla. La promesa de poder cambiar de proveedor se convierte así en un resultado observable.

11. Utiliza una lista de decisión sencilla

Para cada solución, escribe una respuesta y su prueba junto a estas preguntas. «Por confirmar» es una respuesta válida durante la comparación. Debe seguir visible en la decisión final, con un responsable y una fecha de comprobación. Evita una nota global que esconda un requisito esencial entre detalles agradables.

• Construcción: ¿desde qué dispositivos puedes trabajar y con qué ayuda?
• Proyecto: ¿qué archivos recuperas y quién puede demostrar que permiten continuar?
• IA: ¿qué elementos se transmiten y bajo qué condiciones?
• Uso: ¿dónde funciona la aplicación final y quién organiza los accesos?
• Continuidad: ¿qué sigue siendo posible sin conexión o si un proveedor no está disponible?
• Gastos: ¿qué conceptos son fijos, variables, iniciales o asociados a la salida?

La galería empieza por sus requisitos: tres personas deben consultar los préstamos, una dirige la construcción y el proyecto debe poder entregarse a otra persona. Una solución que cumpla estas condiciones merece una prueba. La que no explique cómo recuperar el proyecto sigue pendiente, aunque su primera pantalla impresione más.

Puedes elegir una combinación: construcción local, IA remota y aplicación final alojada. También puedes escoger otra. Lo adecuado es comprender y probar las consecuencias, asignar responsabilidades y aceptar límites que encajen con tu actividad.

12. Haz una pequeña prueba antes de elegir

Retoma una sola situación: registrar un préstamo ficticio, cambiar su ubicación y preparar su devolución. Añade las comprobaciones importantes de tu lista: acceso desde los dispositivos adecuados, interrupción de conexión, recuperación de archivos y entrega a otra persona. Mantén el mismo escenario en todas las soluciones comparadas.

Anota lo que has observado y lo que solo se ha anunciado. Una demostración del proveedor, una prueba realizada por ti y una función prometida para más adelante no tienen el mismo valor. Podrás volver a esta hoja antes de contratar, empezar o pedir acompañamiento.

Maestro es una opción para construir en Mac: el proyecto y el historial se conservan en tu equipo, con posibles intercambios con el proveedor de IA configurado. El alojamiento y el uso compartido de la aplicación final se preparan por separado. Elegir Maestro no demuestra, por sí solo, que tu futura herramienta funcionará sin Internet.

A 23 de septiembre de 2026, Maestro está en beta por invitación para macOS 13 y versiones posteriores. La aplicación es gratuita durante la beta y el uso de IA se factura aparte; Windows está en desarrollo. Prepara tu escenario con la plantilla de requisitos de una aplicación y compara según lo que realmente tendrás que construir y utilizar.

Volver al índice