# RBT Studio — Ricard Boixeda > Portfolio de Ricard Boixeda: más de 10 años de ingeniería frontend, producto AI-native y código generativo, con formación en Bellas Artes. Barcelona. URL: https://rbt-studio.com/ · Email: contact@rbt-studio.com ## Sobre Ricard Boixeda Diseño cómo se sienten las cosas al usarse, no sólo cómo funcionan. Soy Ricard Boixeda — Experience Engineer con más de 10 años traduciendo sistemas complejos en productos digitales claros, usables y sofisticados. Mi perfil combina Bellas Artes, ingeniería frontend, product thinking e interfaces AI-native. Diseño y construyo sistemas frontend donde la interacción, el movimiento y la claridad UX son tan deliberados como la arquitectura que hay detrás. Cómodo llevando toda la superficie de producto: de los design systems y la arquitectura de componentes a las interfaces con IA y el creative technology. - **Origen:** Bellas Artes → frontend. Bellas Artes en la Universidad de Barcelona. La sensibilidad visual y el pensamiento conceptual son la base de cada decisión técnica. - **Perfil:** Producto · UX · IA. Más de 10 años traduciendo complejidad técnica en experiencias utilizables. Startups, agencias y producto propio. Criterio, no sólo código. - **Disponibilidad:** Barcelona · remoto global. Español, catalán e inglés (B2). Abierto a proyectos de producto, agencias y equipos de diseño. ## Servicios - **Experience Engineering** (React, Next.js, TypeScript, Motion): Frontend sofisticado donde cada interacción tiene intención. Interfaces que se sienten bien, no sólo que funcionan. - **Producto AI-native** (LLMs, AI UI, Producto, UX): Interfaces para sistemas inteligentes: claras, predecibles y humanas. La IA como comportamiento útil, no como reclamo. - **Design Systems** (Tokens, Componentes, Storybook, Figma): Sistemas de componentes con criterio visual y consistencia a escala. De los tokens a una experiencia coherente. - **Movimiento e interacción** (GSAP, Framer Motion, WebGL, R3F): Animación con propósito: microinteracciones, transiciones y feedback que refuerzan la narrativa del producto. - **Consultoría de producto** (Arquitectura, Auditoría UX, Roadmap): Arquitectura frontend, auditoría UX y hoja de ruta técnica orientada a la experiencia de uso. - **Creative technology** (Generativo, p5.js, Interactivo, Instalación): Código generativo, instalaciones interactivas y piezas computacionales para espacios culturales y digitales. ## Casos de estudio Proyectos contados de principio a fin: el problema, las decisiones que lo resolvieron y lo que salió mal por el camino. ### STORYPRINTS — Un cuento que se imprime y se colorea URL: https://rbt-studio.com/casos/storyprints/ _Ocho respuestas de un padre convertidas en un objeto físico en dos minutos_ · SaaS · B2C · EdTech - **Cliente:** Side project — producto propio de RBT Studio - **Rol:** Producto, diseño y desarrollo full stack (una sola persona) - **Periodo:** Marzo 2026 – en curso - **Stack:** Next.js 15, React 18, TypeScript, Supabase, Claude, OpenRouter, Upstash Redis + BullMQ, pdfkit, Lemon Squeezy - **Enlace:** https://storyprints.rbt-studio.com #### El hueco estaba entre el libro por encargo y la ventana de chat Un libro para colorear de tienda es genérico por definición: el protagonista nunca es tu hija. Las alternativas personalizadas son libros impresos por encargo — caros, con semanas de espera y una sola tirada. En el otro extremo, un chat de IA puede escribirte un cuento, pero devuelve texto en una ventana: no es un libro, no tiene portada, no se imprime, no se colorea, no se queda en la estantería. #### El problema: Tres restricciones que decidieron el diseño técnico El artefacto final es un PDF A4, no una pantalla: todo lo que se genera tiene que sobrevivir a una impresora doméstica. El público son niños de 3 a 12 años, así que contenido que no ha vetado nadie no puede llegar a una página impresa. Y cada libro cuesta dinero real en llamadas a modelos — la economía del producto tenía que estar en el código desde el principio, no como una capa añadida después. #### Cómo se abordó 1. **El wizard: ocho preguntas, no un prompt.** La primera decisión de producto fue no exponer un campo de texto libre. Un padre no quiere escribir un prompt; quiere contestar preguntas con su hija al lado. Nombre, edad, escenario, acompañante, valor, identidad, extensión y estilo narrativo — cada respuesta es una tarjeta. Ese StoryConfig validado es el único contrato que entra en el pipeline: nada aguas abajo vuelve a preguntarle nada al navegador. 2. **Una cola, y un cron que la rescata.** Las generaciones tardan minutos y cuestan dinero, así que van a una cola (BullMQ sobre Upstash Redis) con progreso hacia el navegador. Se drena por dos vías: en proceso justo después de responder, y un cron cada 5 minutos. El cron no es redundancia decorativa — es lo único que hace que una cola atascada se arregle sola. El endpoint falla cerrado si no hay CRON_SECRET, porque cada llamada gasta dinero en modelos. 3. **Las ilustraciones no pueden llevar texto.** Son páginas para colorear: una letra horneada en el bitmap no se quita, y la página se imprime tal cual. El modelo de imagen se llama por chat completion, sin negative prompt, así que todo viaja dentro del texto — la instrucción se repite de tres formas distintas y el diálogo entrecomillado se elimina de la escena antes de que el modelo la vea, porque las comillas son la señal más fuerte para que un modelo dibuje letras. Es mitigación a nivel de prompt, no una garantía, y la documentación lo dice así. 4. **La economía va en el código.** Cada imagen se paga en créditos, y el plan compra una asignación mensual que caduca al cerrar el periodo: una asignación que se acumula no es una asignación. Durante un tiempo el webhook de suscripción escribía el plan y nada más, así que un suscriptor tenía cero créditos y recibía los mismos dibujos genéricos que el plan gratuito. Hoy grantPlanCredits() corre en la creación, la actualización y cada pago mensual — idempotente por descripción, con un índice único en Postgres que lo hace cumplir de verdad. 5. **Dos decisiones de negocio deliberadas.** El plan gratuito entrega un libro completo e imprimible: retener el PDF dejaría al plan gratis sin nada por lo que juzgar el producto — lo que quita la suscripción es la marca de agua. Y el primer cuento de cada usuario lleva ilustración de IA de verdad, sea cual sea su plan; si no, el único libro por el que un visitante juzga el producto se renderiza con seis SVG genéricos, es decir, sin nada de la personalización por la que se le está pidiendo pagar. Un registro cuesta una llamada de imagen: es publicidad barata. wizard → PDF: Wizard · 8 pasos → StoryConfig validado → Cola BullMQ · Redis → Narrative Engine · Claude → Content Safety → Illustration Engine · OpenRouter → Supabase Storage → Lector SVG → PDF A4 bajo demanda #### Solución: Un SaaS completo, de la landing al PDF, construido y operado por una persona Wizard de ocho pasos con subida opcional de una foto del niño, con consentimiento explícito y nunca escrita en la columna config del cuento. Motor narrativo sobre Claude con escenas ajustadas a la edad y extensiones de 6 a 18 páginas derivadas del número de escenas. Motor de ilustración sobre OpenRouter, línea negra sobre blanco y coherente entre escenas. Filtro de contenido aplicado tanto a lo que devuelve el modelo como al único campo libre del producto. Lector web en SVG y exportación a PDF con pdfkit. Cuatro planes leídos desde una única tabla de límites, share card propia, panel de admin y suscripciones con Lemon Squeezy. El PDF no está en el pipeline: se compone bajo demanda desde el cuento ya guardado, para que una generación nunca se bloquee esperando a la maquetación. #### Resultados El producto está construido y desplegado, y aún no está validado en mercado. No hay métricas de usuarios, conversión ni ingresos que reportar, y prefiero no inventarlas. Lo que sí se puede afirmar: el circuito completo funciona en producción, de las ocho respuestas del wizard al PDF descargable, con pagos y suscripciones activas. Los invariantes del negocio están bloqueados por tests, no por disciplina — la tabla de límites y la página de precios no pueden divergir porque hay un test que falla si lo hacen. Y la cola se autocorrige: una generación cuyo disparo en proceso se interrumpe la recoge el cron en los siguientes 5 minutos. Lo que queda por validar es lo importante: si un padre paga 6,99 € al mes por esto. - **376** — tests en 30 suites, todos en verde - **113** — commits en cinco meses de trabajo de una sola persona - **4** — planes leídos desde una única tabla de límites > "Un flag que ninguna ruta lee no es un límite: es un comentario que lo parece." #### Qué se aprendió 1. **Un flag que ninguna ruta lee no es un límite.** La tabla de planes existía mucho antes de que las rutas la consultaran. El bug de los créditos —un suscriptor recibiendo los mismos dibujos que el plan gratis— no fue un error de código: fue una configuración que nadie ejecutaba. Ahora cada límite tiene una ruta que lo lee y un test que lo prueba. 2. **Lo que no se puede quitar después, se impide antes.** Una letra horneada en un bitmap que se va a imprimir no tiene arreglo posterior, así que la mitigación tiene que vivir en el prompt y en el preprocesado de la escena — y documentarse como mitigación, no como garantía. 3. **Sacar el PDF del pipeline fue lo que hizo el sistema robusto.** Componer bajo demanda desde el cuento guardado significa que un fallo de maquetación nunca bloquea una generación ya pagada. Estado: Producto en producción, pendiente de validación en mercado. ### VAMPMAKER — Convertir una demo en un producto cobrable URL: https://rbt-studio.com/casos/vampmaker/ _Un SaaS que prepara la partida de rol antes de que empiece la partida_ · SaaS · Nicho B2C · TRPG - **Cliente:** Side project — RBT Studio - **Rol:** Full Stack / AI Engineer — producto, arquitectura y desarrollo - **Periodo:** Mayo 2026 – en curso (Release 1.0) - **Stack:** TypeScript, NestJS 11, Next.js 16, React 19, Prisma, PostgreSQL · Neon, Zustand, Tailwind 4, OpenRouter, Pollinations.ai #### Dirigir una crónica se parece más a producir una serie que a jugar una partida El Narrador llega al viernes con un arco de cinco sesiones que sostener, una ciudad con su jerarquía política, una docena de NPCs que deben sonar distintos entre sí y fichas que cuadren con la edición que se está jugando. Casi todo ese trabajo ocurre antes de que nadie tire un dado. VampMaker nació para absorber esa preparación, y la primera versión lo hacía bien. El problema era lo que pasaba después. #### El problema: Nada de lo generado sobrevivía al navegador Una auditoría del código en agosto de 2026 dejó el diagnóstico en una frase. El store escribía solo en localStorage, y el CRUD completo del backend NestJS —veinte y pico endpoints, con su esquema de PostgreSQL, sus relaciones y sus borrados en cascada— nunca llegaba a invocarse: saveCampaign() y loadCampaigns() estaban escritas, probadas contra la API y sin una sola llamada desde la interfaz. El resultado era un producto que se presentaba como SaaS —con cuenta, con tiers, con un «Plan Gratuito» en la barra lateral— y que perdía la campaña del usuario al cambiar de dispositivo. El encargo real no era añadir IA: era convertir una demo funcional en un producto cobrable. #### Cómo se abordó 1. **La spec antes que el código.** Con un hallazgo de ese calibre la tentación es abrir el editor y empezar a conectar cables. Escribí primero la especificación: cuatro documentos SDD —SPEC, ARCHITECTURE, SCAFFOLD, AGENTS— que fijan objetivos, no-objetivos y criterios de aceptación verificables antes de tocar una línea. Definir los no-objetivos resultó tan útil como los objetivos: pasarela de pago, colaboración multiusuario, app nativa y export a PDF quedaron fuera de Release 1.0 por escrito, y eso cerró la puerta a tres meses de deriva de alcance. 2. **Ocho agentes con su grafo de dependencias.** Sobre esa spec monté un harness de ocho agentes. El proyecto lo desarrolla una sola persona, así que la división no busca paralelismo humano: busca que cada sesión de trabajo —propia o con un LLM— tenga un alcance cerrado y una definition of done comprobable. 3. **Seis decisiones documentadas como ADR.** El servidor pasa a ser la fuente de verdad y localStorage baja de almacén a caché read-through. Identificadores string (cuid) de extremo a extremo, porque el frontend asumía number y en cuanto Prisma emite cuids el usuario ve «Campaña no encontrada» por un problema que en realidad es de tipos — este ADR bloquea a todos los demás. Lo que no cabe en el esquema va a columnas Json, no a tablas nuevas. Persistencia write-through síncrona por operación: una petición extra es irrelevante frente a los 10–30 segundos de una generación, y a cambio el fallo es atribuible a una acción concreta. Contrato de API estricto con un único envelope de error. Y la cuota como Guard que reserva antes e Interceptor que confirma después, de modo que una generación fallida no consuma saldo. 4. **La capa de IA, tratada como ingeniería y no como conversación.** Conectar OpenRouter son veinte líneas. Lo difícil fue conseguir que el modelo devolviera siempre algo renderizable, en el idioma correcto y sin contradecir el canon de la edición elegida. Idioma: parte del inglés que se colaba no venía del modelo sino de una plantilla del propio código, y la regla explícita separa hoy claves (intactas, las consume el frontend) de valores (en español, con la terminología del juego traducida). Esquema: «devuelve SOLO JSON válido» no es una especificación, así que el prompt lleva ahora el esquema explícito con su ramificación entre ediciones. Canon en capas: núcleo universal, capa por edición y las maldiciones solo de los clanes que aparecen en la petición — antes se inyectaban las quince y se afirmaba que «la Mascarada es ley absoluta» incluso en una campaña de Dark Ages, donde no se declara hasta 1666. harness de 8 agentes: CostProbe → ContractMigrator → PersistenceBuilder → ResilienceBuilder → ExperienceBuilder → QuotaBuilder → DocWriter #### Solución: Monorepo con tres workspaces y un contrato que rompe la compilación, no la producción backend, frontend y shared, donde el paquete compartido contiene los tipos de dominio que ambos extremos consumen. Backend NestJS 11 con módulos por dominio, Prisma sobre PostgreSQL en Neon, JWT en cookie httpOnly y filtro global de excepciones. Frontend Next.js 16 con React 19, App Router, Zustand y una vista de campaña con pestañas: arco, sesiones, NPCs, fichas y mapas. Motor de generación con seis endpoints sobre deepseek-chat vía OpenRouter para texto y Pollinations.ai para imágenes — el prompt de imagen se mantiene deliberadamente en inglés, porque los modelos de difusión rinden peor en español: lo que se traduce es lo que ve el usuario, no lo que consume el generador. Cuatro ediciones soportadas (V5, V20, Dark Ages y Sabbat), cada una con su lore, sus facciones y sus cargos de ciudad. #### Resultados No hay métricas de uso que enseñar: el producto está en fase de Release 1.0 y la persistencia servidor-autoritativa está en curso. Lo que sí hay es criterio acumulado, que es lo que de verdad viaja de un proyecto al siguiente. Release 1.0 cierra persistencia servidor-autoritativa, errores no silenciosos, un único camino de navegación, export a Markdown para llevar el material a la mesa y límite de cuota por cuenta. - **6 ADR** — decisiones estructurales con su alternativa descartada - **~190** — tokens ahorrados por generación al dejar de repetir la regla de idioma seis veces - **4** — ediciones soportadas, cada una con su lore y sus cargos > "Antes de tocar el prompt, averigua quién escribe el texto. Pasé un rato convencido de que el inglés venía del modelo. Una parte venía de una plantilla del propio código." #### Qué se aprendió 1. **Un prompt sin esquema es una API sin contrato.** «Devuelve JSON válido» no es una especificación. Si la interfaz espera quince claves concretas, esas quince claves van en el prompt — y las que consume el código no se traducen aunque el resto del contenido sí. 2. **El contexto que contradice al dominio cuesta más que el contexto que falta.** Inyectar las reglas de la Camarilla en una campaña medieval no es solo desperdiciar tokens: es pedirle activamente al modelo que se equivoque. Trocear el canon por edición mejoró la salida _y_ la abarató. 3. **Un hook con useState no es estado compartido.** Cada componente que llamaba a useAuth tenía su propio user y su propia petición. Como la barra lateral vive en el layout raíz y no se remonta al navegar, el login funcionaba de verdad —cookie emitida, sesión válida— pero la aplicación seguía pintándose como si no. Un error de arquitectura de estado disfrazado de bug de autenticación. 4. **Escribir la spec primero convirtió «arreglar la app» en ocho unidades verificables.** Es la diferencia entre un refactor que no se sabe cuándo termina y ocho bloques con criterio de terminado. Estado: Repositorio y demo pendientes de publicar. ### BRANDAI — El sistema de diseño que viaja contigo URL: https://rbt-studio.com/casos/brandai/ _Identidad de marca portable entre herramientas de IA_ · SaaS · B2C · Freelancers & Creators - **Cliente:** Side project — RBT Studio - **Rol:** Product design · Full-stack · Arquitectura multi-agente · Prompt engineering - **Periodo:** Producto propio - **Stack:** Next.js, Supabase, OpenRouter, Upstash Redis, Multi-agent, Markdown #### Contexto El problema de coherencia visual en proyectos pequeños no es de talento — es de memoria. Cada vez que usas un LLM para generar algo para tu marca, empiezas desde cero. BrandAI orquesta cinco agentes especializados para generar un design.md completo: paleta, tipografía, tono verbal, espaciado, tokens. Un archivo Markdown que viaja contigo a cualquier LLM, Cursor o pipeline. #### El problema: Los LLMs no recuerdan quién eres Un design system completo en Figma o Notion es inaccesible para proyectos pequeños en tiempo y dinero. Pero sin contexto de marca, cada generación de IA produce algo inconsistente con lo anterior. El resultado es una identidad visual que se fragmenta con cada herramienta que usas. orchestration pipeline — 5 agents: Input lenguaje natural → Orquestador → Agente Paleta → Agente Tipografía → Agente Tono verbal → Redis · caché por hash → Validador de consistencia → Ensamblado design.md → Supabase · v+1 #### Solución: Un artefacto portable generado por agentes especializados Cinco agentes en pipeline — orquestador, paleta, tipografía, tono verbal, validador de consistencia — generan un design.md completo en 60–90 segundos. El validador detecta inconsistencias entre capas y relanza los agentes afectados. El resultado viaja al IDE, al chat, al prompt del generador de imagen. #### Decisiones de producto - **mi rol:** Product design · Full-stack · Arquitectura multi-agente · Prompt engineering - **usuarios:** **Fundadoras wellness** — sin presupuesto de diseño **Freelancers** — coherencia entre clientes **Content creators** — múltiples marcas propias - **decisión de producto clave:** Markdown como formato de salida. No Figma, no Notion, no JSON. El archivo más portable del ecosistema digital — funciona en cualquier editor, cualquier LLM, cualquier CI/CD. - **decisión de IA clave:** Modelo distinto por agente: haiku para paleta y tipografía, sonnet para orquestador y validador, gpt-4o-mini para tono verbal. ~30% reducción de coste con caché Redis por hash semántico. - **60–90s** — generación design.md completo - **~30%** — reducción de coste vía caché Redis - **40%** — retorno para modo evolución en 30 días > "La decisión más importante del producto no fue técnica — fue de formato. Markdown es el artefacto más portable del ecosistema digital." #### Qué se aprendió 1. **El validador de consistencia es el agente más caro y el más valioso.** Sin él, el orquestador ensambla secciones que se contradicen — paleta fría con tono "cálido y terroso". Con él, la satisfacción media sube 0.8 puntos sobre 5. 2. **El modo evolución retiene más que el modo generación.** Con el design.md versionado en Supabase, el coste de cambiar de herramienta es alto. Cada actualización de marca que vuelve a BrandAI es un ciclo de retención natural. 3. **Diferentes modelos por agente vía OpenRouter fue decisivo.** GPT-4o-mini superó a Claude Haiku en tono verbal para marcas wellness en inglés. Un cambio de una línea en el config, sin refactor. ### RBT.STUDIO — El portfolio como declaración de intenciones URL: https://rbt-studio.com/casos/rbt-studio/ _Cuando el producto eres tú mismo_ · Portfolio · Identidad digital · Creative Dev - **Cliente:** Producto propio — rbt-studio.com - **Rol:** Diseño, desarrollo y dirección de arte - **Periodo:** En curso - **Stack:** React, Vite, Canvas API, GSAP, Generative art, Tailwind #### Contexto Un portfolio no es un CV con CSS. Es el argumento más completo que puedes hacer sobre quién eres como profesional. El rbt.studio fue diseñado desde el fondo de las artes visuales — un background de Bellas Artes que informa cada decisión técnica. Particle field en el hero, canvas Lissajous generativo, paleta dark con acentos en oro y sage. El código es el diseño. #### El problema: Posicionarse en la intersección de AI engineer y creative dev Un portfolio estándar de developer no comunica la dimensión creativa. Un portfolio de diseñador no comunica la profundidad técnica. El perfil de Ricard vive exactamente en esa intersección — y el portfolio tiene que demostrarlo sin explicarlo. Si tienes que explicar que eres creativo, ya has perdido. capas del sistema visual: Identidad — dark / teal / cream → DM Sans + JetBrains Mono → Particle field hero — Canvas 2D → Lissajous canvas — paramétrico → Casos de trabajo — grid editorial → Stack (AI · Frontend · Systems) #### Solución: El propio código como pieza de portfolio El generative canvas no es decoración — es la primera prueba de que el autor entiende sistemas visuales complejos. La particle field del hero responde al cursor con física de atracción. El canvas Lissajous dibuja figuras de Bowditch en tiempo real. Un recruiter técnico lo abre en DevTools y ve el código. Un recruiter de diseño ve el resultado. #### Decisiones de producto - **mi rol:** Diseño de identidad · Frontend · Generative art · Motion - **contexto:** 10+ años de experiencia full stack. Background en Bellas Artes (Universitat de Barcelona). El portfolio tiene que mostrar los dos mundos a la vez — técnico y creativo. - **decisión estética clave:** Paleta dark/cream con teal como acento primario. Sin colores de marca genéricos. Tipografía DM Sans para display — sans que cruza lo editorial con lo técnico. - **diferenciador técnico:** Canvas Lissajous generativo — figura paramétrica que varía en tiempo real. Particle field en el hero con física de atracción. Todo renderizado en Canvas 2D sin librerías externas. - **10+** — años de experiencia condensados en una sola página - **0** — librerías externas para los efectos generativos - **2** — perfiles en uno — AI engineer y creative technologist > "Technical depth from 10+ years of full stack engineering. Creative precision from a fine arts background. The intersection is where I work." #### Qué se aprendió 1. **El portfolio es el argumento, no el resumen.** No lista proyectos — demuestra un punto de vista. La particle field no es decoración, es la primera frase del argumento: este developer entiende sistemas visuales en tiempo real. 2. **Canvas 2D sin dependencias externas es una decisión deliberada.** Three.js habría sido más rápido. La elección de implementar la física de partículas y las curvas de Lissajous desde cero demuestra comprensión matemática del sistema. 3. **La paleta dark/cream comunica antes de que se lea una palabra.** Los portfolios de developers suelen ser blancos con azul. El contraste de este sistema visual señala desde el primer segundo que el autor tiene criterio estético propio. ### AIMPLAS — Un prototipo que se explica solo URL: https://rbt-studio.com/casos/aimplas/ _App 3D para tablets que acompaña a un casco y un patinete reales_ · App móvil · 3D interactivo · I+D industrial - **Cliente:** Aimplas — Instituto Tecnológico del Plástico - **Rol:** Desarrollo de app móvil e integración 3D - **Periodo:** Proyecto de cliente - **Stack:** React Native, Expo.dev, Three.js, Headless CMS, API REST #### Contexto Aimplas desarrolló, junto a Stimulo Design Studio, un prototipo físico de casco y patinete que concentra varias innovaciones en materiales. El problema de un prototipo así es que sus avances no se ven: están dentro del material. La app para tablets es la capa que los hace visibles — un acompañante que se usa delante del objeto real, en ferias y demostraciones, para desplegar lo que el ojo no alcanza. #### El problema: La innovación estaba dentro del material, no a la vista Un casco y un patinete de nueva generación parecen, a simple vista, un casco y un patinete. Las innovaciones son de composición, proceso y estructura. Había que explicarlas a públicos muy distintos — desde un visitante casual hasta un ingeniero de materiales — sin convertir la app en un manual técnico ni en un folleto vacío. content → tablet pipeline: CMS headless → API REST → App Expo / React Native → Navegación por perfil → Modelo 3D interactivo → Grid de detalles → Listado de innovaciones #### Solución: Tres formatos de lectura sobre el mismo contenido La navegación se personaliza según el tipo de usuario y ofrece el mismo contenido en tres profundidades: elementos 3D interactivos para explorar el objeto, una retícula de imágenes de detalle para una lectura rápida, y un listado completo de innovaciones para quien quiere el dato. Cada perfil entra por donde le interesa y baja al nivel que quiere. #### Decisiones de producto - **mi rol:** UX/UI · Desarrollo frontend · Integración de API con CMS headless - **contexto:** Proyecto para Aimplas en colaboración con Stimulo Design Studio. La app complementa un prototipo físico real de casco y patinete. - **usuarios:** **Visitantes de feria** — recorrido rápido y visual **Perfiles técnicos** — listado completo de innovaciones **Equipo comercial** — demo guiada sobre el objeto físico - **decisión técnica clave:** Todo el contenido vive en un CMS externo consumido por API. Actualizar textos, imágenes o innovaciones no requiere recompilar ni reinstalar la app en las tablets. - **3** — formatos de contenido sobre la misma información - **0** — reinstalaciones necesarias para actualizar contenido - **1** — app que acompaña al prototipo físico en demostraciones > "La app no sustituye al prototipo — lo acompaña. El objeto está en la mesa; la tablet enseña lo que hay dentro del material." #### Qué se aprendió 1. **El contenido desacoplado es un requisito, no una comodidad.** Una app de feria se actualiza el día antes del evento. Con CMS headless por API, el cambio es de contenido; con contenido hardcodeado, es un ciclo de build y despliegue en cada tablet. 2. **El 3D es la puerta de entrada, no el destino.** El modelo interactivo atrae y orienta, pero quien busca el dato técnico necesita una lista. Sostener ambos formatos sobre la misma fuente de contenido evita duplicar el trabajo editorial. 3. **Expo redujo la fricción de distribución en un parque de tablets.** Actualizar la app en varios dispositivos de demostración es una tarea logística — no técnica — y conviene resolverla desde la elección de stack. ### D-GO — Datos técnicos que se leen como relato URL: https://rbt-studio.com/casos/d-go/ _Web para D-Go, un motor direct-drive para bicicletas de carga_ · Web de producto · 3D · Movilidad eléctrica - **Cliente:** D-Go - **Rol:** Desarrollo web y dirección técnica 3D - **Periodo:** Proyecto de cliente - **Stack:** Frontend development, 3D graphics, Scroll-driven animation, Diseño UX/UI #### Contexto D-Go es un motor eléctrico premium para bicicletas de carga. Su valor está en la ingeniería: par, integración, transmisión directa. Todo lo que lo hace bueno es difícil de contar. La web se desarrolló con el equipo de marketing de Stimulo Design Studio para resolver exactamente eso — presentar información técnica compleja de forma clara y visual, sin diluirla. #### El problema: La ficha técnica no vende ingeniería Presentar datos técnicos complejos de forma clara y visual es el reto central del proyecto. Una tabla de especificaciones es precisa y no comunica nada; un texto comercial comunica y pierde la precisión que justifica el precio de un producto premium. scroll → narrativa técnica: Assets 3D del motor → Guion técnico por secciones → Scroll del usuario → Sincronización de narrativas → Render 3D por tramo → Capas de dato técnico → CTA de producto #### Solución: Gráficos 3D sincronizados con el scroll Se crearon gráficos 3D y se sincronizaron varias narrativas con el desplazamiento del usuario. Al ceder el control del tempo al visitante, el contenido técnico deja de ser una imposición y se convierte en exploración — con un engagement notablemente más positivo hacia información que, en formato estático, se abandona. #### Decisiones de producto - **mi rol:** UX/UI · Desarrollo frontend · Desarrollo integral del sitio - **contexto:** Proyecto desarrollado en colaboración con el equipo de marketing de Stimulo Design Studio. Sitio público de producto — d-go.eu - **decisión de diseño clave:** Sincronizar varias narrativas con el scroll del usuario. El visitante controla el tempo del relato técnico: avanza cuando ha entendido, se detiene cuando quiere mirar. - **reto de comunicación:** Un motor direct-drive se explica con conceptos poco intuitivos. Los gráficos 3D permiten enseñar el mecanismo en lugar de describirlo. - **3D** — gráficos propios para explicar el mecanismo - **1:1** — scroll y narrativa sincronizados — el tempo lo marca el usuario - **d-go.eu** — sitio público de producto en producción > "Cuando el usuario controla el tempo del relato, la información técnica deja de ser un obstáculo y pasa a ser el motivo por el que se queda." #### Qué se aprendió 1. **Ceder el control del tempo cambia la relación con el contenido denso.** Un vídeo autoplay impone un ritmo; el scroll lo negocia. En producto técnico, esa diferencia decide si el visitante llega al final de la página. 2. **El 3D enseña el mecanismo; el texto solo lo describe.** Un motor de transmisión directa se entiende viéndolo funcionar. La animación no es adorno — es la explicación. 3. **Trabajar con el equipo de marketing desde el inicio evita rehacer.** El guion narrativo y la implementación técnica se diseñaron a la vez; la estructura de scroll es la estructura del mensaje. ### THE SMART LOLLIPOP — Cómo cuenta su producto una startup URL: https://rbt-studio.com/casos/the-smart-lollipop/ _Landing para The Smart Lollipop, un dispositivo de salud infantil_ · Landing de producto · Startup · 3D + GSAP - **Cliente:** The Smart Lollipop - **Rol:** Desarrollo web · 3D · GSAP - **Periodo:** Proyecto de cliente - **Stack:** Frontend development, 3D graphics, GSAP, Plantillas a medida, UX/UI #### Contexto The Smart Lollipop es una startup con un producto que no se parece a nada previo — y por tanto sin un lenguaje visual heredado del que tirar. El proyecto se desarrolló en estrecha colaboración con Stimulo Design Agency, combinando creatividad y tecnología: ayudar a una startup a definir cómo presentar su producto y comunicar su valor es siempre un reto estimulante. #### El problema: Una startup sin lenguaje propio todavía Antes de construir la web había que resolver algo anterior: cómo presenta este producto lo que hace y por qué importa. Sin referentes directos de categoría, cada decisión visual y narrativa define el posicionamiento — y una startup no puede permitirse una web que envejezca en seis meses. scroll → narrativa emocional: Definición del mensaje → Guion por secciones → Gráficos 3D animados → GSAP · scroll sync → Plantillas a medida → Gestión de contenido #### Solución: Narrativa 3D con el tempo en manos del usuario Se integraron gráficos animados en 3D para crear narrativas sincronizadas con el scroll del navegador: el usuario marca el ritmo del relato y desarrolla empatía con el producto. En paralelo, un sistema de plantillas a medida permite al equipo actualizar contenido con facilidad sin romper la coherencia del diseño. #### Decisiones de producto - **mi rol:** Comunicación · UX/UI · Desarrollo frontend · Animaciones 3D y GSAP - **contexto:** Proyecto en colaboración con Stimulo Design Agency para una startup en fase temprana. Sitio público — thesmartlollipop.com - **decisión de diseño clave:** Narrativas 3D sincronizadas con el scroll del navegador. El usuario controla el ritmo de la historia, lo que facilita la conexión emocional con el producto. - **decisión de producto clave:** Plantillas a medida para gestionar el contenido con flexibilidad sin comprometer la integridad visual y estructural del diseño. - **3D** — gráficos animados sincronizados con el scroll - **∞** — actualizaciones de contenido sin tocar el diseño - **1** — lenguaje visual definido desde cero con la startup > "Ayudar a una startup a definir cómo presenta su producto y comunica su valor es siempre un reto estimulante." #### Qué se aprendió 1. **En una startup, la web se diseña después del mensaje.** Empezar por la interfaz sin haber definido qué se comunica produce un sitio bonito que no posiciona nada. 2. **Las plantillas a medida son el equilibrio entre libertad y coherencia.** Un editor totalmente libre degrada el diseño en semanas; uno cerrado obliga a llamar al desarrollador por cada cambio. Las plantillas acotan la libertad al espacio donde no rompe nada. 3. **La empatía con el producto se construye con ritmo, no con adjetivos.** Sincronizar la animación con el scroll deja que el usuario descubra a su velocidad — y lo descubierto convence más que lo afirmado. ### EONIA — Una app que no recomienda: decide URL: https://rbt-studio.com/casos/eonia/ _La capa de decisión biológica que faltaba entre medir e intervenir_ · Producto propio · Salud · Local-first + IA - **Cliente:** Producto propio de RBT Studio - **Rol:** Producto, diseño de sistema y desarrollo full-stack + IA — autor único - **Periodo:** Junio 2026 → en curso (MVP v1.0 + incremento servidor v1.5) - **Stack:** TypeScript, React Native · Expo, Skia + Reanimated, NestJS, PostgreSQL · pgvector, LangGraph + Claude, Render · EAS #### Contexto El usuario de alto rendimiento tiene más datos biológicos que ninguna generación anterior — y sigue tomando los mismos suplementos cada mañana, dé igual cómo esté hoy. El mercado resolvió la medición (Oura, WHOOP) y la intervención (suplementación basada en evidencia), y dejó el centro vacío: la decisión. Un sistema que recomienda traslada la carga cognitiva al usuario; uno que decide la absorbe. EONIA convierte un check-in de 30 segundos en un estado biológico calculado y una arquitectura de cápsulas adaptada a ese estado, en el dispositivo. #### El problema: El hueco está en la decisión, no en el dato Medición e intervención están bien resueltas por el mercado; entre ambas no hay nada. La diferencia no es incremental sino estructural: el usuario de EONIA no necesita entender el eje HPA para beneficiarse de él. Cada pantalla responde a una sola pregunta — qué tengo que hacer ahora mismo — sin gráficas y sin jerga por delante. #### Cómo se abordó 1. **Especificar antes de programar, y decidir por escrito.** El proyecto arrancó con un set documental completo (SPEC · ARCHITECTURE · SCAFFOLD · DESIGN · HANDOFF) antes de la primera línea de producto, y cada decisión estructural quedó fijada como un ADR con su alternativa descartada. No es burocracia: en un producto que toca salud, la trazabilidad de por qué el sistema decide lo que decide es parte del producto. 2. **El motor de decisión es puro y determinista.** @eonia/engine no tiene I/O, ni React, ni red, ni modelo de lenguaje. Entra un check-in, sale un estado y una arquitectura. Es el único sitio donde se decide. Consecuencia deliberada: el mismo paquete corre en el dispositivo y en el servidor y produce exactamente el mismo veredicto — lo que hace que el modo offline no sea una versión degradada, sino el mismo sistema. 3. **El Orb es una entidad, no una gráfica.** La visualización central (Skia + Reanimated, trazo de pincel sumi-e) tiene que comunicar el estado biológico pre-cognitivamente: en menos de un segundo, sin leer ni interpretar. Un donut chart habría sido más barato y habría fallado en el único requisito que importaba. Las tres capas de información —qué hacer, por qué, y el mecanismo fisiológico— son un límite arquitectónico impuesto en el código, no una convención de diseño. 4. **Dónde entra la IA.** La capa narrativa genera el informe personalizado con LangGraph y Claude, pero bajo una restricción dura: el motor decide, el LLM solo explica. El nodo de preparación es código puro —normalización, aritmética de tendencias, resolución de etiquetas— y el modelo recibe un contexto grounded del que no puede salir. Tres especialistas analizan en paralelo, un nodo sintetiza y una puerta de seguridad decide entre entregar o escalar. Una alucinación en el nodo de normalización se habría propagado a todas las ramas; por eso ese nodo no es una llamada al modelo. 5. **El catálogo clínico tenía que salir del código.** Las fórmulas vivían como constantes en el motor, lo que implicaba que actualizar un protocolo era un despliegue. Se movieron a base de datos y se construyó una consola de back-office con tres roles no jerárquicos: admin, specialist y provider. Editar el catálogo invalida la firma clínica y sube la versión, y la clave de caché de los informes incluye esa versión. Es la única vía por la que un farmacéutico —no un commit— puede firmar un protocolo. 6. **Un incidente que merece estar en el case study.** Con la beta ya en manos de testers, todos los usuarios quedaron bloqueados tras verificar su email. La causa: force_organization_selection activado en el proveedor de identidad. Cada sesión recibía una tarea de «elegir organización» que un usuario B2C nunca puede satisfacer, la sesión se quedaba pending, el cliente la contaba igualmente y el modo de sesión única rechazaba cualquier login nuevo. Se arregló en dos frentes: la configuración y el cliente, porque una app en producción no puede depender de que la consola de un tercero esté bien configurada. check-in → protocolo: Check-in · 5 dimensiones → Baseline individual → @eonia/engine · puro → 6 estados biológicos → Histéresis 3 días → 6 arquitecturas · circadiano → LangGraph · narrativa grounded → Gate de seguridad → Sync opcional · Postgres #### Solución: Un bucle cerrado de señal, decisión y ejecución Check-in de 5 dimensiones en ~30 segundos → EONIA Score contra tu baseline personal → uno de 6 estados biológicos → una de 6 arquitecturas de cápsulas con ventanas circadianas por compuesto. La arquitectura solo cambia tras 3 días coherentes seguidos: histéresis deliberada contra la oscilación por ruido. El catálogo clínico vive en base de datos con firma profesional y versionado, no en el código. #### Decisiones de producto - **mi rol:** Producto, diseño de sistema y desarrollo full-stack + IA — autor único - **arquitectura clave:** **Motor puro y determinista** — sin I/O, sin red, sin modelo de lenguaje. El mismo paquete corre en dispositivo y servidor y produce el mismo veredicto: el modo offline no es una versión degradada. - **decisión de IA clave:** El motor decide, el LLM solo explica. La capa narrativa recibe un contexto grounded del que no puede salir — no deriva un estado, ni una arquitectura, ni un número propio. - **estado:** MVP v1.0 desplegado (Render + APK vía EAS) e incremento de servidor v1.5 en producción. Beta cerrada. #### Resultados Sin métricas de usuarios todavía — la beta es cerrada y no se han publicado cifras. Lo que sí es verificable: MVP v1.0 completo y desplegado, con backend dockerizado en Render vía Blueprint y APK Android distribuida a testers vía EAS. Incremento de servidor v1.5 en producción, con sync opcional autenticado, informes narrativos y consola de back-office con control de acceso por rol. Y un catálogo clínico editable con firma: los protocolos ya no son código, y la firma clínica es un estado del dato que solo un profesional puede establecer. - **35** — tests sobre el núcleo de decisión, con integración multi-día - **5** — workspaces con frontera clara: engine, mobile, backend, admin, narrative - **46** — commits desde el kickoff, con el set SDD sincronizado con el código > "Poner el LLM en el sitio equivocado es fácil y caro. Restringirlo a explicar una decisión ya tomada por código verificable es lo que hace el sistema auditable — y lo que permite que el modo offline no pierda nada esencial." #### Qué se aprendió 1. **El ADR que más valor dio no fue técnico.** Reconciliar un backend multitenant heredado con un producto B2C no resolvió un problema de código: resolvió si el producto era B2C o B2B2C, e impidió que el backend arrastrase el producto. 2. **Lo que un profesional deba poder cambiar no puede vivir en el código.** Mover el catálogo clínico a base de datos con firma y versionado convirtió una app en un sistema operable — un farmacéutico firma un protocolo, no un commit. 3. **La configuración de un tercero es superficie de producción.** Un flag mal puesto en el proveedor de identidad bloqueó al 100% de los testers tras verificar el email. Se arregló en la configuración _y_ en el cliente: una app en producción no puede depender de que la consola de un tercero esté bien. Estado: Demo y beta bajo petición. ### EL ÚLTIMO ZARPE — Lo único que sobrevive al bucle es lo que entiendes URL: https://rbt-studio.com/casos/el-ultimo-zarpe/ _Un roguelike sin meta-progresión, donde solo se acumula comprensión_ · Videojuego propio · Roguelike de preparación - **Cliente:** Side project — juego propio - **Rol:** Diseño de juego, desarrollo y dirección de arte - **Periodo:** Julio 2026 – en curso - **Stack:** Godot 4.7, GDScript, JSON como capa de reglas, Prototipo HTML/SVG como oráculo, Dirección de arte #### Contexto El roguelike moderno enseña a memorizar builds: mueres, ganas monedas permanentes, vuelves más fuerte. La dificultad no la resuelve el jugador, la erosiona el desbloqueo. El Último Zarpe hace lo contrario — sin monedas persistentes, sin árbol de mejoras. Un puerto llamado Grisal, unos días contados, un barco que zarpa con o sin ti. Preparas el viaje con dinero limitado, información contradictoria y una bodega que no da para todo. Normalmente mueres. Lo que aprendes al morir es todo lo que te llevas. #### El problema: Un juego que mata constantemente tiene un margen de error muy estrecho Si una muerte se siente arbitraria, el jugador no aprende: se va. Además, una medición incómoda tras el port reveló que el juego supuestamente rejugable tenía solo 6 puzzles posibles en modo largo — memorizable en una tarde. Tres parámetros de dificultad no hacían absolutamente nada. #### Cómo se abordó 1. **El problema real no era el bucle, era la injusticia.** Un juego que mata al jugador constantemente tiene un margen de error muy estrecho: si una muerte se siente arbitraria, el jugador no aprende, se va. La primera decisión de diseño no fue de contenido sino de contrato — nunca mentir al jugador sobre las reglas; sí sobre los hechos. Y «justo» aquí no es una promesa de intenciones: cada viaje generado se demuestra soluble antes de dejarte empezar. Un verificador prueba por fuerza bruta que existe al menos una combinación de compras que sobrevive, con margen económico. Si no la encuentra, ese viaje no llega al jugador. 2. **Reintentar es el mismo puzzle, no uno nuevo.** La decisión más contraintuitiva del proyecto: volver a Grisal repite la misma semilla a propósito. La tentación de un roguelike es dar una partida nueva tras cada muerte, pero eso convierte el fracaso en ruido — si el próximo viaje es otro, lo que aprendiste sobre este no vale nada. Repitiendo la semilla, el segundo intento es el mismo enemigo con más luz: el jugador vuelve al puerto sabiendo que el agua se acaba el día 3, y esta vez gasta sus preguntas en otra cosa. 3. **El prototipo primero, en HTML.** Antes de tocar Godot construí el juego entero como una página HTML con SVG y JS —jugable de principio a fin— para poder discutir el diseño jugándolo en vez de imaginándolo. Cuando la mecánica quedó clara, ese prototipo pasó a ser algo más útil que documentación: la especificación ejecutable del port. El motor de Godot no se consideró correcto hasta que generaba exactamente el mismo viaje que el prototipo para la misma semilla. 4. **Se midió que el juego aburría, y se arregló con números.** Tras el port, una medición incómoda: en modo largo solo existían 6 puzzles posibles, y tres parámetros de dificultad no hacían nada en absoluto. El juego que en teoría era infinitamente rejugable era, en la práctica, memorizable en una tarde. La respuesta fue ampliar el repertorio —de 6 a 12 peligros, de 13 a 18 objetos— y, sobre todo, sacar las reglas del código y meterlas en datos. Hoy la dificultad vive en un JSON que se tunea entre partidas de playtest sin recompilar. 5. **El mapa del puerto también es una variable.** El puerto tiene once lugares y no abren todos cada partida: la misma semilla que genera el viaje sortea cuáles están abiertos hoy, así que la ruta óptima deja de ser memorizable. Dos salvaguardas evitan que la rotación degenere en frustración. Hay un suelo de información —si el sorteo deja el puerto demasiado pobre, se abren lugares extra— y una regla más dura, aprendida a base de romperla: lo que apaga una mecánica no rota. Al principio el callejón, donde vive el único informador capaz de señalar que una pista es falsa, entraba en el sorteo. Costó variedad (de 126 mapas posibles a 56) y valió la pena. semilla → travesía: Semilla + dureza + longitud → Generación del viaje → Verificador de solubilidad → Rotación de lugares del puerto → Suelo de información → Preparación · acciones del día → Travesía en cascada → Bitácora · qué te mató #### Solución: Solubilidad demostrada y reglas fuera del código Un verificador prueba por fuerza bruta que cada viaje generado tiene al menos una combinación de compras que sobrevive con margen económico; si no la encuentra, ese viaje no llega al jugador. El repertorio pasó de 6 a 12 peligros y de 13 a 18 objetos, y la dificultad vive hoy en un JSON que se tunea entre partidas de playtest sin recompilar. #### Decisiones de producto - **mi rol:** Diseño de juego, desarrollo y dirección de arte - **el contrato con el jugador:** **Nunca mentir sobre las reglas; sí sobre los hechos.** Las pistas pueden ser falsas y la gente miente en la taberna, pero el sistema es justo — y eso se demuestra, no se promete. - **decisión más contraintuitiva:** Volver a Grisal repite la misma semilla a propósito. Si el próximo viaje fuera otro, lo aprendido sobre este no valdría nada. El segundo intento es el mismo enemigo con más luz. - **estado:** Jugable de principio a fin. Ejecutable autocontenido de Windows, verificado en directorio limpio. Sin tienda ni fecha. #### Resultados El juego es jugable de principio a fin y se distribuye como ejecutable autocontenido de Windows, verificado en un directorio limpio. Todo lo medible hoy es de sistema, no de jugadores: aún no hay playtests externos, ni métricas de retención, ni tienda, ni fecha. Cualquier cifra de aquí habla de la solidez del sistema, no de que a alguien le haya gustado. Ese es el siguiente paso, no un resultado ya conseguido. - **405/405** — combinaciones con paridad exacta contra el prototipo, en dos oráculos - **792** — puzzles posibles en modo largo — eran 6 - **56** — mapas de puerto distintos por rotación de lugares > "Lo que rota son voces, nunca mecánicas. En ~44% de las partidas el jugador perdía la capacidad de detectar mentiras sin que nada se lo dijera: exactamente el tipo de dificultad de la que no se puede aprender." #### Qué se aprendió 1. **Medir la variedad antes de creértela.** El juego infinitamente rejugable tenía seis puzzles. No lo detectó una intuición de diseño: lo detectó contar. Si un sistema generativo no se instrumenta, se asume que funciona porque es generativo. 2. **Un prototipo jugable vale más como oráculo que como documento.** Escribir el juego dos veces — primero en HTML para jugarlo, después en el motor — dio una definición de correcto que no admite opinión: mismo resultado para la misma semilla, o el port está mal. 3. **Lo que falta, y lo sé.** Los días de preparación siguen siendo decorativos, el agua obligatoria convierte una compra en un no-trámite, y casi nunca queda un peligro sin pista honesta — que es justo lo que daría sentido pleno a la bitácora entre bucles. Estado: En desarrollo. Build de Windows funcional; sin tienda ni fecha todavía. ### FOTOGRAFÍA · DIRECCIÓN DE ARTE — Un método, ocho años URL: https://rbt-studio.com/casos/fotografia-direccion-de-arte/ _Una gramática visual, no un estilo — del negativo de medio formato al libro impreso_ · Dirección de arte · 2013–2021 · 3 libros · 1 campaña - **Cliente:** Trabajo propio y de encargo - **Rol:** Dirección de arte, fotografía, edición y maquetación de los tres libros - **Periodo:** 2013 – 2021 - **Stack:** 35 mm, 120 · medio formato, Digital, InDesign, Lightroom Book, Dirección de arte de campaña #### Contexto Un estilo se reconoce por el acabado: un color, un grano, un filtro. Lo que hay aquí es otra cosa — una manera de resolver el encuadre que funciona igual con una cámara de medio formato en un estudio a oscuras que con una digital a pleno sol en un cráter volcánico. Aislar una forma contra un fondo que calla. Dejar entrar un solo color saturado. Pensar en cuadrado. Y quedarse con el accidente únicamente cuando ordena la imagen. El sujeto cambia, el continente cambia, la cámara cambia; la operación es siempre la misma. #### El problema: Un estilo no sobrevive al cambio de sujeto, de medio y de país Ocho años de trabajo repartidos entre estudio, película, campaña y libro corren el riesgo de leerse como cuatro portfolios distintos. La pregunta no era cuál es mi estilo, sino qué decisión se toma antes de saber qué se está fotografiando — porque solo eso aguanta el cambio de contexto. #### Cómo se abordó 1. **01 · Una forma contra un campo plano.** La decisión más constante, y la más invisible: aislar un objeto y darle un fondo sin información. Cielo, negro, un muro blanco, la lámina de mar. El fondo no es lo que había detrás — es lo que se eligió para que no hubiera nada detrás. Cuando el trabajo llega al papel, el campo plano deja de ser el cielo y pasa a ser el propio margen de la página: en Geometrías la imagen nunca sangra, flota dentro del blanco, que hace exactamente el trabajo que hacía el cielo. 2. **02 · Un solo acento saturado.** Nunca hay dos colores peleando. Hay un campo desaturado —gris, beige, negro, la niebla— y exactamente una cosa roja dentro. El rojo entra siempre solo, y siempre es él quien organiza el encuadre: fija dónde empieza la mirada y obliga a todo lo demás a ceder saturación. Da igual la superficie: una capucha que ocupa media imagen o un bordado de dos centímetros funcionan por la misma razón. 3. **03 · El cuadrado como unidad de pensamiento.** El cuadrado empieza siendo una imposición del negativo de medio formato, pero no se queda ahí: sobrevive al escaneo, a la maquetación y llega hasta la imprenta. Dos de los tres libros son cuadrados —21 × 21 y 17,5 × 17,5— sin que ninguna cámara obligara a ello. El cuadrado obliga a componer por peso y no por dirección: no hay un lado largo que empuje la mirada, así que el sujeto tiene que sostenerse por sí mismo. 4. **04 · Control y accidente, en la misma mesa.** Por un lado, estudio: flash, fondo negro, objetos congelados en el aire. Por otro, película: velos, dobles exposiciones, fugas de luz. Lo interesante no es que convivan, sino el criterio para quedarse con el accidente — el error se conserva cuando refuerza las reglas 01 y 02; si las estorba, el fotograma se descarta. La doble exposición no estaba prevista: se queda porque el solape borra el fondo y deja las figuras flotando, es decir, porque el accidente fabricó la regla 01 por su cuenta. 5. **El sistema en papel — tres libros, tres páginas incompatibles.** Los libros son donde el método se pone a prueba de verdad, porque una secuencia no perdona. Geometrías: forma pura, imagen contenida en margen ancho. USA: territorio y carretera, la imagen sangra y alterna una página a sangre contra otra flotando para que la lectura tenga pulso. Sillas: pares a contacto, sin margen y sin folio. No es una plantilla aplicada tres veces — es el mismo criterio produciendo tres respuestas distintas porque el sujeto es distinto. El formato sigue al sujeto. del encuadre a la página: Decidir qué queda fuera → Fondo que calla → Un acento saturado → Marco cuadrado → Disparo · control o accidente → Criterio de descarte → Secuencia → Borde de página según sujeto #### Solución: Cuatro operaciones que se aplican antes del sujeto El fondo no es lo que había detrás: es lo que se eligió para que no hubiera nada detrás. Nunca hay dos colores peleando — hay un campo desaturado y exactamente una cosa roja dentro. El cuadrado sobrevive al escaneo, a la maquetación y a la imprenta. Y el accidente se conserva solo cuando refuerza las dos primeras reglas; si las estorba, el fotograma se descarta. #### Decisiones de producto - **mi rol:** Dirección de arte, fotografía, edición y maquetación de los tres libros - **las cuatro reglas:** **01** Una forma contra un campo plano **02** Un solo acento saturado **03** El cuadrado como unidad de pensamiento **04** Control y accidente en la misma mesa - **aplicación:** Tenerife, abril 2019 — dos días en el cráter del Teide. La localización se elige por el fondo, la ropa por el color, y el plano se decide antes de que la modelo se siente. - **el sistema en papel:** Geometrías (21 × 21, imagen que nunca sangra), USA (24,4 × 21, sangre alterna con flotante) y Sillas (17,5 × 17,5, pares a contacto sin margen ni folio). #### Resultados Ocho años de trabajo que se sostienen como un cuerpo y no como cuatro portfolios sueltos, con tres libros maquetados y una campaña producida de principio a fin. El resultado no es un estilo reconocible por el acabado, sino una gramática que aguanta el cambio de sujeto, de medio y de país — y que incluye saber cuándo suspenderse: en Sillas la primera regla se desactiva a propósito, porque el fondo es quien nombra al ausente. - **8 años** — 2013–2021 · 35 mm, 120 y digital - **3 libros** — tres soluciones de página incompatibles, y las tres correctas - **4 reglas** — aplicadas antes de saber qué se está fotografiando > "Sillas no va de sillas: va de ausencia. Ahí la regla 01 se suspende, y se suspende por una razón que se puede enunciar — el fondo no se puede aplanar porque el fondo es quien nombra al ausente." #### Qué se aprendió 1. **El formato sigue al sujeto.** Una forma cerrada pide un marco cerrado; un territorio sin bordes pide una página sin bordes; una ausencia pide que las imágenes se toquen. La regla no es usa márgenes ni usa sangre — es que el borde de la página diga lo mismo que la imagen. 2. **Casi todo el trabajo está en la resta.** El fondo que se aparta, el color que no entra, el lado largo que se recorta. Decidir antes de disparar qué se queda fuera del encuadre. 3. **Una gramática sirve cuando también sabes romperla y decir por qué.** Saber cuándo no aislar es la misma decisión que aislar, tomada al revés. Estado: Si tienes un proyecto donde hay que decidir cómo se ve algo — y sostener esa decisión a lo largo de una campaña, una web o un objeto impreso. ### NOTJUSTCODE — La auditoría de producto que nadie convoca URL: https://rbt-studio.com/casos/notjustcode/ _Visión, diseño y mercado revisados dentro del editor, sobre el repositorio_ · Herramienta open source · Product audit · CLI + prompt - **Cliente:** Side project — RBT Studio - **Rol:** Product design + prompt engineering + CLI - **Periodo:** Julio 2026 – Agosto 2026 · v0.5.1 funcional, pendiente de publicar en npm - **Stack:** Node.js ≥18.17 · cero dependencias, Claude Code · skills + slash commands, Markdown como capa de producto, MIT #### Contexto Un proyecto de software tiene revisión automática de casi todo menos de lo único que decide si sobrevive. El linter revisa el estilo, los tests el comportamiento, CI que compile. Nadie revisa si el producto tiene sentido. Ese hueco es de quien programa y decide a la vez — indie hackers, fundadores técnicos, freelances con producto propio — y su alternativa real no es otra herramienta: es enseñárselo a alguien con criterio, o enterarse por el silencio después del lanzamiento. #### El problema: Pedirle a un LLM que critique tu trabajo produce halagos con formato de informe Listas de observaciones tibias — "mejorar la jerarquía visual", "podría confundir al usuario" — que no obligan a cambiar nada. Un framework de auditoría que no resuelva esto no sirve, por buena que sea la estructura. Y una auditoría que consume la ventana de contexto entera tampoco: quien la ejecuta termina sin margen para arreglar lo que el informe le acaba de señalar. #### Cómo se abordó 1. **El producto es un prompt, no una aplicación.** La primera decisión de arquitectura fue reconocer dónde estaba realmente el valor. notjustcode son unas 200 líneas de Markdown en templates/; el CLI son 372 líneas dedicadas a copiarlas a la carpeta .claude/ del proyecto. Ese reparto —99% del código sirviendo al 1% del valor— es incómodo de mirar, pero es el correcto: el instalador se ejecuta en el momento de instalar, y la auditoría ocurre en el momento de auditar. Meter lógica de producto en el CLI significaría medir el repositorio en el instante equivocado. 2. **La regla que convierte una observación en un hallazgo.** Cada hallazgo tiene que presentarse como una cadena completa: hallazgo → evidencia en el repo → consecuencia → confianza. Sin evidencia señalable, el hallazgo no entra en el informe. La consecuencia tiene que nombrar qué hace una persona concreta en lugar de lo esperado —abandona, reintenta, escribe a soporte, no vuelve— y frases como «empeora la experiencia» están explícitamente prohibidas. Prohibir las consecuencias vacías no es una regla de estilo: es la defensa estructural contra el fracaso característico de esta categoría de herramienta. 3. **El coste de contexto es una decisión de producto.** Una auditoría que consume la ventana de contexto entera es inútil aunque el informe sea bueno: quien la ejecuta termina sin margen para arreglar lo que el informe le acaba de señalar. Por eso el alcance de lectura está escrito como parte del producto. El comando lee entero lo que habla del producto —README, manifest, rutas, copy de UI, tokens de diseño—, lee solo las primeras ~50 líneas de componentes y hooks, e ignora por completo node_modules, lockfiles, tests, migraciones y binarios. 4. **El análisis de mercado va detrás de un flag.** La capa de competencia y posicionamiento requiere búsqueda web. Cuesta lo mismo en un proyecto pequeño que en uno grande, pero su peso relativo no: suma alrededor de un +70% de contexto en un proyecto pequeño y solo un +6% en uno grande. Esa asimetría es la razón de que sea --market y no comportamiento por defecto. 5. **Especificar la v0.6.0 antes de escribirla.** El modo entrevista se diseñó con un proceso SDD completo antes de tocar una línea: SPEC con 7 requisitos funcionales y sus criterios de aceptación, ARCHITECTURE con 7 ADRs, más SCAFFOLD, AGENTS y HANDOFF. Como la funcionalidad no es código —son cinco secciones de Markdown— no existen tests automáticos posibles, y eso obligó a preferir sistemáticamente lo enumerable sobre lo interpretativo. npx notjustcode: Instalación en .claude/ → Alcance de lectura acotado → 01 · Visión → 02 · Diseño · Nielsen sobre rutas → 03 · Mercado (--market) → Filtro de consecuencias vacías → 04 · 3–5 acciones priorizadas #### Solución: Consecuencias prohibidas y un alcance de lectura escrito como producto La consecuencia de un hallazgo tiene que nombrar qué hace una persona concreta en lugar de lo esperado — abandona, reintenta, escribe a soporte, no vuelve. El comando lee entero lo que habla del producto y solo las primeras ~50 líneas de componentes y hooks; ignora node_modules, lockfiles, tests, migraciones y binarios. El análisis de mercado va detrás de un flag porque su peso relativo es asimétrico según el tamaño del repo. #### Decisiones de producto - **mi rol:** Product design + prompt engineering + CLI - **la arquitectura incómoda:** El producto es un prompt, no una aplicación. **~200 líneas de Markdown** son el valor; **372 líneas de CLI** sirven para copiarlas. Es el reparto correcto: el instalador se ejecuta al instalar, la auditoría al auditar. - **la regla que lo sostiene todo:** Cada hallazgo es una cadena completa: hallazgo → evidencia en el repo → consecuencia → confianza. Sin evidencia señalable no entra en el informe, y "empeora la experiencia" está explícitamente prohibido. - **estado:** v0.5.1 funcional de principio a fin · pendiente de publicar en npm · modo entrevista v0.6.0 especificado con proceso SDD completo. #### Resultados El proyecto está terminado como producto y aún sin publicar en npm, así que no hay métricas de uso que contar. Lo que sí hay: v0.5.1 funcional de principio a fin, con instalación, desinstalación limpia y --dry-run. Dos informes completos publicados en el repositorio sin editar las conclusiones incómodas —uno sobre el propio notjustcode y otro sobre un SaaS con interfaz— que son el activo de marketing principal, porque permiten evaluar el producto sin instalar nada. Y la herramienta se auditó a sí misma: cinco hallazgos, cuatro recomendaciones priorizadas, y la recomendación 3 es hoy la especificación completa de la v0.6.0. El informe sobre sí misma incluye un apartado sobre su propio foso que concluye que el producto no tiene defensa técnica ninguna — que el foso es la autoría, la distribución y la disposición a publicar la crítica que otros se guardarían. - **~90k** — tokens de contexto por auditoría, frente a ~420k leyendo el repo entero - **4 capas** — visión, diseño, mercado y acciones — cada acción referencia su hallazgo - **0** — dependencias · Node ≥18.17 · MIT > "La herramienta se auditó a sí misma y el informe se convirtió en el roadmap. El hallazgo más útil que produjo fue sobre sí misma: planificaba con mucha más facilidad de la que publicaba." #### Qué se aprendió 1. **La credibilidad depende de una regla, no del prompt entero.** Sin la prohibición de consecuencias vacías, el mismo framework produce un informe amable e inútil. No fue una ocurrencia: es la conclusión de haber visto fallar la versión sin ella. 2. **Un producto puede ser tan barato de copiar que proteger el código sea la estrategia equivocada.** Aceptarlo por escrito en el propio README sale más rentable que fingir un foso técnico que no existe: el foso es la autoría, la distribución y publicar la crítica que otros se guardarían. 3. **Lo interpretativo no se puede regresionar.** Como el modo entrevista no es código sino secciones de Markdown, no hay tests posibles — y eso obligó a preferir sistemáticamente lo enumerable sobre lo interpretativo. Estado: MIT. Repositorio público; paquete pendiente de publicar en npm. ### SDD HARNESS — Hablar el mismo idioma antes de la primera línea URL: https://rbt-studio.com/casos/sdd-harness/ _Un wizard de 5 fases para que los agentes construyan lo que tenía en la cabeza_ · Herramienta interna · Specification-Driven Development - **Cliente:** Side project / herramienta interna — RBT Studio - **Rol:** Diseño y desarrollo del skill - **Periodo:** Mayo 2026 · en uso activo - **Stack:** Claude Code · skill, Specification-Driven Development, Arquitectura multi-agente, TDD #### Contexto Cada vez que arrancaba un proyecto nuevo con agentes, el punto de partida era distinto: a veces directo al código, a veces una spec improvisada en un mensaje. El resultado era el mismo — specs inconsistentes de un proyecto a otro, y una desconexión entre lo que yo tenía en la cabeza y lo que los agentes acababan construyendo. #### El problema: Lo que había era o demasiado poco o demasiado Los skills de planificación más simples no tenían fondo real: una plantilla de spec sin nada detrás que asegurara que el código resultante la cumplía. Los más completos iban al otro extremo — procesos pesados pensados para equipos grandes que, en un proyecto propio o de cliente mediano, son fricción pura: mucha ceremonia, poca agilidad. #### Cómo se abordó 1. **Buscar primero, construir después.** Antes de escribir nada busqué soluciones existentes —otros skills de planificación estructurada— y ninguna encajaba. Los más simples no tenían fondo real: una plantilla de spec sin nada detrás que asegurara que el código resultante cumplía esa spec. Los más completos iban al otro extremo: procesos pesados, pensados para equipos grandes, que en un proyecto propio o de cliente mediano se convertían en fricción pura. Necesitaba algo en medio. 2. **Tratarlo como un sistema Lean, no como gestión de proyectos disfrazada.** La decisión de diseño clave. En vez de una plantilla de documento único, lo estructuré como un wizard de 5 fases, cada una con una responsabilidad concreta y una salida clara que alimenta a la siguiente: SPEC (qué y por qué), ARCHITECT (cómo y qué decisiones), SCAFFOLD (estructura base), HARNESS AGENTS (coordinación) y HANDOFF (entrega y contexto). 3. **TDD como la única disciplina no negociable.** El punto de apoyo del sistema es TDD: cada fase de implementación exige que los tests pasen antes de darse por buena, lo que actúa como ancla real contra la deriva — tanto la mía como la de los agentes. Es la diferencia entre «creo que esto cumple la spec» y «esto cumple la spec porque los tests lo confirman». Añadir más fases o más ceremonia habría reintroducido la fricción que quería evitar; quitar la disciplina de tests habría vuelto al punto de partida. wizard de 5 fases: SPEC → ARCHITECT → SCAFFOLD → HARNESS AGENTS → HANDOFF → TDD como ancla en cada fase #### Solución: Un sistema Lean con una disciplina no negociable Cinco fases secuenciales, cada una con una responsabilidad concreta y una salida clara que alimenta a la siguiente, generando los artefactos de documentación antes de tocar código de implementación. Añadir más fases habría reintroducido la fricción; quitar la disciplina de tests habría vuelto al punto de partida — buenas intenciones sin verificación. #### Decisiones de producto - **mi rol:** Diseño y desarrollo del skill - **las 5 fases:** **SPEC** qué y por qué **ARCHITECT** cómo y qué decisiones **SCAFFOLD** estructura base **HARNESS AGENTS** coordinación **HANDOFF** entrega y contexto - **el ancla:** TDD. Cada fase de implementación exige que los tests pasen antes de darse por buena — la diferencia entre "creo que esto cumple la spec" y "esto cumple la spec porque los tests lo confirman". - **estado:** Creado en mayo de 2026, en uso activo. La PRD completa de Job Search OS salió de este proceso. #### Resultados No hay una métrica única que resuma el impacto, pero el cambio en cómo trabajo es claro. Hay seguridad de que nada se pierde entre la idea inicial y el proyecto terminado, porque cada fase deja un artefacto que la siguiente puede consultar. Hay un mismo idioma entre yo y los agentes: con spec y arquitectura explícitas antes de implementar, no queda ambigüedad que cada agente interprete a su manera. Y hay menos rework, porque el enfoque TDD detecta los errores de interpretación pronto y no al final. Ya lo he usado para arrancar proyectos reales — la PRD completa de Job Search OS salió de este proceso, pivotando de una idea inicial de CRM manual a un Career Operating System event-driven con una arquitectura mucho más sólida de la que habría salido empezando directo por el código. - **5 fases** — cada una con un artefacto que la siguiente puede consultar - **1 ancla** — TDD — la única disciplina no negociable del sistema - **En uso** — desde mayo de 2026, en proyectos propios y de cliente > "La estructura correcta no está ni en la plantilla mínima ni en el proceso exhaustivo, sino en un sistema Lean con fases bien delimitadas y una única disciplina no negociable que hace de ancla." #### Qué se aprendió 1. **Seguridad de que nada se pierde** entre la idea inicial y el proyecto terminado — cada fase deja un artefacto trazable. 2. **Mismo idioma entre yo y los agentes.** Con spec y arquitectura explícitas antes de implementar, no queda ambigüedad que cada agente interprete a su manera. 3. **Menos rework.** El enfoque TDD detecta los errores de interpretación pronto, no al final — por ejemplo, pivotar de un CRM manual a un Career Operating System event-driven antes de escribir código. Estado: Herramienta interna, en uso activo desde mayo de 2026. ## Trabajo de cliente Algunos encargos de cliente en producción: de hospitales y universidades a tiendas y portfolios. - **UCSF** — Drupal · Custom theme & plugins - **SJD** — WordPress - **Obra Social SJD** — WordPress - **Universitat de Barcelona** — Custom - **Veritas** — E-commerce · Custom · Maps - **E.Casals** — WordPress - **Carrete** — Drupal · Custom theme & plugins - **Elche.me** — Drupal · Custom theme & plugins - **Cultura Sitges** — WordPress - **Marc Gomez del Moral** — Portfolio - **Curated Collective** — Custom · Motion - **AI Research COVID** — React - **Ecowave** — Custom - **Terpenic** — E-commerce - **Entangle** — Webflow - **El Risell** — WordPress - **Coralimentación** — Custom - **Hyphen** — Custom - **Gallantium** — Custom ## Donde la técnica genera experiencia La formación en Bellas Artes no es un antecedente del trabajo técnico: es parte de él. El código generativo, el movimiento y las instalaciones son el mismo lenguaje visual con otras herramientas. - **Sistemas y patrones vivos** (Código generativo): Exploración de fenómenos naturales mediante algoritmos: atractores, filotaxis, campos de flujo y autómatas celulares. - **Animación con propósito** (Movimiento e interacción): Microinteracciones, transiciones y respuesta que refuerzan la narrativa del producto. GSAP, Framer Motion y WebGL. - **Instalaciones interactivas** (Creative Technology): Entornos audiovisuales y proyecciones para espacios culturales. Donde la tecnología desaparece y queda la experiencia. - **Base conceptual y visual** (Bellas Artes): Bellas Artes en la Universidad de Barcelona. La sensibilidad estética y el pensamiento crítico que informa cada decisión técnica. ## Piezas generativas Sistemas generativos corriendo en vivo, uno por tinta. Ninguno es un vídeo: todos se dibujan mientras miras. - **Atractor de Lorenz:** Sistema caótico y determinista. Movimiento impredecible con un patrón debajo. - **Filotaxis:** El patrón del ángulo áureo. Mueve el cursor para alterar el crecimiento. - **Sistema de partículas:** Partículas que rebotan y se conectan. Generador de patrones emergentes. - **Árbol fractal:** Crecimiento recursivo de ramas que oscilan con el viento. - **Campo de flujo:** Ruido Perlin como campo vectorial. Las partículas siguen la corriente. - **Lemniscata:** La curva del infinito, respirando en oscilación lenta. - **Dispersión radial:** Transformaciones radiales con ruido. Expansión controlada. - **Espiral de giros:** Rectángulos en rotación. Geometría que crece girando. - **Colisiones:** Cuerpos que chocan y reparten energía. Física simple, resultado vivo. - **Curvas de Bézier:** Curvas suaves y elásticas con puntos de control oscilantes. ## Contacto Cuéntame el proyecto. Respondo en menos de 24 horas, desde Barcelona. contact@rbt-studio.com