Cómo he creado mi segundo proyecto con Google AI Studio: un media kit interactivo desde cero

De una idea a una web funcional: así ha sido mi experiencia creando un media kit interactivo con Google AI Studio, Firebase y Netlify, entre pruebas, errores y muchas horas de práctica.

Hay proyectos que empiezan porque tienes una idea que te apetece probar y otros porque necesitas resolver un problema. Este reúne las dos cosas.

Llevaba tiempo pensando en cómo presentar mis colaboraciones con marcas de una manera más completa. Como fotógrafa y creadora de contenido, acumulo productos que he probado, campañas, publicaciones, enlaces y proyectos. Toda esa información es útil cuando una marca quiere conocer mi trabajo, pero mantenerla organizada y presentarla de una forma atractiva no siempre resulta sencillo.

Podía hacer un PDF, actualizarlo cada cierto tiempo y enviarlo cuando alguien me lo pidiese, que es lo que hacía hasta ahora. Sin embargo, quería algo más flexible: una página que pudiese consultar cualquiera, con información organizada y enlaces a mis publicaciones, pero que también me permitiese actualizar el contenido sin tener que rehacer el documento cada vez.

Así nació la idea de crear mi propio media kit interactivo.

Y, como me gusta experimentar con el desarrollo web, decidí volver a utilizar Google AI Studio para construirlo.

Antes de empezar: no soy desarrolladora, pero me gusta trastear

Aunque no me dedico profesionalmente al desarrollo, llevo tiempo creando páginas web y aprendiendo por mi cuenta. He trabajado con WordPress, Squarespace y Blogger, he tocado HTML y he ido descubriendo cómo funcionan estas herramientas a base de práctica y error.

De hecho, este no era mi primer proyecto de este tipo. Antes ya había construido un CMS totalmente funcional, así que tenía cierta experiencia organizando contenidos y pensando cómo debía funcionar una herramienta que necesitase utilizar de manera habitual.

Google AI Studio iba a ser mi herramienta principal para desarrollar el proyecto. Mi trabajo consistiría en definir lo que necesitaba, revisar lo que generaba, probarlo y corregir los problemas que fuesen apareciendo.

1. Definir qué quería construir

Antes de entrar en cuestiones técnicas, tocaba decidir qué debía incluir el media kit.

Quería una presentación con mi perfil, mi biografía, mis especialidades, las marcas con las que había trabajado y los productos que me habían enviado. También necesitaba mostrar publicaciones, enlaces a campañas, proyectos y otra información que ayudase a entender mi actividad como creadora de contenido.

Además, quería que estuviese disponible en varios idiomas y que no se quedase obsoleto en cuanto incorporase una nueva colaboración. Finalmente, debía incluir un formulario de contacto totalmente funcional. 

La parte más importante era el panel de administración. Necesitaba poder añadir marcas, modificar descripciones, asociar publicaciones y actualizar los datos desde una interfaz propia, sin tener que abrir los archivos de la web para cambiar cada elemento manualmente.

Con esa idea clara, empecé a construir la primera versión.

2. Google AI Studio: construir, probar y volver a construir

Trabajar con Google AI Studio me permitió desarrollar el proyecto de manera progresiva. Le explicaba qué quería conseguir, revisaba el resultado y solicitaba cambios cuando algo no funcionaba o no se ajustaba a lo que tenía en mente.

El proceso no consistió en escribir una única instrucción y obtener una aplicación terminada. Había que ir afinando la estructura, los componentes, los formularios y el funcionamiento del panel.

A medida que la web crecía, también lo hacía su complejidad. Una cosa es mostrar información estática y otra permitir que se añada, se edite, se elimine y se conserve correctamente.

La interfaz podía estar terminada visualmente, pero todavía faltaba una parte fundamental: asegurarme de que los datos no desapareciesen cuando cerrase la página.

3. El primer gran problema: ¿dónde se guardaban los datos?

Al principio, parte de la información se guardaba en localStorage, un mecanismo que permite conservar datos en el navegador.

Es útil para determinados casos, pero no era suficiente para lo que necesitaba. Los datos guardados de esa manera dependen del navegador y del dispositivo, y pueden desaparecer si se borran sus datos. Tampoco constituyen por sí solos una base de datos centralizada a la que acceder desde distintos dispositivos.

Yo quería poder actualizar el media kit y tener la tranquilidad de que la información seguiría disponible.

Por eso decidí utilizar Firebase y, concretamente, Cloud Firestore como base de datos.

La idea era que las marcas, sus descripciones y el resto de la información importante quedasen guardados en un servicio externo, en lugar de depender exclusivamente del almacenamiento del navegador.

