En el capítulo 4, «Crea con la IA», lograste algo que funciona. A partir de aquí empieza la fase 4, «publicar»: comprobar con pruebas que no se rompe, tapar los agujeros de seguridad y, por fin, publicarlo al mundo. No te conformes con «funciona»; llévalo hasta un estado en el que otros puedan usarlo con tranquilidad. Suena difícil, pero también aquí la IA es tu aliada.
«Aunque no esté acabado, hazlo llegar con seguridad a una persona»
«Crearlo» y «poder publicarlo» no son lo mismo
Algo que funciona en tu propio ordenador y algo que aguanta que lo toquen otros son cosas distintas. Tú conoces «la forma correcta de usarlo», así que lo manejas como se espera. Pero, al publicarlo, llegan entradas, operaciones y malas intenciones que no habías previsto: quien envía en blanco, quien pega un montón de símbolos, quien intenta espiar los datos de otros...
Aun así, no hace falta ponerse a la defensiva. Lo primero que debes hacer en el desarrollo indie son solo tres puntos muy básicos: «que no se rompa», «que no se filtren los secretos» y «que se protejan los datos ajenos». Este capítulo trata de superar ese mínimo junto a la IA para publicar con la cabeza bien alta.
Solo lo tocas por los pasos correctos. Si sale un error, lo arreglas tú. No te importa que aparezca información secreta en pantalla.
Llegan entradas inesperadas. Se filtra información interna desde la pantalla de error. Con una clave publicada por descuido, hasta facturas altísimas o fugas de datos.
Deja las pruebas y la revisión en manos de la IA
«Al desarrollar en solitario, no tengo un veterano que me revise el código»... Justo ese papel, déjaselo a la IA. El código que escribiste (o que hiciste escribir a la IA), haz que la IA lo revise de nuevo con otra mirada. Quien lo escribe (persona o IA) tiene difícil notar sus propios fallos. Por eso funciona poner a un «auditor».
La forma es sencilla. Pega el código y pide solo esto: «Enumera los errores, las entradas peligrosas y las pruebas que faltan en este código». Entonces te devuelve, en forma de lista, los agujeros de los que no te habías dado cuenta. Después, corrige de uno en uno, empezando por lo más prioritario. El truco es no intentar arreglarlo todo a la vez: corrige una indicación, comprueba el funcionamiento, y otra más.
Cuando pidas la auditoría a la IA, la precisión sube si indicas de forma explícita enfoques como estos.
«¿Cuándo se cae?» «¿Y si le paso un campo vacío o un cero?» Haz que la IA busque las condiciones en que se rompe.
Cadenas malintencionadas, datos enormes, archivos no válidos. Pregunta «si fueras un atacante, ¿cómo lo aprovecharías?».
«¿Qué casos deberían comprobarse y no se están comprobando?» Haz que saque a la luz valores límite y excepciones.
«¿Hay claves de API o contraseñas escritas directamente en el código?» Corta de raíz el germen de una fuga.
💡 Una prueba es «un mecanismo que comprueba en automático». Si vas por la ruta práctica, haz que la IA escriba hasta el código de las pruebas. Si pides «escribe las pruebas de esta función, con el caso normal y también los de campo vacío y valores anómalos», la próxima vez que corrijas podrás volver a comprobar con un solo botón que no se ha roto. En la ruta de iniciación, aunque sea a mano «probar a hacer cosas raras a propósito» ya es un buen primer paso.
Los 3 mínimos de seguridad
La seguridad es un campo profundo, pero, al publicar en desarrollo indie, memoriza solo los 3 puntos que hay que respetar sí o sí. Si te saltas estos tres, puedes perder de golpe dinero, confianza e información ajena. Al revés: con respetar esto, para una primera publicación es suficiente.
No escribas directamente en el código claves de API, contraseñas ni tokens. Sácalos a un archivo de variables de entorno como .env y excluye ese archivo de lo que publicas (añádelo al .gitignore).
Si hay función de inicio de sesión, haz que una persona no pueda ver los datos de nadie más. Introduce sin falta la comprobación de propiedad «¿estos datos son de verdad de esta persona?», y haz que la IA lo verifique.
Las claves de servicios externos y los permisos de la BD, solo lo justo. No repartas claves que «lo pueden todo». Emite claves de un solo uso, claves de solo lectura y demás, acotando el propósito.
🚨 Jamás publiques una clave secreta. Este es el accidente más frecuente del desarrollo indie, y el más caro. Si publicas en GitHub y sitios similares con una clave de API escrita directamente en el código, en minutos u horas la encuentran automáticamente y la usan con malos fines. Con una API de pago, cuando te das cuenta ya tienes una factura de cientos de miles: ocurre de verdad. Antes de publicar, haz siempre que la IA revise «si queda alguna clave en el código». Y si una clave se publicó aunque solo fuera una vez, borrarla no basta: hay que invalidarla sin falta y emitir una clave nueva.
Si sientes que «suena difícil», basta con preguntar a la IA así: «Antes de publicar este código, enséñame, para principiantes, lo que debería hacer en cuanto a seguridad». Te devuelve una lista de comprobación concreta ajustada a tu código.
Ejecutar la automatización con seguridad (para la ruta práctica)
Esto es sobre todo para la ruta práctica 🔧. Si dejas que un agente de IA como Claude Code se encargue de forma automática de operaciones con archivos y ejecución de comandos, el desarrollo se acelera de golpe. Por otro lado, el riesgo de desbocarse —«borra por su cuenta un archivo importante», «ejecuta comandos no previstos»— no es cero.
Por eso importa la idea del «aislamiento (sandbox)». Cuando le des a la IA permisos fuertes, ejecútala dentro de una caja donde no pase nada aunque haya daños. En concreto, enciérrala en una carpeta de trabajo o un contenedor dedicados, de modo que no pueda tocar los datos de producción ni la información secreta. Así puedes delegar la automatización en la IA con tranquilidad.
📦 El principio es «prueba dentro de la caja, y a producción despacio». No ejecutes la acción automática de la IA directamente sobre el entorno de producción ni sobre datos importantes. La forma concreta de aislar se explica en detalle en la guía de configuración del sandbox de Claude Code. Quien va por la ruta de iniciación, con solo saber que «existe esa medida de seguridad» tiene suficiente en esta sección.
Publicar: del código a estar en internet
Por fin, la publicación. «Publicar» es poner lo que tienes dentro de tu ordenador en internet, en un estado en el que cualquiera pueda abrirlo con una URL. A esto se le llama desplegar (deploy). Suena difícil, pero hoy en día se sube a servicios gratuitos con unos pocos clics.
El flujo general son los 3 pasos siguientes. La primera publicación del desarrollo indie se cubre de sobra toda con el plan gratuito. Gastar dinero puede esperar a que aumenten las personas que lo usan.
Guarda el código en GitHub y sitios similares. No olvides excluir los archivos secretos (.env). Esta es la base de la publicación.
Enlaza GitHub con un hosting gratuito como Vercel. La información secreta, regístrala como variables de entorno desde el panel de administración.
Se compila en internet de forma automática y se emite una URL pública. Ya solo queda entregarle esa URL a una persona.
✅ Aunque no esté acabado, publícalo y enséñaselo a una persona. «Aún le faltan funciones», «el diseño es flojo»... Aplazar la publicación con ese sentimiento es la causa número uno de que un desarrollo indie desaparezca. 60 puntos basta. Llega hasta enviar la URL pública a una persona cercana. Su comentario de «esto es incómodo de usar» vale más que 100 horas de darle vueltas.
Los pasos concretos —desde guardar en GitHub hasta publicar en Vercel y configurar las variables de entorno— se explican con capturas de pantalla en Crear con Claude Code / Cursor y publicar en Vercel. Si te atascas, pregunta a la IA tal cual «me salió un error en esta pantalla, ¿qué hago?» y casi siempre saldrás del apuro.
- Aunque desarrolles en solitario, el papel de revisor, a la IA. Haz que audite con «enumera errores, entradas peligrosas y pruebas que faltan» y corrige de uno en uno.
- La seguridad son 3 mínimos: los secretos a variables de entorno / protege los datos ajenos / permisos al mínimo.
- Jamás publiques una clave secreta. Si se filtra, no la borres: invalídala y vuelve a emitirla. Revisa con la IA antes de publicar.
- Publicar (desplegar) vale con el plan gratuito. Aunque no esté acabado, llega hasta entregar la URL a una persona.
Con esto has llegado hasta «crear y publicar con seguridad». Pero la verdadera batalla empieza aquí. La fase final es conseguir que lo usen, mejorarlo y darle una forma sostenible. Pasa al capítulo 6, «Hacer crecer: captación y monetización».