Al comenzar un proyecto la clásica recibís un brief, abrís Figma o el editor y empezás a diseñar pantallas o a codear. Todo avanza rápido, todo parece productivo, y en poco tiempo ya hay algo visible. El problema es que muchas veces lo visible no significa que estemos resolviendo el problema correcto.
La segunda forma es más lenta, pero infinitamente más estratégica: te detenés, abrís la lupa y te preguntás:
¿Qué estoy construyendo realmente y para quién?
Ese ejercicio es el que separa a un ejecutor de un diseñador de producto. Porque el diseño no empieza en la interfaz. Empieza mucho antes: en el entendimiento del sistema, de los actores, de las fricciones reales y del contexto de negocio que sostiene todo.
Hoy más que nunca nuestro rol exige que pensemos como diseñadores de producto, con la lupa puesta no solo en “usuarios”, sino en todo el ecosistema: clientes, cliente del cliente, stakeholders, equipos internos y externos, operaciones, soporte, negocio, logística, proveedores, pagos, legal. Y sí, seguro me olvido de alguien, pero ese alguien también tiene un lugar en el mapa.
A esto se le suma un factor que cambió las reglas: la inteligencia artificial. La IA nos coloca en un lugar excepcional, uno que hace pocos años era impensado. Hoy podemos trabajar end-to-end, anticipar escenarios, investigar, documentar, planificar y construir con un nivel de velocidad y profundidad que antes requería equipos enteros. Ahora somos, en muchos casos, los orquestadores y arquitectos de productos digitales completos.
Pero ojo, porque acá también aparece una trampa.
Consejo: no seas un “vibe coder”.
Esa vibra puede servir para explorar rápido, para prototipar ideas o validar algo puntual. Pero si te quedás ahí, te hace daño. No te imaginás cuánto. Porque un producto real no se construye por impulso: se construye por arquitectura, por criterio y por decisiones conscientes que son primero y luego la cosa.
Y acá es donde quiero compartir algo que me tiene ocupado hace semanas.
Estoy construyendo un LMS (Learning Management System) completo para Animal Groom, una academia de grooming profesional que lleva más de 13 años formando peluqueros caninos de manera presencial. El objetivo principal es migrar un modelo tradicional y físico al mundo digital.
Y claro: esto no es un cambio automático ni instantáneo. Es un proceso gradual. Implica ajustar estructuras internas, roles, operación, oferta educativa, propuesta de valor y modelo de negocios. Migrar no es solo “digitalizar”, migrar es rediseñar el sistema.
Lo interesante es que Animal Groom es un caso perfecto de lo que ya está pasando en todos lados. Los negocios físicos, tradicionales, de operación local, están atravesando una transformación radical. La pandemia fue el gran disparador cultural: dejó en evidencia que el mundo puede funcionar de otra manera, y aceleró el cambio masivo en la forma de consumir productos y servicios.
En Córdoba y en Argentina esto no es ajeno. De hecho, consultando distintos rubros locales, los números son contundentes: más del 80% de los comercios ya funcionan con un modelo mixto (presencial + digital). Y un dato que muchos todavía no terminan de dimensionar: dentro del local físico, los pagos digitales ya dominan, con porcentajes que van del 80% al 92% según la industria.
Eso significa que la gente ya cambió. Las reglas del consumo no son nuevas, pero sí alcanzaron una penetración enorme. No estar atento a esto es quedarse. Y peor aún: quedarse sin hacerse la pregunta más importante de todas, la que todo negocio debería responder antes de lanzar cualquier plataforma ¿Cuál es nuestra propuesta de valor real? ¿Qué nos diferencia de la competencia?
Incluso en entrevistas y encuestas que fui haciendo, algunos reconocen que hoy venden más por el canal digital que por el tradicional. Algo que hace unos años era impensado, cuando el local físico dominaba por márgenes enormes y por lógica de mercado.
En este contexto, Animal Groom no es un “proyecto más”. Es un caso real de migración estratégica. Y lo estoy construyendo aplicando mi propio Framework Baraldi de Product Design, orquestado con inteligencia artificial, sobre un stack moderno que combina Next.js, React, PostgreSQL y una API multiplataforma.
Esto es un caso de estudio real, en progreso. Un producto real, para un cliente real, con usuarios reales. Y quiero contarte por qué este proyecto es completamente diferente a “hacerle una plataforma a un cliente”.
13 años de operación (y una ventaja que una startup mataría por tener)
Animal Groom tiene algo que la mayoría de las startups daría todo por conseguir: alumnos reales.
Cientos de personas pasaron por sus aulas, obtuvieron certificaciones y hoy trabajan en la industria. Esa es una base de mercado que no se inventa. No se simula. No se compra. Se construye con años de operación y reputación.
El problema es que toda esa data vive donde vive la mayoría de los negocios tradicionales: en planillas de Excel, en registros locales, en carpetas dispersas, en bases desactualizadas. Y tiene sentido. Durante años, el modelo presencial funcionó así.
Pero desde producto, esto abre una oportunidad enorme. Porque no solo hay alumnos actuales. Hay ex alumnos. Hay históricos. Hay una comunidad latente. Hay una relación ya construida. Hay confianza.
El pedido inicial fue simple:
“Queremos una web para que los alumnos puedan tomar cursos online, descargar materiales y gestionar certificados.”
Suena lógico. Suena razonable. Pero si parás la pelota y mirás con atención, ese pedido esconde una realidad mucho más compleja.
No existe una identidad digital consolidada de los alumnos. No hay emails verificados, no hay perfiles consistentes, no hay historial académico unificado.
No hay un sistema real de gestión de contenido educativo. Los cursos, módulos y lecciones viven en la cabeza del equipo docente o en documentación dispersa en distintos medios digitales y analógicos.
La migración de datos es un campo minado. Hay emails duplicados, información incompleta, formatos inconsistentes, teléfonos sin normalizar, DNIs escritos de veinte maneras distintas, registros sin datos críticos.
Y además, hay un punto que muchos no ven al inicio: este negocio tiene potencial SaaS.
Si este sistema funciona para Animal Groom, puede funcionar para cualquier academia de formación profesional. Y existen academias exitosas, y otras no tanto. Podemos aprender de todas, entender qué funciona, y sobre todo entender qué necesitan realmente los alumnos.
Ahí es donde aparece el verdadero desafío: no es “subir cursos a internet”. Es diseñar un ecosistema de aprendizaje escalable.
Framework Baraldi aplicado a un producto real
Antes de diseñar una pantalla o escribir una línea de código, activé el Framework Baraldi. Mi sistema de diseño de producto, que obliga a pasar por fases de descubrimiento estructurado antes de llegar a la interfaz.
Para mí, poner a prueba este framework es parte del proceso. No se trata de un checklist ni de un paso a paso rígido. Es un marco de trabajo que te acompaña como un asistente estratégico y que te obliga a hacer las preguntas correctas antes de enamorarte de una solución.
El primer paso fue lo más importante: definir el “para qué” antes del “cómo”.
Trabajé con el equipo de Animal Groom para mapear actores críticos, necesidades reales y tensiones del sistema. No me interesaba diseñar una plataforma “linda”. Me interesaba diseñar un producto que tenga sentido, que sea sostenible y que pueda evolucionar.
El framework me llevó a trabajar sobre tres grandes pilares iniciales.
El primero: Problem Framing.
Ahí definimos qué estamos resolviendo realmente, cuál es el objetivo final, cuáles son las métricas de éxito y qué hipótesis de negocio estamos poniendo a prueba. Porque “que funcione” no es una métrica. La métrica real es si el producto genera valor, si reduce fricción, si habilita crecimiento, si mejora retención, si habilita recompra, si fortalece el vínculo alumno-academia.
El segundo: System Analysis.
Con el problema enmarcado, pasé al mapeo del ecosistema completo. Identifiqué actores con distintos grados de alfabetización digital (y sí, muchos vienen del modelo presencial tradicional). Analicé flujos críticos como el onboarding de alumnos migrados, la inscripción a cursos, el progreso de aprendizaje, la evaluación, y la generación de certificados con verificación única.
También apareció una tensión inevitable: el balance entre “hacerlo simple para el alumno” y “hacerlo escalable para el modelo SaaS”.
El framework me forzó a documentar todo esto antes de tocar el código. Y en un proyecto donde hay un solo desarrollador senior (yo) y un asistente de IA, esa disciplina es la diferencia entre construir algo sólido… o construir algo que después no escala.
El stack tecnológico: el producto también se diseña desde la arquitectura
Acá el desafío no es solo elegir tecnología moderna. El desafío real es evaluar necesidades, costos, seguridad, disponibilidad, mantenimiento, performance y escalabilidad. Y esto también forma parte del rol de orquestador o arquitecto, porque el producto debe responder a pilares críticos: disponibilidad, accesibilidad, sostenibilidad y seguridad.
Mi consejo acá es siempre el mismo: investigá, aprendé lo suficiente para tomar decisiones con criterio, y rodeate de especialistas cuando haga falta. Resolver bien la base trae ahorro real para el cliente y evita dolores de cabeza posteriores.
Qué estamos construyendo realmente
El roadmap está dividido en cuatro fases. Hoy estamos en la fase 1: construyendo el core.
La plataforma ya está pensada como un sistema completo, no como un simple repositorio de videos. Incluye autenticación, perfiles, roles dinámicos, membresías, módulos académicos, cursos, inscripciones y estructura de contenido.
Pero lo interesante no es la lista de features. Lo interesante es la intención.
Esto no es “una plataforma de cursos”. Esto es una arquitectura diseñada para sostener un ecosistema educativo y comercial en expansión.
Multi-tenant desde el día 1: el giro que no se ve a simple vista
Acá está uno de los puntos más estratégicos del proyecto.
Muchos equipos construyen primero una versión single-tenant y después “agregan” multi-tenancy. Eso es como construir una casa de un piso y después querer agregarle un segundo sin cimientos. Funciona hasta que deja de funcionar. Y cuando deja de funcionar, el costo de reconstrucción es enorme.
En Animal Groom, la arquitectura multi-tenant está activa desde el inicio. Cada tabla tiene tenant_id. La seguridad está diseñada con Row Level Security (RLS). El sistema de memberships es central. Y el enfoque es zero-trust desde la sesión.
El MVP funcional es 100% B2C. Pero las capacidades B2B están bajo el capó, listas para activarse cuando la validación del mercado lo justifique.
Eso es diseño de producto real: pensar el presente sin hipotecar el futuro.
La migración de datos: de Excel al siglo XXI
Animal Groom tiene más de una década de registros en Excel, con todos los problemas que te podés imaginar.
Emails duplicados o faltantes. DNIs en formatos distintos. Teléfonos sin normalizar. Registros incompletos. Campos rotos. Historial académico inconsistente.
La estrategia es clara: primero migramos alumnos activos (últimos 12 meses), luego históricos. Y todo registro con conflictos pasa a una tabla especial para validación manual. Nada se importa automáticamente si hay ambigüedad.
Esta tarea es crítica. Porque es la base que va a permitir atender primero a los alumnos actuales y escalar después hacia features de recompra, venta de productos, eventos, comunidad y fidelización.
Un dev senior + IA como par estratégico
Este proyecto lo estoy desarrollando solo, asistido por inteligencia artificial.
Pero la clave está en cómo uso la IA. No como un generador pasivo de código, sino como un par estratégico que sigue reglas claras y respeta límites.
La IA genera outputs en todas las etapas del diseño de producto: documentación, PRDs, handoff, soporte de arquitectura y código dentro de módulos bien definidos, respetando boundaries.
Hay una regla absoluta: nunca auto-genera reglas de seguridad sin validación humana. La IA sigue la arquitectura documentada y patrones definidos previamente.
Las decisiones finales son humanas. Siempre. Para mí, esa es la diferencia entre “usar IA” e “integrar IA” en un proceso serio de diseño de producto.
Qué sigue
El proyecto está en plena construcción. Cada semana hay avances concretos: módulos que se completan, esquemas de base de datos que se validan, flujos de onboarding que se testean, decisiones que se documentan.
No es un side project. No es un ejercicio académico. Es un producto real para un cliente real con usuarios reales. Y este es exactamente el tipo de proyecto donde los diseñadores UX dejamos de ser “los que hacen pantallas” y empezamos a ser diseñadores de producto de verdad.
Si diseñás y construís productos digitales, la invitación es simple: pensá, y después existí.
A recordar siempre
Problem framing antes del código. Definí el “para qué” antes del “cómo”. El brief inicial casi nunca es el problema real, aprende a leer entre líneas y propone con vision a futuro.
Multi-tenant desde el inicio. No solo resuelvas el “aquí y ahora”. Pensá más lejos. Preguntate si hay oportunidades de negocio alrededor del mismo sistema. Sé un socio estratégico. Para eso te pagan.
Seguridad. La seguridad de los datos es crítica. Involucrate, o involucrá expertos. Es uno de los eslabones más importantes de todo el producto.
IA como par, no como ejecutor. La IA acelera. Pero las decisiones finales son humanas, porque construimos productos para humanos.
Nota: El framework Baraldi esta en constante actualización y evolución, y está disponible en mi repo para que lo puedas usar libremente con todos tus proyectos, cuéntame, recomiéndame mejoras o porque no participa en su construcción.
