Decidir si necesitas una aplicación propia
Una aplicación propia tiene sentido cuando existe un trabajo específico que las herramientas disponibles no resuelven de forma adecuada para tu operación. Antes de construir, describe el problema, quién lo experimenta y cómo se aborda hoy. Compara el esfuerzo de adaptación, integración y mantenimiento con el beneficio que buscas obtener.
Imagina un equipo que distribuye solicitudes a través de varias hojas de cálculo y mensajes. Quizá baste con organizar mejor la herramienta existente. Quizá haga falta una interfaz que reúna reglas, disponibilidad y seguimiento en un único recorrido. La decisión depende del trabajo concreto y de las limitaciones observadas, no solo de la facilidad para generar una primera página.
En el libro que escribí en 2022, conté una experiencia profesional relacionada con la planificación de una aplicación para lavanderías. El análisis ayudó a cuestionar el proyecto antes de avanzar. Hoy la IA puede acelerar la construcción, pero sigo queriendo comprender la necesidad y las condiciones del negocio antes de invertir en esa ejecución.
Si el problema consiste sobre todo en conectar herramientas, empieza por la automatización de procesos empresariales. Una aplicación añade interfaz, usuarios y responsabilidades de mantenimiento. A veces esa capa tiene valor; en otras situaciones, un proceso bien organizado basta para mejorar el trabajo sin crear otro producto que mantener.
Escribir el comportamiento antes de pedir código
Un plan de aplicación debe explicar quién la usa, qué información introduce, qué decisiones toma el sistema y qué resultado entrega. Incluye excepciones y diferencias entre permisos. La IA puede trabajar con instrucciones más concretas cuando el comportamiento esperado está escrito y acompañado de ejemplos que permiten comprobar el resultado.
La aplicación de pronósticos deportivos que construí con Claude Code necesitaba preparación antes de generar código. El proyecto incluía usuarios, reglas de puntuación, horarios e integraciones. Esos elementos muestran que construir una aplicación exige definir qué ocurre más allá del aspecto visual de la primera pantalla.
Para una solicitud de reunión, por ejemplo, escribiría qué ocurre si no hay disponibilidad, si la misma solicitud entra dos veces y si alguien intenta consultar la solicitud de otra persona. Añadiría quién puede cambiar el estado y quién solo lo consulta. Son pequeñas decisiones que cambian bastante la implementación.
Desarrollo esa preparación en el artículo sobre planificar una aplicación con Claude Code antes de programar. En esta página, me interesa el recorrido completo hasta el uso diario. El plan inicial debe seguir disponible cuando aparecen cambios, para que el proyecto no dependa del recuerdo de una conversación con la IA.
Construir una primera versión que permita aprender
La primera versión debe completar un recorrido útil, con los controles necesarios para los usuarios previstos. Elige un objetivo pequeño y comprueba la secuencia de principio a fin. Esa versión permite observar dificultades reales antes de añadir informes, personalizaciones y funcionalidades para las que todavía no tienes evidencia suficiente que permita priorizarlas.
En un ejemplo de gestión de solicitudes, empezaría por la entrada, la consulta autorizada, la asignación y la actualización del estado. Un panel con decenas de métricas puede esperar hasta que entendamos qué decisiones necesita tomar el equipo. Si la información llega incompleta, mejorar los gráficos no resuelve la dificultad inicial de trabajar con la solicitud.
Pide a la IA cambios delimitados y revisa el resultado después de cada uno. Un cambio en el formulario puede afectar a la validación, al guardado y a los mensajes de error. Ver la pantalla actualizada es solo parte de la revisión. Interesa confirmar que los datos llegan correctamente al destino y siguen siendo accesibles solo para quienes deben verlos.
Una aplicación puede incorporar un modelo para interpretar texto, pero también puede funcionar íntegramente con reglas después de construirse. La herramienta de seguimiento de campañas que construí con IA sigue ese segundo enfoque. Mantener clara la diferencia ayuda a estimar costes y a entender qué partes exigen evaluar respuestas generadas.
Revisar los accesos y los datos antes de invitar a usuarios
Antes de invitar a usuarios, comprueba cómo identifica la aplicación a cada persona, autoriza acciones y protege los datos guardados. Prueba los accesos indebidos con cuentas separadas y confirma que los secretos no llegan al navegador. La revisión debe abarcar el servidor y la base de datos, además de los botones y las páginas visibles en la interfaz.
Si un usuario cambia la dirección de una solicitud, la aplicación debe volver a confirmar la autorización. Ocultar el enlace a esa solicitud no protege el recurso. Lo mismo se aplica a las descargas y a las operaciones de edición: cada acción necesita saber quién la está solicitando y qué acceso tiene esa persona.
Mis reglas incluyen permisos explícitos en la base de datos, autorización en el servidor, comprobación de acceso por recurso, protección de claves y validación de entradas. Las explico con ejemplos en la página de seguridad de aplicaciones desarrolladas con IA. Son preguntas que deben acompañar la construcción desde el principio.
También separo los accesos de la herramienta de desarrollo de los accesos del producto final. La documentación de seguridad de Claude Code describe permisos y precauciones con el contenido externo. Esos mecanismos ayudan a controlar la herramienta, pero no sustituyen la revisión de la aplicación que se ha construido con ella.
Probar el trabajo real y preparar la publicación
Las pruebas deben comprobar los recorridos importantes, los errores previsibles y los límites de acceso antes de la publicación. Usa ejemplos representativos, incluidos datos incompletos y acciones repetidas. Prepara también la configuración de producción, las copias de seguridad y una forma de recuperarse cuando un cambio produzca un resultado distinto del esperado.
Pide a alguien que ejecute una tarea sin explicarle cada clic. ¿Dónde duda? ¿Entiende el error cuando falta un campo? ¿Puede volver al trabajo después de cerrar la página? Esas observaciones ayudan a mejorar el producto y muestran problemas que una revisión hecha solo por quien lo ha construido puede pasar por alto.
Comprueba el móvil, los estados de carga y los mensajes cuando falla una integración. Un botón sin respuesta deja al usuario sin saber si debe volver a intentarlo. Si la operación puede crear una solicitud o enviar un mensaje, la aplicación debe ayudar a distinguir qué ha quedado completado y qué sigue pendiente de confirmar.
Documenta la configuración necesaria sin poner credenciales en el código. Antes de sustituir una versión en uso, confirma cómo volver a la anterior y cómo tratar los posibles cambios en los datos. Esta preparación forma parte del coste de poner software a trabajar en una empresa, aunque escribir el código haya sido bastante rápido.
Asumir el mantenimiento como parte del proyecto
Una aplicación en uso necesita seguimiento de errores, revisión de dependencias y decisiones sobre nuevas funcionalidades. Define quién recibe los problemas, quién puede publicar cambios y cómo se confirma que una corrección ha funcionado. El mantenimiento debe conservar el conocimiento del proyecto, incluidas las razones detrás de las reglas que utiliza el equipo.
Cuando llega una solicitud de cambio, vuelve al objetivo y al comportamiento existente. Un nuevo permiso puede facilitar una tarea y exponer información a otras personas. Una integración puede ahorrar copias y crear una dependencia externa. Debatir esas consecuencias ayuda a elegir qué debe incorporarse y cómo debe comprobarse.
En Laboratório da IA reviso proyectos en dos mentorías al mes. La mentoría de IA y negocios permite debatir decisiones y dificultades mientras desarrollas tu trabajo. Si la necesidad es preparar a un equipo, también existe la vía de la formación de IA para empresas, con un objetivo y un formato definidos a partir del contexto.
Para una implementación acompañada por el equipo, presenta el problema a SpartAds. Lleva el proceso actual, quién va a usar la aplicación y qué has intentado ya. Eso permite evaluar la necesidad de software propio y el trabajo necesario para mantenerlo útil después de la primera entrega.