- Relato prático de um desenvolvedor solo que desenvolveu e manteve todo o serviço em Rails sozinho e alcançou €1 milhão de ARR (receita recorrente anual)
- No início, começou apenas com um MVP básico, mas fez um rewrite completo e melhorias estruturais até transformá-lo em uma arquitetura sustentável
- O ponto central está na filosofia consistente do Rails, seus componentes e a capacidade de atender mobile com Turbo Native
- Uma arquitetura eficiente que conseguiu lidar com todo o tráfego e volume de uso, mantendo custos de servidor abaixo de €1.500 por mês
- No fim, vendeu uma parte da participação para um investidor de longo prazo e, 14 anos depois, contratou o segundo desenvolvedor, entrando em uma nova fase
Aplicando na prática o One-Person Framework
€1 milhão de ARR usando apenas Rails
- No início de 2022, a PlanGo ultrapassou €1 milhão de receita recorrente anual (ARR), algo que parecia um sonho para um serviço sustentado por uma única codebase em Rails e um único desenvolvedor
- Todas as áreas fora da tecnologia — definição de visão, aquisição de clientes e estratégia de crescimento — ficaram por conta dos cofundadores e da equipe de suporte ao cliente, mas do desenho da arquitetura até deploy, operação e implementação de frontend/backend, tudo foi feito sozinho
- O “One Person Framework” defendido por DHH, ou seja, uma estrutura em que uma única pessoa consegue cuidar da aplicação inteira, foi provado como algo real, e não apenas teórico
- A filosofia estrutural do Rails — permitir trabalhar design de banco de dados, lógica de negócio e UI de frontend dentro de um conjunto consistente de ferramentas — é especialmente vantajosa para times pequenos ou fundadores solo
- Este texto foi escrito para pessoas como:
- Desenvolvedores Rails: quem se pergunta se ainda é possível construir um produto grande sozinho hoje em dia
- Fundadores técnicos: quem acumula vários papéis e se sente sobrecarregado
- Pessoas que valorizam trabalho artesanal e escolhas tecnológicas bem pensadas
Como tudo começou
- Em 2011, o autor, então um desenvolvedor de 21 anos, conheceu Rails enquanto trabalhava em projetos existentes em PHP (CodeIgniter)
- Não havia grande estratégia; tudo começou por uma motivação simples de seguir a tendência e experimentar Rails
- Com uma ideia de marketing do cofundador, foi lançada uma oferta em que quem se cadastrasse na semana de lançamento ganharia 1 ano grátis
- A expectativa era de algumas dezenas de pessoas, mas na prática mais de 500 se cadastraram já na primeira semana
- Como o produto ainda estava em nível de MVP, logo chegaram centenas de pedidos de funcionalidades, perguntas e solicitações de suporte
- Os servidores aguentaram bem, mas a demanda dos clientes explodiu antes de o produto estar realmente pronto
- Como os dois cofundadores ainda tinham seus empregos principais, era impossível responder em tempo integral
- Como resultado, muitos usuários iniciais acabaram inevitavelmente decepcionados
- Essa experiência mostrou com clareza que “desenvolver software” e “operar um negócio de software” são problemas completamente diferentes
- Só implementar funcionalidades não basta; a grande lição foi que é preciso ter atendimento sustentável ao cliente, gestão de expectativas e um sistema de operação de serviço
Aprendendo enquanto construía
- O desenvolvimento começou com apoio de tutoriais de Rails e Stack Overflow, mas construir uma aplicação de produção responsável por um negócio real de clientes era algo de outra ordem completamente diferente
- O código Rails do começo incluía os seguintes erros típicos de iniciante:
- métodos de controller com mais de 200 linhas
- models gigantes com responsabilidades misturadas
- queries SQL ineficientes
- ausência de testes
- configurações e chaves secretas commitadas no Git
- Era possível entregar funcionalidades, mas a aplicação como um todo dependia de remendos temporários e de uma estrutura instável
- Recursos como autenticação de usuários, upload de arquivos, geração de PDF, UI administrativa e processamento de e-mails foram implementados rapidamente com apoio de Gems, mas com o tempo cada Gem passou a introduzir novas complexidades e problemas
- Ao usar
.round(2), surgiu um erro de cálculo de valores porque, diferente do esperado, foi aplicado o "banker's rounding"
- Até em algo simples como cálculo, ao delegar demais para Gems externas, apareceu um problema causado por falta de entendimento mais profundo sobre tratamento numérico
- Por volta de 2013, à medida que a experiência de operação do produto crescia, a dívida técnica também aumentava rapidamente, e desenvolver novas funcionalidades foi ficando cada vez mais difícil
Rewrite completo
- O rewrite completo normalmente é considerado uma escolha arriscada e ineficiente, mas em 2014 foi tomada a decisão de reconstruir tudo do zero com base em Rails 4
- Durante meses, foi mantido um trabalho paralelo intenso de sustentar a aplicação existente enquanto uma nova codebase era desenvolvida
- A arquitetura foi simplificada, as dependências de Gems foram reduzidas para menos da metade, e testes foram introduzidos nas funcionalidades centrais
- A nova estrutura ficou mais enxuta e mais rápida do que a anterior, especialmente projetada para ser mantida por um desenvolvedor solo em tempo parcial
- Esse rewrite acabou se tornando a base técnica que sustentou mais de 10 anos de operação por um único desenvolvedor
Rails é um superpoder
- A PlanGo foi operada por uma única pessoa até 2025, e o principal motivo que tornou isso possível foi o Rails
- Graças a características estruturais do Rails como Convention over Configuration, testes integrados, ActiveRecord, ActiveStorage e ActiveJob, foi possível minimizar decisões não essenciais e focar na criação de valor principal
- Depois da adoção de Turbolinks e Hotwire, também passou a ser possível entregar uma UI moderna sem depender de frameworks JS complexos
- No início do desenvolvimento, em 2011, quase não havia demanda por apps mobile, mas depois os apps iOS/Android se tornaram a principal interface da PlanGo
- Foram testados vários frameworks como Titanium, RubyMotion e Objective-C, enfrentando o problema de equilibrar qualidade e velocidade
- Depois da adoção do Turbo Native, a produtividade aumentou drasticamente, e mesmo com conhecimentos básicos de desenvolvimento nativo passou a ser possível criar apps de alta qualidade aproveitando a codebase em Rails
- Essa abordagem é especialmente ideal para apps B2B ou SaaS, pois permite alcançar desempenho e experiência nativos com um custo pequeno de desenvolvimento
- Como resultado, foram alcançados mais de 100 mil downloads de apps por ano e, por um período, o app ficou acima do Duolingo na App Store da Holanda
- Todos os apps foram desenvolvidos e mantidos por um único desenvolvedor Rails
- Principais métricas:
- Código Ruby: 36.170 linhas
- Código JavaScript: 13.495 linhas
- Cobertura de testes: 40%
- Usuários ativos por dia: 6.332
- Requisições por minuto no pico: 7.000
- Custo mensal de servidores: menos de €1.500
- Manter uma arquitetura monolítica estruturada foi uma das melhores decisões tomadas, permitindo deploy simples com Capistrano e depuração fácil, sem a complexidade de microsserviços
- Para fundadores técnicos, Rails não é apenas um framework, mas um superpoder que permite a uma única pessoa fazer o trabalho de um time inteiro
Além de €1 milhão
- No fim de 2022, surgiu uma virada inesperada: um investidor estrangeiro demonstrou interesse na PlanGo e enviou uma proposta de aquisição
- Naquele momento, a PlanGo já havia ultrapassado €1 milhão de ARR de forma bootstrapada e seguia com uma estrutura sustentável de receita e operação eficiente, mesmo sem capital externo
- A proposta levou o time a encarar a pergunta: "o que queremos daqui para frente?"
- Foram exploradas várias possibilidades: manter tudo como estava, escalar com capital externo ou vender completamente
- O apego ao negócio continuava profundo, mas cresceu a percepção de que, com mais recursos e especialização, seria possível transformar oportunidades em execução com mais facilidade
- Também do ponto de vista de realização financeira, recuperar parte do valor acumulado em mais de 10 anos enquanto o negócio continuava crescendo era uma escolha racional
- A solução escolhida ao final foi uma parceria com um fundo evergreen holandês alinhado em valores e direção de longo prazo
- Venda de uma parte da participação, mantendo o controle e a participação majoritária
- Mais recursos adicionais, sem comprometer a estrutura e a cultura existentes
- Essa decisão não fazia parte de uma estratégia de exit de curto prazo nem de expansão agressiva, mas sim de um plano de crescimento estável baseado em um negócio sustentável e centrado no cliente
- Depois disso, a abordagem baseada em Rails permaneceu a mesma, enquanto começava uma nova fase de perseguir com mais força oportunidades que antes eram difíceis de tentar
Lições aprendidas
- Estas são as lições de operar a PlanGo por 14 anos como fundador técnico solo
- Embrace Rails conventions
- É importante não tentar lutar contra a filosofia e as convenções do Rails
- O “Rails Way” é uma forma de resolver problemas já validada, e quanto mais você a segue, mais consegue focar no valor único do produto
- Less is more
- Gems e bibliotecas JS permitem implementar funcionalidades rapidamente, mas também aumentam a complexidade e as chances de quebra
- Antes de adicionar uma nova dependência, é preciso sempre se perguntar: "isso é realmente necessário?"
- Find a community
- Para um desenvolvedor solo, a conexão com outros desenvolvedores Rails é extremamente importante
- Como exemplo, a comunidade surgida ao criar o Spina CMS se tornou um elo valioso para troca de conhecimento e feedback, mesmo sem ser um ambiente de colegas de trabalho
- Technical debt isn't always bad
- Às vezes, escolhas pragmáticas para entrar rápido no mercado são melhores do que perfeição técnica
- O ponto central da dívida técnica é distinguir conscientemente o momento de assumi-la e o momento de pagá-la
- You can go far alone
- Com Rails, um único desenvolvedor consegue projetar, escalar e fazer deploy de um produto do tamanho de um time inteiro
- Não é preciso ficar preso à noção comum de que “é obrigatório ter um time”
O que vem pela frente
- O novo parceiro investidor concordava com o modo enxuto de operar da PlanGo, mas colocou apenas uma condição: adicionar mais um desenvolvedor Rails
- O problema não era insistir em desenvolvimento solo, e sim a própria dificuldade de onboardar um novo desenvolvedor em uma codebase que evoluiu ao longo de 14 anos
- A codebase não era apenas a evolução da PlanGo, mas também uma estrutura que carregava por inteiro a história de desenvolvimento pessoal de alguém que passou de iniciante a experiente,
com decisões e estilos de código de diferentes fases da vida coexistindo ali
- Ao contratar o segundo desenvolvedor Rails, encontrado na Rails World (Canadá), surgiram mudanças estruturais e impactos positivos
- Redução do risco técnico que antes era um ponto único de falha
- Entrada de novas perspectivas e ideias
- Melhoria da qualidade do código por meio de pair programming
- Estímulo intelectual trazido pela colaboração com outro desenvolvedor que fala a mesma linguagem
- Mesmo assim, não há planos de montar um grande time de desenvolvimento
- Como já foi demonstrado até aqui, uma abordagem baseada em Rails já é suficiente para um time pequeno, mas poderoso, construir software relevante
- Ainda assim, ficou claro que mesmo o desenvolvedor solo mais eficiente pode crescer ainda mais com um bom colega de equipe
- A jornada da PlanGo é um exemplo de que o One-Person Framework do Rails realmente funciona e,
uma prova de que times pequenos com as ferramentas certas conseguem construir negócios sérios segundo seus próprios padrões
- Seja para quem está criando o primeiro produto sozinho, seja para um time pequeno avaliando sua stack técnica, fica a esperança de que esta história mostre o que é possível quando se aproveita o Rails ao máximo
4 comentários
Transformei este conteúdo em um podcast com o resumo em áudio do NotebookLM.
https://notebooklm.google.com/notebook/…
Nesse nível, já está excelente. Vou lapidar mais um pouco.
Uau... isso é impressionante... de verdade. É incrível como ficou tão natural
E as informações entram de forma super clara...
Comentários do Hacker News
Há um usuário com experiência semelhante à de Django operando o próprio app
Há um usuário que afirma que a pessoa é mais importante do que o framework
Há um usuário compartilhando experiência com Rails e Phoenix
Há um usuário que fez uma apresentação dizendo que Rails 7+ ajuda até desenvolvedores solo a construir apps ambiciosos
Há um usuário compartilhando uma experiência em que um novo parceiro queria adicionar desenvolvedores Rails
Há um usuário construindo um app com AdonisJS
Há um usuário que acha que Rails é melhor que Django em muitos aspectos
Há um desenvolvedor solo construindo um app com Rails
Há um usuário que defende que reescritas completas devem ser evitadas
Há um usuário que considera que o framework não é tão importante