En el último post os conté que me había propuesto algo que llevaba años postergando: construir un producto digital con mis propias manos, sin saber programar, usando IA como equipo técnico. La idea es Savia, una plataforma de mentoría 1:1 que conecta profesionales con experiencia real con personas que están arrancando su carrera.
Pues bien, Savia ya existe. Está viva en savia.company, desplegada en producción, con su dominio propio, sus emails transaccionales funcionando y su sistema de sesiones coordinándose en tiempo real.
Pero no vengo a vender humo. Esto es un lanzamiento pequeño, deliberado, casi artesanal. Se que van a fallar cosas.
He hecho mucho testing y hay cosas que me ha costado solucionar. Cuando pensaba que ya lo tenía casi todo, el onboarding petaba cuando se hacía entre varios dispositivos (te registrabas en desktop pero validabas email desde móvil, por ejemblo).
Como decía, van a fallar cosas. Así que la idea es empezar a enseñárselo a gente real para recoger feedback antes de iterar. Si te pica la curiosidad, entra, explora y cuéntame qué te parece. De verdad. Escríbeme a mentors.savia.app@gmail.com con lo que sea: lo que te gusta, lo que no entiendes, lo que te chirría. Ese feedback ahora mismo vale oro.
Dicho esto, lo que quiero contar hoy no es que la app esté en producción. Es lo que pasó antes de que existiera una sola línea de código. Porque si algo he aprendido en este tiempo de experimentación, es que la parte más importante del “vibe coding” no tiene nada que ver con código.
La trampa del “empieza a pedirle cosas” a Claude
Cuando la mayoría de la gente piensa en construir algo con IA, se imagina abriendo un editor, escribiendo “hazme una aplicación de mentoría” y viendo cómo aparece magia en la pantalla. Y sí, la IA puede generar código. Pero el código sin contexto estratégico es ruido. Es como contratar a un equipo de ingeniería el día 1 sin tener claro qué problema resuelves, para quién, ni qué considerarás “éxito”.
Empecé frenando. No abriendo el editor. No escribiendo ni un prompt técnico. Primero invertí tiempo en construir el cerebro del proyecto.
Dediqué varios días — sí, días — a crear lo que llamo el “ecosistema estratégico” de Savia dentro de Claude Code. Y fue, con diferencia, la inversión de tiempo con mayor retorno de todo el proyecto.
Os cuento cómo lo hice, paso a paso.
Fase 1: Las custom instructions — enséñale quién eres.
Lo primero fue configurar las custom instructions de Claude. Esto es, básicamente, un archivo donde le dices a la IA quién eres y cómo quieres que trabaje contigo.
Parece una tontería, pero pensadlo así: cuando arrancas a trabajar con un equipo nuevo, lo primero que haces es darle contexto. Le cuentas tu experiencia, tu rol, tu nivel técnico, qué tipo de comunicación prefieres. No le dices “hazme un plan estratégico” en frío.
En mis custom instructions incluí:
-
Mi perfil profesional: 13 años en producto B2B, roles de PMM a CPO, sectores donde he trabajado.
-
Mi nivel técnico real: Sé diseñar sistemas pero no he programado nunca. No me hables como si supiera programar, pero tampoco me trates como si no supiera qué es una API o un webhook.
-
Cómo quiero que me hable: Directo, sin paternalismos, con opinión propia. Si algo es mala idea, que me lo diga. Si hay una decisión técnica que tomar, que me explique los trade-offs como se los explicaría a una PM senior, no a una estudiante.
¿Por qué importa esto? Porque la IA no es genérica si tú no eres genérico con ella. El nivel de las respuestas que obtienes es directamente proporcional a la calidad del contexto que le das. Créeme, le di vueltas a esto. Muchas vueltas. Y la diferencia entre un Claude “por defecto” y un Claude que sabe quién eres es abismal.
Fase 2: La mente estratégica — documentos fundacionales
Una vez Claude sabía quién soy y cómo trabajar conmigo, tocaba darle el contexto completo del proyecto. No un brief de dos párrafos. Un ecosistema de documentos estratégicos, como los que crearía para cualquier producto real en una empresa.
Perfil_Fundador.md — El “quién” y el “por qué”
Este documento responde a las preguntas que normalmente no se escriben: ¿por qué hago esto? ¿Qué me motiva de verdad? ¿Cuáles son mis miedos técnicos? ¿Qué quiero aprender en el proceso?
Suena a ejercicio de coaching, pero tiene una función muy práctica: le da a la IA el marco para tomar decisiones alineadas con tu intención real. Cuando más adelante Claude tiene que elegir entre una solución más compleja pero “correcta” y una más simple que encaja con mis objetivos de aprendizaje, este documento es el que guía esa decisión.
Vision_y_Contexto.md — El “qué”
Aquí va todo el contenido alrededor de la idea de Savia: el mercado de mentoría, los dos perfiles de usuario (mentores con experiencia real y mentees que arrancan su carrera), el gap que existe en las plataformas actuales, y la visión a medio plazo.
Este es el documento que cualquier PM reconocería como “el contexto del producto”. Nada revolucionario en su formato, pero crítico para que la IA entienda qué estamos construyendo y para quién.
Operating_Manual.md — El “cómo”
Este fue el más denso y probablemente el más importante de los tres. Es, literalmente, el manual de gobernanza del proyecto. Incluye:
-
Tono y comunicación: Cómo me habla Claude, cuándo es proactivo, cuándo pide validación, cuándo sube código sin aprobación o cuándo le dejo acceder a archivos sin que me pregunte.
-
Rol dominante: Staff PM. Claude actúa como mi equipo, pero yo soy la PM. Las decisiones de producto son mías. Las decisiones de implementación son suyas, salvo que afecten a la experiencia de usuario.
-
Nivel de autonomía: Dónde puede moverse solo (refactors, optimizaciones, bugs evidentes) y dónde tiene que parar y preguntar (cambios en flujos de usuario, decisiones de arquitectura, cualquier cosa visible para el usuario final).
-
PRD completo del MVP:
-
Problema (por qué existe Savia) que resolvemos
-
Usuarios para los que lo resolvemos (personas detalladas de mentor y mentee)
-
Solución (definición en una frase + happy path)
-
North Star metric + criterios de éxito
-
Scope v1 (features del MVP)
-
Antifeatures (cosas explícitamente fuera del MVP)
-
Estrategia de activación (supply-first, empezar por mentores)
-
Riesgos y mitigación
-
Timeline
-
¿Por qué meto el PRD dentro del Operating Manual? Porque quiero que cada vez que Claude trabaje en Savia, tenga presente no solo qué construir, sino dentro de qué marco de decisiones hacerlo. El PRD sin gobernanza es una lista de features. La gobernanza sin PRD es burocracia. Juntos, son el sistema operativo del proyecto.
Fase 3: El sistema de Skills — un equipo, no un chatbot
Aquí es donde la cosa se pone interesante. Una vez tienes el contexto estratégico, necesitas que la IA pueda cambiar de sombrero según lo que toque hacer. No es lo mismo revisar una decisión de arquitectura que escribir el copy de un email o auditar la accesibilidad de un componente.
Para eso creé un sistema de Skills: roles especializados que Claude puede activar según la tarea. Cada Skill tiene su propio prompt, sus propios criterios de calidad y sus propias reglas:
-
SKILL 1 — Staff PM: El rol por defecto. Priorización, decisiones de scope, trade-offs de producto.
-
SKILL 2 — Product Designer: Revisión de flujos, consistencia visual, accesibilidad.
-
SKILL 3 — PMM (Product Marketing Manager): Posicionamiento, redacción de emails, redacción de copy, comunicación con usuarios.
-
SKILL 4 — Software Architect: Decisiones de stack, patrones de código, performance, seguridad.
-
SKILL 5 — Critical Auditor: Revisiones de producción. El que te dice “esto se va a romper en producción” antes de que se rompa.
-
SKILL 6 — Vibe Coding: Implementación pura. Escribe código siguiendo las convenciones del proyecto.
-
SKILL 7 — Project Archivist: Documentación, decisiones técnicas, historial del proyecto.
La analogía que mejor lo explica: no contratas a “un tío que hace de todo”. Contratas especialistas. Cada uno sabe de lo suyo, tiene sus criterios, y aporta una perspectiva distinta. El hecho de que todos “vivan” dentro de la misma IA no significa que deban comportarse igual.
Para orquestar todo esto, creé un README_Skills.md — un documento que le explica a Claude cómo activar cada skill, cuándo cambiar entre ellas, y cómo se relacionan entre sí. Es el equivalente a tener un organigrama funcional de tu equipo.
Lo que nadie cuenta del vibe coding
Todo esto — las custom instructions, los documentos fundacionales, las skills, el README — lo hice antes de escribir una sola línea de código. Antes de elegir stack. Antes de crear la base de datos. Antes de diseñar la primera pantalla.
¿Fue rápido? No. ¿Fue necesario? Absolutamente.
Porque cuando finalmente empecé a construir, Claude no era un chatbot genérico al que le pedía cosas. Era un equipo que entendía el proyecto, conocía mis limitaciones, respetaba mis decisiones de producto y sabía cuándo preguntar. La velocidad de desarrollo que vino después — y que contaré en próximos posts — fue consecuencia directa de esta inversión inicial.
Si estás pensando en construir algo con IA, mi consejo es este: no empieces por el código. Empieza por el contexto. Cuanto más clara tengas la estrategia, mejores serán las respuestas. Y esto aplica tanto si estás construyendo un side-project como si estás integrando IA en tu equipo de producto.
Savia está en savia.company. Es pequeña, es un MVP, y seguramente tiene cosas que mejorar. Por eso la lanzo ahora: para que me digáis qué funciona y qué no. Entrad, explorad, y si os animáis, escribidme a mentors.savia.app@gmail.com. Toda opinión cuenta.
Y vosotros… ¿habéis probado a construir algo con IA? ¿Empezasteis por el código o por el contexto?