Aplicações Laravel e PHP
Aplicações Laravel feitas para serem entregues.
Portais de clientes, cobrança por assinatura, ferramentas internas e as APIs que conectam tudo isso ao resto do que você usa. Tipadas, testadas onde importa e documentadas o suficiente para que você possa me substituir sem drama, que é a única definição honesta de um projeto terminado.
01EscopoO que eu construo
Os tipos de aplicação que isso costuma significar.
Portais para clientes e parceiros
Um lugar onde os seus clientes entram para ver os próprios dados: pedidos, faturas, documentos, consumo, permissões. O difícil raramente são as telas. É o modelo de permissões, a trilha de auditoria e o que acontece quando uma conta precisa de seis usuários com acessos diferentes.
Cobrança por assinatura e por fatura
Planos, cobrança proporcional, prazos de pagamento, régua de cobrança, impostos, faturas em PDF e o relatório de conciliação em que a sua equipe financeira realmente confia. Construo a cobrança sobre um livro-razão de partidas dobradas, e não sobre um total acumulado, porque um total acumulado é impossível de auditar no dia em que alguém contesta uma cobrança.
Ferramentas internas que substituem uma planilha
O fluxo que hoje vive em uma planilha compartilhada, com seus conflitos de versão e aquela única pessoa que entende tudo. Transformar isso em uma aplicação costuma ser o trabalho de maior retorno que uma empresa pode encomendar, e normalmente o menor.
APIs e integrações
Endpoints REST ou GraphQL para o seu próprio front-end, o seu app mobile ou um parceiro. Além do trabalho de integração que conecta o Laravel a tudo o que você usa: um ERP, um CRM, um provedor de pagamentos, um sistema de estoque.
Assumir o código de outra pessoa
Começo esses projetos com uma semana só de leitura: rodar os testes, se existirem, mapear os modelos de domínio e registrar o que encontro, incluindo as partes que me preocupam. Você recebe essa avaliação continuando ou não, então nunca paga só para ouvir que o código está bom.
02MétodoPara onde vai o dinheiro
Em que eu gasto o seu orçamento.
A maioria dos orçamentos de aplicações se perde nos mesmos três lugares, então é para lá que vai o cuidado, e não para as partes que ficam bonitas em uma demonstração.
O modelo de dados, antes de tudo
Decisões de schema são as que não dá para desfazer barato. Uma migração que divide uma tabela em três depois de dezoito meses, com dados reais de clientes e um conjunto de relatórios apontando para ela, é o dia mais caro na vida de um projeto. Prefiro gastar dois dias a mais no schema do que duas semanas a mais nessa migração.
Tudo o que envolve dinheiro ou permissões
Cobrança, papéis e tudo o que escreve em um livro-razão ganham testes. Não por um selo de cobertura, e sim para que a próxima pessoa possa mudar a sua lógica de preços sem quebrar silenciosamente as faturas do trimestre passado. No resto, testo os caminhos difíceis e deixo os óbvios em paz.
O que acontece quando outra coisa quebra
Uma integração não está pronta quando funciona. Está pronta quando se comporta com bom senso enquanto o outro sistema não responde. Isso significa jobs em fila, novas tentativas limitadas, chaves de idempotência e um log de falhas que uma pessoa consegue ler, para que uma tarde ruim de um fornecedor atrase os seus dados em vez de perdê-los.
Nada disso é exótico. É Laravel comum, feito com cuidado. A diferença aparece no segundo ano, que é justamente quando a maioria das agências já foi embora e você descobre o que realmente comprou.
03EntregaO que é seu no final
A entrega não é só a aplicação rodando.
- 01
O repositório
- Na sua organização, não na minha, desde o primeiro commit. Com o histórico intacto e mensagens de commit que explicam o porquê, não só o quê.
- 02
Um documento de arquitetura
- Algumas páginas sobre os modelos de domínio, as decisões que tomei e as alternativas que descartei, e por quê. É o documento que economiza quinze dias do seu próximo desenvolvedor.
- 03
Um ambiente local que funciona
- Um desenvolvedor novo deve ir do clone à aplicação rodando em menos de uma hora, com seeders que geram dados realistas. Se isso leva um dia, o projeto não está pronto.
- 04
Notas de deploy e de rollback
- Como é feito o deploy, quais são as variáveis de ambiente, para onde vão os backups e como voltar atrás às duas da manhã sem precisar me ligar.
04PerguntasFrequentes, respondidas sem rodeios
O que as pessoas perguntam antes de me contratar.
Isso deveria ser uma aplicação Laravel ou um site WordPress?
Se o trabalho principal é publicar páginas que pessoas não técnicas editam, o WordPress costuma ser mais barato e mais rápido. Se o trabalho principal é usuários entrarem e fazerem algo (pedir, agendar, aprovar, gerar relatórios), isso é uma aplicação. Forçar uma aplicação dentro do WordPress geralmente custa mais ao longo de dois anos do que construí-la direito uma vez.
Você consegue assumir um código existente?
Sim, e é uma boa parte do meu trabalho. Começa com uma semana só de leitura que gera uma avaliação por escrito: o que existe, o que é arriscado e o que eu faria primeiro. Esse documento fica com você, seja qual for a sua decisão.
Você escreve testes?
Em tudo o que envolve dinheiro, permissões ou integridade de dados, sim. Não corro atrás de porcentagem de cobertura: uma suíte cheia de testes verificando que getters retornam valores é um custo de manutenção disfarçado de qualidade. A suíte existe para que alguém consiga mudar a sua cobrança sem quebrá-la.
Como você lida com deploy e hospedagem?
Com o que você já tem: uma VPS, Forge, Ploi, Vapor, contêineres. Se você ainda não tem nada, recomendo a opção mais simples que atenda ao seu tráfego. Para a maioria das aplicações de negócio, isso é um servidor bem configurado com backups gerenciados do banco de dados, não um cluster.
Você consegue integrar com o nosso ERP ou CRM?
Normalmente, sim. A pergunta de verdade nunca é se é possível, e sim como a integração se comporta quando o outro sistema está lento ou fora do ar. Jobs em fila com novas tentativas limitadas e um log de falhas legível, para que a queda deles atrase os seus dados em vez de perdê-los.
E se eu precisar de mudanças depois do lançamento?
O repositório e a documentação são seus, então você pode contratar quem quiser. Se preferir continuar comigo, ofereço um pacote mensal de horas. O que tento evitar é me tornar estruturalmente indispensável: uma aplicação que só eu consigo manter é um risco para você, não uma vantagem para mim.
Próximo passo
Descreva o fluxo que você quer substituir.
Mesmo uma descrição aproximada já me basta para dizer se é um trabalho de duas semanas ou de dois trimestres, e quais partes você poderia deixar de fora da primeira versão.