ArtVault y cómo hacerles la vida más sencilla a los artistas
Una parte de mí siempre ha estado ligada al mundo del arte, y sigue estándolo. Crear, para mí, es como respirar. En mi entorno, muchos amigos son pintores, diseñadores, ilustradores, fotógrafos. Un día, hablando con una de ellas sobre su trabajo artístico, me di cuenta de que malgastaba un montón de tiempo en tareas administrativas. Y me sentí identificada.
Presentar algo a un concurso, por ejemplo, le consumía mucho tiempo: buscar los datos de la obra, recopilar especificaciones técnicas... Hacerlo una vez es viable, pero cuando se vuelve habitual, llega el descontrol y el caos. No había un sistema que unificara todo el catálogo de su obra y estuviera listo para consultar, mostrar o compartir, más allá de Instagram o su web —soluciones donde la trazabilidad de la obra quedaba fuera.
En ese momento, entre una tapa y otra, mientras seguíamos conversando sobre el ecosistema del arte, me vino la idea a la cabeza. ¿Por qué no montar un gestor de obras? Por mi experiencia en museos, era consciente de que ya existen gestores de archivo muy potentes que incluyen todo esto —la trazabilidad, el archivo de obra, la catalogación—, pero eran soluciones demasiado ambiciosas para un artista de a pie. La idea se quedó rondándome la cabeza, pero antes de empezar a diseñar tenía que entender mejor el mercado, la competencia y las necesidades reales de los artistas.
Buceé entre las soluciones que ya existían en el mercado e hice lo que todos conocemos como benchmarking —la primera pieza de investigación de un proceso que después seguiría con conversaciones informales y definición de producto mínimo viable. Los productos que investigué me confirmaron que había un hueco interesante entre las grandes soluciones para museos, archivos y galerías, y las soluciones más sencillas para simplemente mostrar la obra. Entre ambos extremos existía la oportunidad. Fue entonces cuando ArtVault empezó a fraguarse.
Antes de seguir, tenía que hablar algo más con los artistas. Lo hice de forma informal, y todos coincidían en las pocas ganas de gestionar la obra —por pereza, por falta de conocimientos, por falta de tiempo. Todos sobrevivían según la necesidad del momento: se acercaba un concurso, una feria, una expo, y el dossier iba surgiendo sobre la marcha. Lo tenía claro: mi aplicación debía proporcionarles una herramienta profesional para gestionar su catálogo, y tenía que hacerles la vida más sencilla. Quitarles tiempo de gestionar, para darles más tiempo de crear.
Cogí la idea por el pescuezo y la bajé a tierra. Apunté en mi Notion —mi segundo cerebro, de eso hablaré en otro post— todas las necesidades que me habían ido contando, cotejé cómo respondían a ellas otras herramientas, y empecé a adaptarlo a mi público objetivo: artistas individuales, consagrados y emergentes, con una característica clave en común: ellos mismos gestionan su propio archivo.
La siguiente pregunta que me hice fue: ¿todos los artistas necesitan lo mismo? No, estaba claro que no. Cada disciplina tenía características propias, intrínsecas a su naturaleza, y a la hora de empezar a construir tenía que tenerlo claro.
Construir. ¿Pero por dónde empezar? Tenía las necesidades, pero necesitaba entender los flujos. ¿Cuál era el flujo principal? Todo tiene que comenzar con una obra. De eso se trata: un gestor de obra artística empieza siempre por una obra. Este fue el paso que más tiempo me llevó pensar. ¿Qué necesita cada tipo de artista? No es lo mismo un pintor, cuya obra es siempre original, que un ilustrador, cuya obra es reproducible: puede ser única, puede ir en tirada, puede ser una edición limitada.
Esa diferencia no se quedaba en el papel: cambiaba el propio formulario. Si una obra era única, ahí terminaba su ficha: un estado, una ubicación, un historial de movimientos. Pero si era reproducible, esa misma obra podía desplegar su propia tabla de copias, cada una con su estado y su ubicación propios —porque un grabado en edición de 20 no es una sola pieza, son 20 piezas que pueden estar, cada una, en un sitio distinto. Entender esta diferencia era clave para diseñar el primer flujo: añadir una obra.
En ArtVault esto es primordial. Tenía que tener en cuenta todos los parámetros, porque todo el sistema iba a beber de ahí. ¿Qué debía contener ese primer formulario? Le di forma con toda la información recopilada, y aunque seguramente no sea perfecto —siempre hay opción de mejora—, para un MVP era suficiente.
Ese formulario no era solo una pantalla más: era el origen de todo. Cada obra que un artista registra ahí —con su estado, su ubicación, si es única o tiene copias— se convierte en el dato que alimenta el resto de la app. La misma obra aparece en su historial de movimientos cuando cambia de sitio, puede colgar de un certificado si hace falta acreditarla, y puede entrar en uno o varios portfolios distintos sin que tengas que volver a introducir sus datos cada vez. Diseñar bien ese primer formulario significaba que todo lo demás —el portfolio para una galería, el registro de qué pieza está prestada y a quién— se construía solo, en vez de pedirle al artista que rellenara la misma información una y otra vez.
Una vez definido esto, creé el sitemap completo y empecé a diseñar los primeros wireframes en baja resolución, para hacerme ya una idea general del funcionamiento de la app.
Y en ese momento me surgió una duda. Estas cosas pasan a mitad del proceso. La idea, desde el inicio, siempre fue crear un gestor. Pero, ¿no debería poder también vender obra? Un paso atrás: tenía que mirarlo con perspectiva y volver a investigar. Existían sitios de venta de obra, sí. Podría hacer algo adaptado, seguro. Mi público objetivo lo necesitaba, sí. Era una necesidad real que no había tenido en cuenta.
Y ahí me hice la pregunta más importante: ¿puedo llegar a eso? La respuesta fue no. Por el momento, no. Para un primer producto mínimo viable, con mis recursos, se tenía que quedar fuera. Quizá en el futuro se pueda ampliar con un módulo de venta, pero con mis conocimientos en ese momento —aun teniendo Stripe en el radar— se quedaba fuera. Implicaba un esfuerzo que no podía asumir.
En producto, estas decisiones son cruciales, porque pueden ser positivas o pueden meterte en una espiral de descontrol. En este caso, decidí centrarme en resolver la necesidad principal: reducir el tiempo de gestión del archivo.
Una vez apartado esto, creé la marca. Mi background de diseñadora gráfica y técnica de marketing salió a jugar. Personalmente, esta parte siempre me ha encantado: construir marcas. Y aquí tenía la oportunidad de disfrutarlo. Marca, producto y negocio, todo a una, como Fuenteovejuna.
Tocaba avanzar y meterme en el barro. Comenzaba el desarrollo. Y aquí entraba mi nuevo descubrimiento, el que os contaba en mi anterior publicación: el no-code. Mi primera aproximación fue con Lovable, pero es verdad que enseguida lo cambié todo a Claude Code, que es la herramienta que uso actualmente y con la que me siento más cómoda. Le di todo lo que tenía, y empezamos a construir.
Ya os digo que no salió bien a la primera. Iteré una, dos, muchas veces. Pero por fin la tenía: una aplicación completamente funcional, sencilla y navegable al cien por cien.
Lo que salió de ahí fue más de lo que esperaba al principio: el diseño completo del sistema, con sus componentes definidos; un manual de marca hecho desde cero; y un prototipo funcional, publicado, conectado a una base de datos real —no una maqueta que se queda en el papel, sino algo que se puede abrir y usar.
Ahí estaba: ArtVault, funcionando, con un catálogo real donde antes solo había una carpeta desordenada de fotos. No es el producto final. Pero es la prueba de que una idea puede cobrar vida rápidamente, ayudar a confirmar si funciona y ahorrar mucho tiempo de trabajo si no lo hace.
Puedes ver este y otros proyectos en erikaromera.com o en Behance.
