Problema
El reto
Trabajando con diferentes compañias identifiqué un problema recurrente: ninguna sabía exactamente cuánto gastaba en software y sobre todo ninguna sabia si ese gasto estaba justificado.
Empresas que pagaban Notion para 40 personas cuando solo 12 lo usaban activamente. Tenían Atlassian contratado para un equipo que llevaba meses sin tocarlo. HubSpot renovando automáticamente sin que nadie lo hubiera revisado.
Según datos del sector, las empresas desperdician de media un 30% de su presupuesto en software infrautilizado. Para una PYME que gasta 3.000€/mes en herramientas, eso son 900€ tirados cada mes.
Research
Benchmark
Hice un benchmark de las soluciones existentes:
Torii, Zylo, BetterCloud — soluciones enterprise con precios de enterprise. Implementación de semanas y contratos anuales de miles de euros. Fuera del alcance de cualquier PYME.
Cledara, Substly — más accesibles, pero sin versión en español, con onboarding complejo y enfocadas en el mercado anglosajón.
Hojas de Excel — la solución real de la mayoría. Funciona, pero no escala, no avisa, no analiza.
No existía una solución simple, asequible y en español para el mercado de pymes.
Descubrimiento y target
A través de conversaciones informales con perfiles relevantes identifiqué tres arquetipos principales:
El Office Manager que gestiona el día a día operativo y recibe las facturas sin contexto suficiente para cuestionarlas. El CFO que necesita justificar cada partida de gasto ante dirección pero no tiene los datos organizados. El CEO que aprobó herramientas cuando el equipo era pequeño y ahora ha perdido el control.
Los tres comparten el mismo dolor: visibilidad cero sobre si su inversión en software tiene sentido.
Proceso
Arquitectura de la información
Definí la arquitectura alrededor de tres momentos del usuario: ¿cómo estoy? (Dashboard), ¿qué tengo? (Stack) y ¿qué hago? (Insights). Cada sección responde una sola pregunta y lleva a una sola acción.
Pero había una restricción de diseño más importante: si el objetivo es reemplazar el Excel, no podía construir simplemente un dashboard bonito o una tabla más ordenada.
El Excel no te dice qué hacer. No detecta que llevas tres meses pagando por licencias que nadie usa. No te calcula cuánto ahorrarías si cambiaras de herramienta. Solo muestra lo que tú mismo has introducido.
Ahí está el espacio. La feature principal tenía que hacer exactamente lo que el Excel no puede: interpretar los datos y convertirlos en decisiones concretas. Por eso Insights no es una sección más, es el motivo por el que existe el resto.
Principios de diseño
Claridad sobre completitud Un dashboard vacío es mejor que un dashboard lleno de ruido. Cada métrica, cada gráfico, cada label tiene que ganarse su sitio. Si no ayuda al usuario a tomar una decisión, no está.
El dinero como lenguaje. Esta solución habla a gestores, no a técnicos. Traducimos cada dato a su impacto económico real — no "uso al 40%" sino "estás pagando 480€ por licencias que nadie usa". El producto piensa en euros, no en porcentajes.
La acción por encima de la información Mostrar datos no es suficiente. Cada pantalla tiene que responder implícitamente a "¿y yo qué hago con esto?". El valor no está en lo que el usuario ve, sino en la decisión que toma después de verlo.
Decisiones de diseño
Estados por herramienta
Definí tres estados automáticos basados en el porcentaje de uso real sobre asientos contratados: Crítica (<40%), A revisar (40-70%) y Optimizada (>70%). Estos estados están creados para que "A revisar" sea una señal de acción antes de que el problema sea crítico, no después.
Empty state como experiencia.
Con pocos datos, un dashboard vacío destruye la percepción de valor. Diseñé estados vacíos específicos para cada situación: ghost UI en el gráfico de evolución para mostrar cómo se verá cuando haya datos, mensajes motivadores en lugar de errores, y progresión visual que hace sentir al usuario que está construyendo algo.
Comparativa de alternativas.
La funcionalidad más diferencial del producto. En lugar de solo decirle al usuario que Jira está infrautilizado, le decimos que existe Linear a 8€/asiento frente a los 15€ que paga ahora, y que con sus 25 asientos eso son 175€/mes de ahorro potencial. Transforma un insight abstracto en una decisión concreta.
Solución
Dashboard con tres métricas clave: ahorro potencial, gasto mensual y gasto anual proyectado. El gráfico de evolución muestra el año completo desde que te creas la cuenta a un año vista para dar contexto temporal desde el primer día de uso.
Stack como centro de operaciones. Tabla completa de herramientas con logo, categoría en chip, barra de uso de asientos con código de color automático, coste mensual y fecha de renovación. Tres cards resumen en la parte superior: apps activas, asientos totales y coste por asiento — la métrica de eficiencia más honesta del stack.
Insights en dos pestañas. La primera, "Optimizar uso", muestra en formato de lista horizontal las herramientas que necesitan atención, con su estado, uso real, ahorro estimado y acción recomendada concreta. La segunda, "Comparativa de herramientas", enfrenta cada herramienta del usuario con su alternativa más económica disponible en el mercado, mostrando el diferencial de coste real con los asientos actuales.
Onboarding en tres pasos diseñado para que el usuario vea valor en menos de diez minutos: nombre de empresa y tamaño, selección de herramientas del stack desde un grid visual, e introducción de datos por herramienta con ayudas contextuales y calculadora de coste por asiento en tiempo real.
Aprendizajes
Lo que funcionó
Separar las decisiones de producto de la implementación técnica resultó ser una ventaja, no una limitación. Sin la carga cognitiva del código, pude dedicar toda la atención a los porqués: por qué esta métrica y no otra, por qué este flujo y no el alternativo, por qué este empty state y no simplemente nada.
El principio de diseñar para el empty state desde el principio cambió la calidad del producto significativamente. La mayoría de productos se diseñan para el happy path y añaden los estados vacíos al final. En MyStack los diseñé en paralelo, y eso se nota en la cohesión de la experiencia.
El límite honesto del MVP
El mayor aprendizaje es también la mayor limitación del producto actual: la introducción manual de datos crea una fricción que puede romper la propuesta de valor antes de que el usuario la experimente.
El usuario que más necesita la herramienta es el que menos datos organizados tiene. Es una paradoja de diseño que solo se resuelve con automatización, integraciones directas con las herramientas para leer datos de uso sin intervención manual.
La reflexión más importante
Este proyecto confirma que la distinción entre diseñador y builder se está diluyendo. Un diseñador de producto con criterio claro, capacidad de decisión y las herramientas adecuadas puede llevar un producto de cero a producción sin depender de un equipo de ingeniería.
Eso no elimina la necesidad de ingenieros, los necesitarás cuando el producto escale, cuando la arquitectura se complique, cuando aparezcan problemas de rendimiento o seguridad. Pero en la fase de validación de una idea, la barrera técnica ya no es una excusa.
El conocimiento que importa sigue siendo el mismo: entender el problema, conocer al usuario, tomar decisiones de producto con criterio. Eso no lo automatiza ninguna IA.