# Ruby on Rails: o que a convenção compra > O que o Rails decide por você, o que a convenção compra e o que ela custa, onde ele não encaixa e como se compara a Django e Laravel. **URL:** https://northern.com.br/ruby-on-rails/ **Data:** 2026-08-27 --- Ruby on Rails é um framework para construir aplicações web em Ruby. A diferença dele não está no que permite fazer, e sim no que ele decide por você: estrutura de pastas, conversa com o banco de dados, rotas, filas, envio de e-mail e onde os testes moram já vêm resolvidos e iguais em todo projeto. Este texto mostra o que é convenção sobre configuração e o que ela custa, onde Rails é a escolha certa e onde não é, como ele se compara a Django e Laravel, a objeção do tamanho do mercado e por que é a stack em que a Northern constrói. **Neste guia** - [O que é, e o que ele decide por você](#o-que-e) - [Convenção sobre configuração, e o que ela custa](#convencao) - [Onde é a escolha certa, e onde não é](#onde) - [Rails, Django e Laravel](#comparacao) - [A objeção do mercado de desenvolvedores](#mercado) - [O mito de que serve só para começar](#escala) - [Por que é a nossa stack](#northern) ## O que é, e o que ele decide por você Quase nenhum projeto web parte da linguagem pura. Entre a linguagem e o produto existe um framework, e escolher a linguagem é, na prática, escolher o framework dela: Python para web é Django, PHP é Laravel, Ruby é Rails. Na rotina de um time, essa escolha decide mais que a sintaxe. O que já vem pronto no Rails, e que em outros lugares é decisão de projeto: - **Acesso ao banco de dados,** com as tabelas representadas como classes e a evolução do banco versionada em arquivos que acompanham o código. - **Rotas e organização do código,** com um lugar previsível para cada coisa. - **Autenticação e sessão,** sem escolher biblioteca de terceiro para a tarefa mais comum que existe. - **Trabalho em segundo plano,** para o que não pode travar a tela: envio de e-mail, geração de arquivo, chamada a serviço externo. - **Cache, e-mail, armazenamento de arquivo e testes,** cada um com endereço definido. A consequência prática é que o tempo entre decidir uma funcionalidade e tê-la funcionando na tela é curto, porque nenhuma das perguntas de infraestrutura precisa ser respondida de novo. Fora do que vem embutido, existe um ecossistema de bibliotecas prontas para o que se repete em todo projeto: cobrança recorrente, geração de PDF, importação de planilha, painel administrativo, autorização por perfil. São peças mantidas há anos e usadas por muita gente, o que importa mais que a quantidade: biblioteca abandonada é dívida, não atalho. A régua para escolher é a data do último lançamento e quantos projetos dependem dela. ## Convenção sobre configuração, e o que ela custa Rails é o mais opinativo dos três frameworks grandes: ele não oferece opções para as decisões de estrutura, já as tomou. Quem conhece Rails encontra o que procura em um projeto que nunca viu, porque o arquivo está onde tem que estar. A liberdade que se perde é a de organizar cada projeto de um jeito diferente, e vale dizer com clareza que essa perda é real. O ponto é quando ela dói: o custo de cada projeto ter estrutura própria não aparece no primeiro ano, quando o time é o mesmo que escreveu tudo. Aparece no terceiro, quando alguém precisa mexer em código que ninguém do time atual escreveu. Ou seja, o que a convenção compra não é velocidade no começo. É custo de manutenção estável ao longo do tempo, que é a linha que costuma decidir se um produto continua evoluindo ou congela. ## Onde é a escolha certa, e onde não é Rails encaixa quando Rails não é a escolha quando o produto é novo e o time é pequeno há processamento intensivo de cálculo há muita regra de negócio e operação de cadastro o sistema precisa de latência muito baixa o prazo até a primeira versão utilizável é curto o projeto é de dados ou de IA, onde o ecossistema de Python não tem equivalente é provável mudar de direção sem reescrever tudo o time já é fluente em outra stack A última linha da coluna da direita é a mais ignorada. Trocar de framework para ganhar produtividade e perder meses de aprendizado do time é mau negócio mesmo quando o framework novo é melhor no papel. Stack se escolhe uma vez, no começo, ou quando existe motivo grande o suficiente para pagar a migração. ## Rails, Django e Laravel Os três resolvem o mesmo problema e a escolha entre eles raramente é técnica. Rails é o mais opinativo, com o ganho e o custo descritos acima. Django tem a vantagem decisiva de morar no ecossistema de Python, o que importa muito quando o produto tem componente de dados ou de modelo. Laravel tem o maior mercado de profissionais no Brasil e a hospedagem mais barata e disponível. O critério honesto para decidir entre eles é o do time, não o do framework: em qual deles você consegue contratar, manter alguém e ter um segundo par de olhos quando precisar. Um framework excelente sem ninguém disponível para trabalhar nele é risco, não vantagem. O panorama completo das linguagens está em [linguagens de programação](/linguagens-de-programacao/). ## A objeção do mercado de desenvolvedores É a crítica legítima e a mais repetida: há menos gente escrevendo Ruby que Python ou JavaScript. Ela pesa menos do que parece, por dois motivos. O primeiro é que o mercado que importa não é o global: é o de quem você consegue contratar e manter. Número de profissionais no mundo não ajuda quem precisa de duas pessoas boas na sua cidade ou no seu fuso. O segundo é mais interessante, e é consequência da convenção: quando o framework já tomou as decisões de estrutura, o tempo até um desenvolvedor experiente ficar produtivo em um projeto que ele não escreveu é curto. Isso ataca exatamente o problema que a rotatividade cria, que é o custo de entrada de cada pessoa nova. O caminho prático de contratar está em [como contratar desenvolvedores web](/como-contratar-desenvolvedores-web/). ## O mito de que serve só para começar A leitura de que Rails é bom para protótipo e ruim para escala não se sustenta na evidência mais simples: GitHub, Shopify e Basecamp rodam em Rails há mais de uma década, em volume que não tem nada de estágio inicial. O que essa lista mostra não é a marca das empresas. É que produtividade alta e capacidade de escalar não são coisas que se trocam uma pela outra, e que gargalo de aplicação web quase nunca é a linguagem: é consulta mal escrita ao banco, ausência de cache e trabalho pesado feito na hora em vez de em segundo plano. Nenhum desses três problemas se resolve trocando de framework. ## Por que é a nossa stack É a stack em que a Northern constrói: Ruby on Rails no servidor. O motivo é o mesmo que orienta as nossas outras decisões de projeto: o que limita produto digital novo quase nunca é a velocidade da máquina, e quase sempre é quanto tempo leva para uma decisão virar algo funcionando na tela. Isso tem consequência direta em duas coisas que o cliente sente. A primeira é o prazo até existir algo que dá para usar e criticar, em vez de slide. A segunda é o custo de mudar de ideia depois da primeira versão, que é o momento em que quase todo produto descobre que precisa mudar. Como esse cálculo aparece no orçamento está em [quanto custa desenvolver um produto digital](/quanto-custa-desenvolver-produto-digital/), o processo de trabalho em volta em [desenvolvimento de software](/desenvolvimento-de-software/), e o recorte que vem antes de qualquer escolha de tecnologia em [como definir o escopo do primeiro produto digital](/definir-escopo-produto-digital/). Se a dúvida ainda é entre construir e contratar pronto, o corte está em [software house](/software-house-o-que-e-por-que-contratar/). ## Perguntas frequentes ### O que é Ruby on Rails? É um framework para construir aplicações web em Ruby. A diferença dele não está no que permite fazer, e sim no que decide por você: estrutura de pastas, conversa com o banco de dados, rotas, filas, envio de e-mail e onde os testes moram já vêm resolvidos e iguais em todo projeto. Escolher Ruby para web é, na prática, escolher Rails. ### O que já vem pronto no Rails? Acesso ao banco com as tabelas representadas como classes e a evolução do banco versionada em arquivos que acompanham o código. Rotas e organização, com lugar previsível para cada coisa. Autenticação e sessão. Trabalho em segundo plano para o que não pode travar a tela. E cache, e-mail, armazenamento de arquivo e testes, cada um com endereço definido. ### O que é convenção sobre configuração? É o Rails não oferecer opções para as decisões de estrutura, tendo já as tomado. Quem conhece Rails encontra o que procura em um projeto que nunca viu, porque o arquivo está onde tem que estar. A liberdade que se perde é a de organizar cada projeto de um jeito diferente, e essa perda é real. ### Qual o custo da convenção? Perder a liberdade de estruturar cada projeto do seu jeito. O ponto é quando ela dói: o custo de cada projeto ter estrutura própria não aparece no primeiro ano, quando o time é o mesmo que escreveu tudo, e aparece no terceiro, quando alguém mexe em código que ninguém do time atual escreveu. O que a convenção compra não é velocidade no começo, é custo de manutenção estável. ### Quando Ruby on Rails é a escolha certa? Quando o produto é novo e o time é pequeno; quando há muita regra de negócio e operação de cadastro; quando o prazo até a primeira versão utilizável é curto; e quando é provável mudar de direção depois sem reescrever tudo. São as condições da maioria dos produtos digitais em construção. ### Quando Rails não é a escolha? Quando há processamento intensivo de cálculo; quando o sistema precisa de latência muito baixa; quando o projeto é de dados ou de IA, onde o ecossistema de Python não tem equivalente; e quando o time já é fluente em outra stack. Essa última é a mais ignorada: trocar de framework e perder meses de aprendizado é mau negócio mesmo quando o novo é melhor no papel. ### Rails, Django ou Laravel? Os três resolvem o mesmo problema e a escolha raramente é técnica. Rails é o mais opinativo. Django tem a vantagem de morar no ecossistema de Python, o que importa quando o produto tem componente de dados ou de modelo. Laravel tem o maior mercado de profissionais no Brasil e hospedagem mais barata. O critério honesto é o do time: em qual deles você consegue contratar e manter alguém. ### Existem poucos desenvolvedores Ruby? Há menos gente escrevendo Ruby que Python ou JavaScript, e a objeção pesa menos do que parece. Primeiro porque o mercado que importa não é o global, é o de quem você consegue contratar e manter. Segundo porque, quando o framework já tomou as decisões de estrutura, o tempo até alguém experiente ficar produtivo num projeto que não escreveu é curto, o que ataca justamente o custo da rotatividade. ### Ruby on Rails escala? GitHub, Shopify e Basecamp rodam em Rails há mais de uma década, em volume que não tem nada de estágio inicial. O que isso mostra não é a marca das empresas: é que produtividade alta e capacidade de escalar não são coisas que se trocam uma pela outra. Gargalo de aplicação web quase nunca é a linguagem, e sim consulta mal escrita, falta de cache e trabalho pesado feito na hora. ### Por que a Northern usa Ruby on Rails? Porque o que limita produto digital novo quase nunca é a velocidade da máquina, e quase sempre é quanto tempo leva para uma decisão virar algo funcionando na tela. Isso aparece em duas coisas que o cliente sente: o prazo até existir algo que dá para usar e criticar em vez de slide, e o custo de mudar de ideia depois da primeira versão, que é quando quase todo produto descobre que precisa mudar.