Parecía un paso lógico, pero fue aquí donde empezaron algunos de los problemas más técnicos del proyecto.

4. Firebase y Firestore: permisos, configuración y errores

Al conectar la aplicación con Firestore, descubrí que la base de datos no estaba habilitada correctamente en el proyecto. Algunas operaciones fallaban y aparecían errores relacionados con los permisos.

Por mucho que el panel tuviese botones para guardar información, la aplicación necesitaba una base de datos correctamente configurada y unas reglas que permitiesen realizar las operaciones correspondientes.

Tuve que entrar en la consola de Firebase, habilitar Cloud Firestore y crear la base de datos. Después, tocaba revisar las reglas de seguridad y comprobar qué podía hacer cada tipo de usuario.

No quería que cualquiera pudiese modificar la información de mi media kit. Por eso, trabajé en separar los datos privados del panel de administración de la información pública que se muestra en la web.

La intención era que mi cuenta verificada tuviese acceso a la gestión privada, mientras que la parte pública pudiese consultar únicamente el contenido publicado. También había que limitar los datos que se aceptaban desde los formularios públicos.

Esta parte me hizo entender algo importante: conectar una web con una base de datos no consiste únicamente en indicar dónde guardar la información. También hay que decidir quién puede leerla, quién puede modificarla y qué operaciones están permitidas.

5. Cuando una función funciona en desarrollo, pero falla en la web publicada

Otro problema apareció con una función de respaldo.

Durante el desarrollo, el código intentaba utilizar un endpoint que no estaba disponible de la misma manera en el despliegue de Netlify. Al publicar la web, la petición devolvía un error 404.

El motivo era que la aplicación publicada no disponía de ese endpoint. No bastaba con que el código intentase llamarlo: tenía que existir un servicio que atendiese la petición.

Esto me obligó a revisar cómo estaba planteada esa parte del proyecto y a distinguir entre las herramientas disponibles durante el desarrollo y las que realmente funcionan en una web estática publicada.

Son esos detalles que a veces pasan desapercibidos cuando estás construyendo la interfaz, pero que aparecen en cuanto intentas utilizar la aplicación en condiciones reales.

6. El capítulo de las imágenes

Quería que el panel permitiese subir imágenes, empezando por mi propia fotografía y continuando con los recursos asociados a las marcas y los proyectos.

La primera opción era utilizar Firebase Storage, el servicio de Firebase destinado al almacenamiento de archivos. Sin embargo, las peticiones de subida devolvían un error 404 porque el almacenamiento no estaba provisionado correctamente.

En lugar de seguir intentando utilizar una función que no estaba preparada, cambié el planteamiento.

La alternativa que probé consistía en comprimir las imágenes en el propio navegador y guardar su contenido codificado en Base64 dentro de Firestore.

La compresión era importante porque no tenía sentido guardar fotografías enormes sin reducir su tamaño. El objetivo era conseguir archivos suficientemente ligeros para que el proceso fuese más manejable.

Pero el problema no terminó ahí. El diagnóstico de la subida se quedaba atascado y no avanzaba. Hubo que revisar cómo se generaba la vista previa de la imagen, cómo se procesaba el archivo y cómo se gestionaban los tiempos de espera y los errores.

Esta solución permitió cambiar el enfoque de la subida, aunque también tiene limitaciones: guardar imágenes en una base de datos no equivale a utilizar un servicio de almacenamiento de archivos y hay que vigilar el tamaño de los datos, el consumo y los límites del servicio. Es algo que tendría en cuenta si el proyecto siguiese creciendo.

7. Los botones que parecían funcionar, pero no guardaban correctamente

A medida que fui utilizando el panel, aparecieron otros fallos menos llamativos, pero igual de importantes.

Algunas operaciones de guardado no esperaban correctamente a que terminase la escritura en Firestore. La interfaz podía dar la impresión de que todo había salido bien, aunque la base de datos todavía no hubiese confirmado la operación.

También ocurría que algunas marcas de ejemplo reaparecían después de eliminarlas. El problema estaba en una parte del código que volvía a introducir esos datos de demostración.

La solución no consistía simplemente en pulsar otra vez el botón. Había que revisar qué hacía el programa después de guardar o eliminar una marca y eliminar la lógica que volvía a introducir contenido que ya no debía estar ahí.

Estos errores me recordaron que hay que probar las operaciones completas. No basta con comprobar que una tarjeta desaparece de la pantalla o que un mensaje de confirmación aparece. También hay que verificar que los datos se hayan guardado realmente y que el estado se mantenga al volver a cargar la página.

8. Publicar la web con Netlify

Cuando el proyecto empezó a funcionar como quería, llegó el momento de publicarlo.

