HyperSpace

HyperSpace es una plataforma de IA todo en uno: una sola suscripción da a los usuarios un amplio catálogo de modelos y herramientas de IA para chat, imágenes, video, texto, voz y música, en web, iOS y Android. En mi etapa, la empresa elegía e integraba cada modelo por su cuenta, así que funcionaba como un catálogo curado y no como un marketplace abierto.

El CEO me invitó a sumarme como Chief Product Officer en septiembre de 2024, cuando la empresa llevaba más de un año construyendo el producto. El encargo era la monetización: se suponía que el producto funcionaba pero ganaba demasiado poco, y la empresa quería más experimentación y optimización.

Lo que parecía un problema de monetización era un problema operativo. Producción fallaba una y otra vez, a veces sin que el equipo lo notara, y muchas veces nadie podía decir dónde ni por qué. El logging y la analítica de producto no alcanzaban para diagnosticar fallas ni para explicar qué hacían los usuarios. El trabajo llegaba sin orden, las prioridades cambiaban antes de validar la idea anterior y las hipótesis que se consideraban críticas tardaban uno o varios meses en llegar a los usuarios. Además, la empresa pagaba servicios y herramientas que casi no usaba, y el horizonte de financiamiento que me comunicaron al llegar era de unos seis meses.

Experimentar con la monetización sobre esa base habría medido ruido. Antes de optimizar el crecimiento, el producto tenía que volverse operable.

Como CPO era responsable del producto y de cómo se construía, y en la práctica también del P&L: costos, unit economics y el panorama de gasto que llevaba al CEO. Lideré el cambio de liderazgo de ingeniería y trabajé con el nuevo CTO en la estabilización de producción.

Volver operable la empresa antes de optimizar la monetización: controlar el gasto, estructurar las entregas y estabilizar e instrumentar producción.

Construir un P&L y cortar todo costo que no sirviera al producto, para darle tiempo al turnaround.

Reemplazar el trabajo caótico de meses por entregas de dos semanas, un sistema compartido y responsables claros.

Cambiar el liderazgo de ingeniería cuando el proceso por sí solo no podía resolver las entregas ni la estabilidad.

Convertir el catálogo en un producto que guía, a partir de lo que cada usuario quiere hacer.

Juzgar las apuestas de producto con experimentos controlados, empezando por Energy.

No había un P&L con el que se gestionara el negocio, así que lo construí y lo mantuve: cada costo recurrente, qué aportaba y los unit economics detrás, revisados con el CEO. Así aparecieron suscripciones y servicios que casi nadie usaba y gasto de marketing que no se recuperaba. Los cortamos junto con otros costos operativos evitables, y más tarde el cambio de liderazgo de ingeniería también redujo el gasto.

Los costos operativos documentados sin nómina bajaron cerca de tres cuartos: el promedio mensual de septiembre de 2024 a febrero de 2025 quedó alrededor de un 74% por debajo de los tres meses previos a mi llegada. HyperSpace se financiaba por etapas a través de su inversor principal, no con un saldo fijo de caja. Frente al horizonte de unos seis meses que el CEO comunicó cuando llegué, el menor gasto extendió el horizonte operativo efectivo de la empresa a cerca de un año.

El equipo era chico y fragmentado: desarrolladores full-stack de nombre que trabajaban sobre todo en backend, un CTO que también programaba funcionalidades, un desarrollador frontend part-time y desarrollo móvil tercerizado. Nadie tenía una visión compartida de qué se estaba construyendo, quién lo hacía ni cuándo iba a estar listo.

Llevé todo el trabajo a Jira y a sprints de dos semanas. Las hipótesis grandes se dividían hasta entrar en un sprint, cada parte tenía un responsable y cada sprint terminaba con una revisión de lo que había salido y de qué cambiar. La demo mensual quedó como la capa de reporte por encima de los sprints. Las herramientas importaban menos que el efecto: el trabajo se volvió visible, dividido en partes y con dueño, y el equipo dejó de abandonar ideas antes de probarlas.

El proceso no podía arreglar ingeniería por sí solo. Hacía falta ownership técnico, una justificación de negocio para las prioridades y un plan de estabilidad. Impulsé el cambio de liderazgo de ingeniería, ya tenía un candidato capaz de asumir el rol y reemplacé al CTO.

Con el nuevo CTO armamos un plan de estabilización técnica. Incorporamos Sentry, logs y alertas, instrumentamos los errores en la analítica de producto y después resolvimos los cuellos de botella técnicos que esa visibilidad dejó al descubierto.

Las caídas diarias dejaron de ser normales. El servicio ya no se caía día tras día, y los incidentes que sí ocurrían se detectaban y resolvían mucho más rápido. La instrumentación también rindió en puntos concretos: expuso una falla en Sign in with Apple, cuyos errores bajaron a cero una vez corregida, y los errores que veían los usuarios cayeron cerca de un 30% de marzo a abril de 2025.

Dejar bien configurada la analítica de producto llevó tiempo: eventos de Amplitude en web y mobile, y después Adjust para la atribución. Cuando los datos fueron confiables, mostraron lo que el catálogo escondía. Cada usuario usaba solo una parte pequeña de una biblioteca de modelos enorme, en su mayoría irrelevante para él, y muchos no sabían qué hacer a continuación. Mil modelos no sumaban un recorrido de usuario, y la inestabilidad de producción empeoraba una retención ya débil.

De ahí salió la dirección: entender qué quiere lograr cada persona y guiarla hacia las capacidades que le sirven, en lugar de mostrarle un muro indiferenciado de modelos. El primer paso fue un nuevo onboarding web que preguntaba por los intereses del usuario. Generó las primeras compras hechas directamente dentro del onboarding y se convirtió en la plataforma para los experimentos que siguieron: onboarding, embudos de suscripción, assets del App Store, atribución y monetización en web y mobile.

Energy fue una hipótesis que el CEO propuso más o menos cuando llegué, y la respaldé como base para seguir experimentando. Cambiaba cómo funcionaba la suscripción: la suscripción daba un saldo de créditos Energy que se renovaba en cada período de facturación, y cada generación gastaba créditos según el cómputo que necesitaba. Una sola economía de uso pasó a cubrir capacidades de IA muy distintas, de imágenes a clips y música.

En el sistema de entregas que heredé, una funcionalidad así llevaba meses y no semanas, y en gran parte por eso importaba el trabajo operativo. Cuando Energy estuvo en producción en la web, la corrimos como test A/B. Los usuarios con Energy mostraron un área bajo la curva de retención de 26,34%, frente a 13,13% de los usuarios sin ella: 13,2 puntos porcentuales más, cerca del doble.

El turnaround redujo el gasto, estabilizó el producto y le dio a HyperSpace una forma de construir que podía medir lo que lanzaba. No llegó a hacer a la empresa autosustentable antes de que se agotara el financiamiento. HyperSpace dependía del financiamiento por etapas de su inversor principal, y a mediados de 2025 el financiamiento puente que necesitaba no se concretó. El desarrollo activo se congeló, la mayor parte del equipo se desvinculó y un desarrollador siguió manteniendo el producto. Mi etapa ahí terminó en septiembre de 2025. HyperSpace sigue en funcionamiento.

Un encargo de monetización puede esconder un problema operativo. Los experimentos solo significan algo cuando el producto no se cae, los datos son confiables y el equipo puede lanzar una hipótesis en semanas; por eso el trabajo siguió ese orden.