Quando começamos a KeepFlow, enfrentamos a escolha que toda equipe técnica enfrenta no início: construir software para clientes, ou construir software que seja nosso. O caminho de agência é o mais seguro. Os clientes pagam na entrega, a receita é previsível, e quando um projeto é lançado, ele vira problema de outra pessoa. Escolhemos o caminho mais difícil de forma deliberada. Todo produto que a KeepFlow faz, nós somos donos de ponta a ponta — nós o construímos, nós o operamos, e convivemos com cada decisão por todo o tempo que ele existir.

Isto não é uma frase de marketing. Muda como a engenharia de fato funciona, de maneiras que levamos um tempo para apreciar por completo. É isto que a propriedade faz com a forma como você constrói.

Quando a relação não termina na entrega

A característica que define o trabalho para clientes é que ele tem um fim. Você delimita um projeto, você o constrói, você o entrega, e a relação se encerra. O que quer que aconteça com aquele software depois — os bugs que surgem sob carga real, os despenhadeiros de desempenho, o patch de segurança que nunca é aplicado — agora pertence a outra pessoa. Você já seguiu para o próximo contrato.

Ser dono dos seus produtos elimina o fim. Não há entrega, não há um momento em que o código deixa de ser problema seu. Isso soa como um fardo, e em alguns dias é. Mas também elimina a maior fonte de atalhos no software: a certeza de que não será você quem vai lidar com as consequências. Quando não há saída, cortar caminho não é economizar tempo — é emprestar um problema a si mesmo com juros, e é você quem paga a conta.

Todo bug é o seu bug

O efeito mais imediato é sobre a responsabilização, e não é abstrato. Todo bug em um produto da KeepFlow é o nosso bug. Toda regressão de desempenho aparece nos nossos próprios números. Todo usuário frustrado é um veredito direto sobre um trabalho que nós fizemos. Não há para quem repassar o tíquete.

Isso derruba um muro que a maioria das organizações de software gasta uma energia enorme para manter — aquele entre as pessoas que escrevem o software e as pessoas que o operam. Na KeepFlow, são as mesmas pessoas. O engenheiro que construiu um recurso é quem o acompanha em produção, quem responde quando ele dispara um alerta às três da manhã, e quem lê o que os usuários dizem a respeito dele.

Esse arranjo é desconfortável por design, e é essa a intenção. Quando a pessoa que sobe o código é a pessoa que é acordada por ele, os incentivos em torno da qualidade deixam de ser algo que você precisa impor com processo. Ninguém quer depurar o próprio atalho às 3 da manhã. A pressão para construir certo da primeira vez vem da estrutura do trabalho, não de um documento de política.

Construindo para tempos de vida, não para prazos

Projetos para clientes são organizados em torno de prazos. Produtos próprios são organizados em torno de tempos de vida, e essa diferença alcança decisões técnicas que parecem idênticas na superfície, mas saem opostas.

Quando você está construindo algo que vai operar por anos, o cálculo de quase toda escolha se inverte:

  • Você investe em observabilidade desde o começo, porque é você quem vai encarar os dashboards às 2 da manhã, e um sistema em que você não enxerga é um sistema que você não consegue operar.
  • Você escreve os testes que ficaria tentado a pular sob um prazo, porque é você quem vai alterar este código daqui a dois anos, muito depois de ter esquecido como ele funciona.
  • Você escolhe uma tecnologia sem graça e comprovada em vez do framework novo e empolgante, porque você está se comprometendo a manter essa decisão por um bom tempo, e a novidade tem o costume de virar um passivo assim que o hype vai embora.

Nenhuma dessas escolhas ajuda você a entregar mais rápido neste trimestre. Todas elas são obviamente corretas quando seu horizonte de tempo é medido em anos em vez de semanas. O trabalho para clientes raramente as recompensa, porque quem faz o tradeoff não é quem herda o custo. A propriedade funde essas duas pessoas em uma só.

O ciclo de feedback se fecha

Há um benefício mais sutil, que demoramos mais para perceber: quando você é dono do produto, o ciclo entre o problema de um usuário e a correção dele fica drasticamente mais curto, porque nenhum contrato fica no meio do caminho.

No trabalho de agência, aprender algo sobre seus usuários costuma ser o começo de uma negociação. Você nota um ponto de atrito, mas agir sobre ele significa uma solicitação de mudança, uma conversa de escopo, uma nova ordem de serviço — e, quando tudo isso se resolve, o insight já ficou obsoleto. A economia desencoraja ativamente agir sobre o que você aprende, porque toda melhoria é faturável e, portanto, contestada.

Quando o produto é seu, notar e corrigir são o mesmo movimento. Um engenheiro lê uma conversa de suporte, reconhece o padrão por trás de três reclamações, e sobe a correção naquela mesma tarde — sem cadeia de aprovação, sem fatura, sem debate sobre se está no escopo. As pessoas mais próximas do problema têm tanto o contexto para entendê-lo quanto a autoridade para resolvê-lo. Ao longo de meses, esse acúmulo de pequenas melhorias sem bloqueios é a maior parte do que separa um produto que as pessoas toleram de um em que elas confiam.

Isso também muda o que construímos, para começar. Como operamos tudo o que fazemos, sentimos a falta dos nossos próprios recursos antes de qualquer usuário reportá-la. Várias das coisas mais afiadas dos nossos produtos começaram como um incômodo que um de nós teve ao operar um produto diferente na mesma equipe. Ser o seu próprio cliente mais exigente é um tipo de pesquisa que nenhum briefing de cliente consegue comprar.

Sem correr atrás de tendências

Há uma tentação neste setor de tratar a coisa mais nova como a melhor coisa — de reconstruir sobre qualquer framework em ascensão, de correr atrás do padrão de arquitetura que está em alta. Nos esforçamos muito para resistir a isso, e a propriedade torna isso mais fácil, porque sentimos o custo integral de toda tendência que perseguimos. Uma reescrita que está na moda neste ano é um fardo de manutenção que carregamos pelos próximos cinco.

O que estamos construindo, em vez disso, é a infraestrutura da qual as empresas dependem todos os dias: um atendimento ao cliente que tem que responder, uma detecção de fraude que tem que estar certa, uma moderação que tem que ser rápida, ferramentas que as pessoas usam sem pensar no que há por baixo. Esse tipo de software conquista confiança devagar, pelas virtudes sem graça — confiabilidade, consistência, estar presente e funcionar. Essas virtudes não vêm da novidade. Elas vêm de se importar com algo por tempo suficiente para acertá-lo, e então permanecer para mantê-lo assim.

Essa é toda a razão pela qual criamos nossos próprios produtos. Não porque seja mais fácil — não é — mas porque conviver com as próprias decisões é a forma mais confiável que conhecemos de tomar boas decisões.