Elegí Netlify para alojar la web, pero me encontré con una diferencia importante entre el código fuente y los archivos finales que necesita la página publicada.

El proyecto tenía archivos como package.json, vite.config.ts y la carpeta src, que forman parte del entorno de desarrollo. Sin embargo, para un despliegue manual necesitaba la carpeta generada con los archivos finales de la aplicación.

En mi caso, esa carpeta incluía el index.html, los recursos de assets, el archivo _redirects y otros elementos necesarios para que la web se mostrase correctamente.

Una vez generado el proyecto, tuve que identificar la carpeta adecuada y subirla a Netlify. No era cuestión de arrastrar cualquier carpeta, sino de publicar los archivos preparados para producción.

Puede parecer un detalle menor, pero entender esta diferencia evita muchos problemas cuando estás trabajando con herramientas que generan una aplicación a partir de un proyecto de código.

9. La vista previa de WhatsApp que no quería actualizarse

Cuando ya tenía el media kit publicado, apareció un último detalle: al compartir el enlace por WhatsApp seguía apareciendo una fotografía antigua.

La web mostraba su contenido correctamente, pero la tarjeta que acompañaba al enlace no utilizaba necesariamente la misma imagen que aparecía dentro de la aplicación.

Para averiguar qué ocurría, revisé el archivo index.html y las etiquetas Open Graph, que son las que proporcionan a plataformas como WhatsApp información sobre el título, la descripción y la imagen que deben utilizar al compartir una página.

Descubrí que el archivo og-image.jpg seguía conteniendo la fotografía antigua y que el HTML indicaba expresamente que debía utilizarse esa imagen.

Cambiar la fotografía desde el panel de administración no modificaba automáticamente ese recurso. Eran dos elementos distintos.

Preparé una versión del archivo HTML que dejaba de declarar una imagen para la vista previa y volví a publicar los archivos modificados. Aun así, este tipo de cambios puede tardar en reflejarse porque WhatsApp puede conservar temporalmente una tarjeta anterior en su caché.

Fue otro de esos problemas que no afectan necesariamente al funcionamiento de la web, pero sí a cómo se presenta cuando compartes el enlace.

10. Las copias de seguridad: mejor prevenir

Después de todo el trabajo invertido en añadir marcas, redactar descripciones y asociar publicaciones, no quería depender únicamente de que el panel siguiese funcionando.

Por eso, el proyecto cuenta con una opción para descargar un respaldo en JSON. Este archivo permite conservar una copia de los datos y comprobar qué información se ha exportado.

Antes de realizar los últimos cambios en Netlify, descargué el respaldo y comprobé que contenía las marcas y otros datos del media kit.

Esto no sustituye a una estrategia completa de copias de seguridad de la base de datos, pero sí me proporciona una copia exportada que puedo conservar y consultar.

Después de tantos errores, una de las cosas que más valoro es poder hacer cambios sin sentir que cualquier fallo me obliga a empezar de cero.

El resultado: una herramienta hecha a mi medida

Después de todas estas pruebas, tengo mi propio media kit interactivo, con una parte pública para presentar mi trabajo y un panel privado desde el que gestionar el contenido.

No significa que todo esté perfecto ni que el proyecto no pueda seguir mejorando. Hay decisiones técnicas que conviene revisar a medida que una aplicación crece, especialmente en cuestiones como el almacenamiento de imágenes, las copias de seguridad y la seguridad de los datos.

Pero he conseguido construir una herramienta que responde a una necesidad real de mi trabajo y que puedo seguir adaptando a medida que cambien mis colaboraciones.

Lo más interesante de este proceso no ha sido solamente tener la web terminada. Ha sido aprender cómo se relacionan las distintas partes de una aplicación: la interfaz, la base de datos, los permisos, el almacenamiento, el despliegue y los metadatos que utilizan otras plataformas.

Google AI Studio ha sido una herramienta muy útil para desarrollar el proyecto, pero el proceso ha requerido bastante más que una instrucción inicial. He tenido que explicar lo que quería, revisar los resultados, detectar fallos, investigar las causas y probar distintas soluciones.

Ya había trabajado con WordPress, Squarespace y Blogger, había tocado HTML y había construido un CMS funcional. Este proyecto me ha permitido seguir explorando ese interés por el desarrollo web y enfrentarme a problemas nuevos.

No soy desarrolladora de profesión, pero me gusta aprender cómo funcionan las cosas y construir herramientas que me resulten útiles. Y, al final, esa curiosidad es lo que me ha llevado a terminar este segundo proyecto con Google AI Studio.

Ahora tengo un media kit que puedo utilizar en mi trabajo y una lista bastante larga de cosas que he aprendido por el camino.

Y seguramente no será el último proyecto que me apetezca construir.