Bajaj
Site institucional da Bajaj, a terceira maior montadora de motos do mundo, com 77 páginas de concessionária e integração com CRM. Entrei para corrigir bugs e acabei reescrevendo a validação de leads, centralizando credenciais e implantando versionamento. Aqui eu conto as três frentes que mudaram a estrutura do projeto.
- PAPEL
- Desenvolvimento full stack, segurança e infraestrutura
- CLIENTE
- Bajaj do Brasil, via TecSinapse
- PERÍODO
- 2026
- STACK
- PHP, JavaScript, jQuery, WordPress, Git, SSH
- TIME
- Sozinha, com repasse ao time de infra
CONTEXTO
Um site grande, sem versionamento e com credencial em texto puro
WordPress com tema customizado. Páginas de modelo de moto, 77 páginas de concessionária, formulários de interesse e test ride, mapa interativo de concessionárias e integração com CRM corporativo por API e Amazon SES.
Atuo na manutenção do site: incluo novas concessionárias, analiso e corrijo bugs, aplico melhorias de segurança e desenvolvo novas páginas e funcionalidades. O que começou como uma fila de tickets virou nove frentes de trabalho. Seis foram correções pontuais, como o mapa de concessionárias com busca por estado, a proteção contra duplo clique e a limpeza de arquivos órfãos no servidor. As outras três mudaram a estrutura do projeto.
LEADS
Um módulo central para os 106 formulários
O time comercial recebia lead com CPF inválido e sem rastreio de origem. A mesma verificação faltava em quatro lugares ao mesmo tempo: o campo HTML só conferia o tamanho, a máscara formatava sem validar, o servidor confiava no que o front mandava, e o endpoint aceitava envio de bot. Escrevi um módulo PHP central e um JavaScript compartilhado. Como as 77 páginas carregavam o mesmo arquivo, um deploy alcançou os 106 formulários.
ANTES
<input name="cpf" pattern=".{11,14}" required>
$("#cpf").mask("000.000.000-00")
if (cpf.length >= 11) enviarLead(form)
// no servidor: nenhuma verificação
DEPOIS - validacao.php
function cpf_valido(string $cpf): bool {
$cpf = preg_replace("/\D/", "", $cpf);
if (strlen($cpf) !== 11) return false;
if (preg_match("/^(\d)\1{10}$/", $cpf)) return false;
return digitos_verificadores_ok($cpf);
}
CREDENCIAIS
113 arquivos com a mesma senha escrita dentro
As credenciais SMTP do Amazon SES estavam escritas direto no código, repetidas em 113 arquivos PHP do tema. Criei um arquivo único de configuração e refatorei os 113 para apontar para lá. Trocar a senha passou a ser uma alteração em um arquivo só.
Depois fiz uma auditoria de segurança e entreguei um relatório com os achados por severidade, separando o que eu podia corrigir sozinha do que precisava do time de infraestrutura. Corrigi o que estava na minha alçada e repassei o resto.
VERSIONAMENTO
De nenhum controle de versão a deploy automático
O site não tinha controle de versão. Toda publicação era manual por FTP, sem histórico, e um desenvolvedor podia sobrescrever o trabalho do outro.
Inicializei o repositório no tema e configurei o ignore para deixar de fora credencial, imagem, log e backup. A limpeza do histórico levou o repositório de 2,68 GB para 3,4 MB. Liguei o deploy automático a cada push e escrevi um guia de versionamento para o time.
ANTES
2,68 GB
repositório com histórico sujo
DEPOIS
3,4 MB
depois da limpeza
RESULTADO
Em números
- 106
- formulários com validação dupla
- 113
- arquivos refatorados para credencial única
- 8
- vetores de segurança auditados
- 83
- formulários protegidos contra duplo clique
- 11
- páginas corrigidas com uma linha de CSS
- 700+
- arquivos órfãos removidos do servidor