Nem todo projeto justifica construir um backend próprio do zero. Firebase é minha escolha quando o objetivo é validar uma ideia rápido, ou quando o escopo do projeto realmente não pede a flexibilidade de um Laravel completo com banco relacional próprio.
Quando escolho Firebase
Autenticação pronta, banco em tempo real e hospedagem simples resolvem uma boa fatia de projetos pequenos e MVPs sem exigir infraestrutura própria. Para um protótipo que precisa validar se uma ideia tem tração antes de qualquer investimento maior, Firebase reduz o tempo entre a ideia e o primeiro usuário testando.
Um caso típico: um cliente quer testar se um app simples de agendamento tem demanda antes de investir em um sistema completo. Com Firebase, consigo entregar autenticação, banco de dados e notificações em uma fração do tempo que levaria construindo cada uma dessas peças do zero em Laravel — e se a ideia não vingar, o custo de ter testado foi baixo.
Onde ele para de fazer sentido
Regras de negócio complexas, relatórios com consultas relacionais elaboradas, ou qualquer sistema que vá crescer em regras de domínio específicas — aí o modelo do Firebase começa a atrapalhar mais do que ajudar. É o mesmo raciocínio que uso para SQLite: a ferramenta certa depende do problema, não de qual é mais popular no momento.
O ponto de não retorno
Existe um momento em que migrar de Firebase para um backend próprio custa mais do que teria custado construir certo desde o início. Por isso decido isso logo no começo do projeto, não no meio — a mesma decisão que descrevo com mais detalhe em Como decido entre construir do zero ou usar uma solução pronta.
