HyperSpace

A HyperSpace é uma plataforma de IA tudo em um: uma única assinatura dá aos usuários um grande catálogo de modelos e ferramentas de IA para chat, imagens, vídeo, texto, voz e música, na web, no iOS e no Android. Na minha época, a própria empresa escolhia e integrava cada modelo, então ela funcionava como um catálogo curado, não como um marketplace aberto.

O CEO me convidou para entrar como Chief Product Officer em setembro de 2024, quando a empresa já construía o produto havia mais de um ano. A missão era monetização: o produto supostamente funcionava, mas ganhava pouco demais, e a empresa queria mais experimentação e otimização.

O que parecia um problema de monetização era um problema operacional. A produção caía de novo e de novo, às vezes sem o time perceber, e muitas vezes ninguém sabia dizer onde nem por quê. Logging e analytics de produto não bastavam para diagnosticar falhas nem para explicar o que os usuários faziam. O trabalho chegava sem ordem, as prioridades mudavam antes de a ideia anterior ser validada e hipóteses tratadas como críticas levavam um ou vários meses para chegar aos usuários. A empresa também pagava por serviços e ferramentas que quase não usava, e o horizonte de financiamento comunicado quando entrei era de uns seis meses.

Experimentar monetização em cima disso teria medido ruído. Antes de otimizar o crescimento, o produto precisava se tornar operável.

Como CPO eu era responsável pelo produto e pelo jeito como ele era construído e, na prática, também pelo P&L: custos, unit economics e o panorama de gastos que eu levava ao CEO. Conduzi a troca da liderança de engenharia e trabalhei com o novo CTO na estabilização da produção.

Tornar a empresa operável antes de otimizar a monetização: controlar os gastos, estruturar as entregas e estabilizar e instrumentar a produção.

Construir um P&L e cortar todo custo que não servisse ao produto, para dar tempo ao turnaround.

Trocar o trabalho caótico de meses por entregas de duas semanas, um sistema compartilhado e responsáveis claros.

Trocar a liderança de engenharia quando o processo sozinho não resolvia as entregas nem a estabilidade.

Transformar o catálogo em um produto que guia, a partir do que cada usuário quer fazer.

Julgar as apostas de produto com experimentos controlados, começando pelo Energy.

Não havia um P&L usado para gerir o negócio, então construí um e o mantive: cada custo recorrente, o que ele entregava e os unit economics por trás, revisados com o CEO. Assim apareceram assinaturas e serviços que quase ninguém usava e gasto de marketing que não se pagava. Cortamos isso junto com outros custos operacionais evitáveis, e depois a troca da liderança de engenharia também reduziu o gasto.

Os custos operacionais documentados sem folha de pagamento caíram cerca de três quartos: a média mensal de setembro de 2024 a fevereiro de 2025 ficou cerca de 74% abaixo dos três meses anteriores à minha entrada. A HyperSpace era financiada em etapas pelo seu investidor principal, e não a partir de um saldo fixo de caixa. Frente ao horizonte de uns seis meses que o CEO comunicou quando entrei, o gasto menor estendeu o horizonte operacional efetivo da empresa para cerca de um ano.

O time era pequeno e fragmentado: desenvolvedores full-stack no nome, mas que trabalhavam sobretudo no backend, um CTO que também desenvolvia funcionalidades, um desenvolvedor frontend part-time e desenvolvimento mobile terceirizado. Ninguém tinha uma visão compartilhada do que estava sendo construído, por quem ou quando ficaria pronto.

Levei todo o trabalho para o Jira e para sprints de duas semanas. Hipóteses grandes eram quebradas até caber em um sprint, cada parte tinha um responsável e cada sprint terminava com uma revisão do que tinha saído e do que mudar. A demo mensal continuou como a camada de reporte acima dos sprints. As ferramentas importavam menos que o efeito: o trabalho ficou visível, quebrado em partes e com dono, e o time parou de abandonar ideias antes de testá-las.

O processo sozinho não consertaria a engenharia. Ela precisava de ownership técnico, de uma justificativa de negócio para as prioridades e de um plano de estabilidade. Defendi a troca da liderança de engenharia, já tinha um candidato capaz de assumir o papel e substituí o CTO.

Com o novo CTO montamos um plano de estabilização técnica. Adotamos Sentry, logs e alertas, instrumentamos os erros no analytics de produto e depois resolvemos os gargalos técnicos que essa visibilidade revelou.

Quedas diárias deixaram de ser normais. O serviço não caía mais dia após dia, e os incidentes que aconteciam passaram a ser encontrados e resolvidos muito mais rápido. A instrumentação também rendeu em pontos concretos: revelou uma falha no Sign in with Apple, cujos erros caíram a zero depois da correção, e os erros vistos pelos usuários caíram cerca de 30% de março para abril de 2025.

Deixar o analytics de produto bem configurado levou tempo: eventos do Amplitude na web e no mobile e, depois, Adjust para atribuição. Quando os dados ficaram confiáveis, mostraram o que o catálogo escondia. Cada usuário usava só uma pequena parte de uma biblioteca enorme de modelos, a maior parte irrelevante para ele, e muitos não sabiam o que fazer em seguida. Mil modelos não formavam uma jornada, e a instabilidade da produção piorava uma retenção já fraca.

Daí veio a direção: entender o que a pessoa quer realizar e guiá-la até as capacidades certas, em vez de um paredão indiferenciado de modelos. O primeiro passo foi um novo onboarding na web que perguntava pelos interesses do usuário. Ele gerou as primeiras compras feitas diretamente dentro do onboarding e virou a plataforma para os experimentos seguintes: onboarding, funis de assinatura, assets da App Store, atribuição e monetização na web e no mobile.

O Energy foi uma hipótese que o CEO propôs mais ou menos quando entrei, e eu a apoiei como base para mais experimentos. Ele mudava o funcionamento da assinatura: a assinatura dava um saldo de créditos Energy que se renovava a cada período de cobrança, e cada geração gastava créditos conforme o processamento de que precisava. Uma única economia de uso passou a cobrir capacidades de IA muito diferentes, de imagens a clipes e música.

No sistema de entregas que herdei, uma funcionalidade assim levava meses, não semanas, e em boa parte é por isso que o trabalho operacional importava. Quando o Energy entrou no ar na web, rodamos um teste A/B. Os usuários com Energy mostraram área sob a curva de retenção de 26,34%, contra 13,13% dos usuários sem ele: 13,2 pontos percentuais a mais, cerca do dobro.

O turnaround reduziu o gasto, estabilizou o produto e deu à HyperSpace um jeito de construir capaz de medir o que lançava. Não chegou a tornar a empresa autossustentável antes de o financiamento acabar. A HyperSpace dependia de financiamento em etapas do seu investidor principal, e no meio de 2025 o financiamento-ponte de que precisava não se concretizou. O desenvolvimento ativo foi congelado, a maior parte do time foi desligada e um desenvolvedor continuou mantendo o produto. Minha passagem terminou em setembro de 2025. A HyperSpace continua no ar.

Uma missão de monetização pode esconder um problema operacional. Experimentos só significam algo quando o produto fica no ar, os dados são confiáveis e o time consegue lançar uma hipótese em semanas; por isso o trabalho seguiu essa ordem.