O daSphere nasceu com a ambição de se tornar uma startup nacional. Em 2016, um investidor estrangeiro me convidou para participar do projeto e, naquele momento, a proposta parecia extremamente promissora. A ideia era formar uma equipe de designers e desenvolvedores para construir uma plataforma inspirada no conceito do GoBoard, porém com um direcionamento mais voltado para um verdadeiro social hub.

Em vez de apenas exibir informações, o objetivo era permitir que o usuário gerenciasse todas as suas redes sociais em um único ambiente. Para isso, integraríamos diversas APIs em uma plataforma baseada em HTML5, JavaScript e Google Firebase. Assim, o daSphere poderia se tornar a nova aba principal do navegador.

Qual a proposta do daSphere?

Atualmente, precisamos manter várias abas abertas para acompanhar redes sociais, mensagens, e-mails e notícias. No entanto, imagine concentrar tudo isso em uma única interface, com atualização dinâmica e ferramentas integradas entre si. Essa era a proposta central do daSphere.

Contudo, rapidamente nos deparamos com desafios clássicos de startups:

• Investimento limitado;
• Freelancers desalinhados com qualidade e prazo;
• Stakeholder exigindo escopo amplo com orçamento reduzido;
• Mudanças de mercado eliminando diferenciais estratégicos.

Portanto, o que parecia apenas um produto digital passou a se tornar um exercício real de estratégia, liderança e tomada de decisão sob pressão.

Porque esse case foi importante para mim?

Ao longo da minha carreira, sempre atuei como freelancer ou em projetos pessoais. Estou acostumado a equilibrar orçamento, prazo e expectativa do cliente. Entretanto, no daSphere, precisei assumir um papel diferente.

Aprendi a liderar equipe multidisciplinar, negociar com investidor e justificar decisões estratégicas com base em risco e retorno. Além disso, passei a acompanhar na prática a execução de um plano de negócios real, entendendo como microdecisões impactam diretamente o futuro de um produto.

Esse projeto deixou de ser apenas técnico. Tornou-se um aprendizado sobre timing de mercado, alinhamento de stakeholders e validação de proposta de valor.

Um case de microdecisões, timing de mercado e aprendizados reais

Vou contar essa história como ela foi. Sem glamour e sem final forçado. O daSphere foi um daqueles projetos que ensinam mais quando não avançam do que muitos que dão certo.

Onde tudo começou (2016)

Em 2016, um amigo americano que morava em Boise, Idaho, apresentou a ideia após observar dashboards como o GoBoard em hotéis. A provocação foi simples:

“E se isso existisse no navegador? E se fosse pessoal?”

Inicialmente, a proposta incluía:

• Notícias via RSS;
• Clima da região;
• Alguns serviços úteis.

No começo, o escopo era informativo. Entretanto, percebi que poderíamos ir além.

Minha primeira decisão:

Naquele momento, as APIs do Twitter, Instagram e Facebook ainda retornavam o feed completo do usuário. Por isso, sugeri ampliar o conceito e integrar também os feeds sociais em uma única tela. Dessa forma, o daSphere deixaria de ser apenas um painel informativo e passaria a atuar como um verdadeiro social hub.

A partir dessa decisão, entramos naturalmente no território do Hootsuite. Contudo, entendemos que nosso diferencial deveria estar na experiência visual, na escalabilidade e em um modelo freemium mais amigável.

A proposta era sólida. Porém, a cada evolução técnica, o mercado se movia e nos obrigava a revisar a estratégia. Enquanto desenvolvíamos, APIs mudavam e concorrentes evoluíam.

Nossas referências de dashboard incluíam GoBoard, Microsoft Azure e Microsoft System Center Advisor. Já a inspiração para a loja de apps veio do antigo Google News e seu sistema de fontes agregadas.

O Conceito:

O usuário teria um dashboard totalmente personalizável. Poderia adicionar ou remover widgets conforme desejasse. Além disso, criaríamos uma “loja” de apps, permitindo conexão das ferramentas às contas do usuário por meio de login único.

Chamamos esses aplicativos de widgets. Inicialmente, seriam desenvolvidos por nós, com visual semelhante aos apps oficiais, reforçando familiaridade e usabilidade. Ao mesmo tempo, o sistema permitiria drag and drop e redimensionamento, criando uma experiência realmente customizável.

A visão era clara: construir um social hub configurável e centralizado.

O que seria igual aos concorrentes:

• Visualização e interação com redes sociais;
• Publicação e agendamento multiplataforma;
• Feeds RSS.

O que seria diferente dos concorrentes:

• Dashboard personalizável;
• Widget store própria;
• Possibilidade de desenvolvedores externos criarem widgets HTML5.

Minha segunda decisão – o nome:

Depois de diversas sugestões, propus o nome “daSphere”, inspirado em “The Sphere”. O conceito representava um círculo onde o usuário teria todas as informações concentradas em um único ambiente. Além disso, o nome era simples, memorável e facilmente pronunciável tanto em inglês quanto em português.

O Logo:

O primeiro grande problema surgiu aqui.

Inicialmente, contratamos um designer freelancer. No entanto, atrasos e desalinhamentos comprometeram o cronograma. Diante disso, assumi o layout da plataforma e desenvolvi um símbolo minimalista que representava parte da letra “d” e, ao mesmo tempo, um círculo com brilho.

Alguns enxergaram uma lente; outros, uma íris. Independentemente da interpretação, o símbolo agradou aos stakeholders e passou a representar oficialmente o projeto. Além disso, realizamos uma pequena validação com públicos de língua inglesa e portuguesa, que reagiram positivamente ao nome e à identidade.

A partir desse ponto, assumi definitivamente a liderança visual do produto.

O desenvolvimento:

Enquanto mantinha meu trabalho em horário comercial, cuidava do produto, do design e da estratégia. Precisávamos de desenvolvedores; contudo, enfrentamos problemas recorrentes com freelancers:

• Atrasos constantes;
• Entregas desalinhadas com o layout;
• Código inconsistente;
• Retrabalho frequente.

Após várias tentativas, encontramos um desenvolvedor comprometido. Assim, conseguimos estabilizar a base técnica.

As primeiras versões foram construídas com Drupal, PHP, HTML5 e jQuery (Masonry), utilizando iframes para os apps. Entretanto, surgiram limitações em drag and drop e redimensionamento.

Foi então que tomamos uma decisão estratégica relevante: migrar para ReactJS. Embora ainda não fosse dominante na época, analisamos escalabilidade, desempenho e manutenção antes de decidir. Essa escolha se mostrou tecnicamente acertada e permitiu a construção de um MVP funcional com qualidade.

O primeiro murro que levamos:

No meio do desenvolvimento, Instagram, Facebook e Twitter alteraram suas APIs. Como consequência, o feed completo deixou de ser disponibilizado. Essa mudança eliminou o principal diferencial do daSphere como social hub centralizador.

O segundo murro que levamos:

Pouco depois, o Hootsuite lançou sua própria loja de aplicativos. Com isso, nosso diferencial competitivo reduziu drasticamente.

Mas o que matou mesmo o projeto?

O fator decisivo foi estratégico.

Com orçamento enxuto, deveríamos ter lançado um MVP mínimo e evoluído gradualmente com base em feedback real. Aos poucos, poderíamos validar a proposta de valor, ajustar funcionalidades e monetizar de forma progressiva.

No entanto, o investidor optou por aguardar todas as funcionalidades prontas antes do lançamento. Consequentemente, tempo, recursos e motivação foram sendo drenados. Sem validação de mercado e sem tração inicial, o projeto perdeu força até ser encerrado.