Contratando um desenvolvedor Magento freelancer: o que perguntar antes

Sou desenvolvedor Magento freelancer, então leia isto sabendo de que lado da mesa eu estou. Mesmo assim, as perguntas abaixo são as que eu gostaria que um dono de loja me fizesse, porque um desenvolvedor que responde bem a elas é mais fácil de trabalhar junto, e um que foge delas é um risco que dá para perceber cedo.

Contratar para Magento é mais difícil do que para a maioria das plataformas. O código é grande, os erros aparecem como pedidos perdidos em vez de uma página quebrada, e muita gente coloca Magento no perfil depois de ter mexido uma vez. O objetivo desta lista não é pegar ninguém na curva. É descobrir como a pessoa trabalha antes de dinheiro e acessos mudarem de mãos.

Experiência com a sua versão e o seu setup

"Experiência com Magento" cobre muita coisa. Magento 1 e Magento 2 são sistemas diferentes. Open Source e Adobe Commerce compartilham o core, mas diferem em recursos e hospedagem. O Adobe Commerce Cloud tem seu próprio processo de deploy. Frontends Hyvä, Luma e headless exigem habilidades diferentes.

Perguntas que valem a pena:

• Em quais versões do Magento 2 você trabalhou recentemente, e já fez upgrades entre versões minor, por exemplo da 2.4.6 para a 2.4.8?
• Você já trabalhou com o nosso frontend: Luma, Hyvä ou um setup headless com GraphQL?
• Você já trabalhou no Adobe Commerce Cloud, se é lá que estamos hospedados?
• Com quais extensões da nossa loja você já lidou? Conectores de ERP, métodos de pagamento, mecanismos de busca e módulos B2B têm cada um suas manhas.

Certificações ajudam como base, já que as provas testam conhecimento real do framework. Elas não substituem trabalho recente na prática. Pergunte sobre os dois.

Como a pessoa aborda um problema

Um bom teste é descrever um problema real que você tem e perguntar como ela começaria. Você não está procurando uma solução na call. Está ouvindo a ordem dos passos.

Uma resposta sólida costuma começar reproduzindo o problema em um ambiente que não seja de produção, lendo os logs, vendo o que mudou recentemente, e só então mexendo no código. Uma resposta que começa com "vou instalar um módulo que resolve isso" ou "vou só alterar direto no servidor" também diz alguma coisa.

Pergunte também como ela estende o comportamento do core. No Magento 2, a resposta esperada envolve plugins, observers, preferences usadas com moderação e módulos custom. Editar arquivos dentro de vendor/ ou app/code/Magento significa que o próximo upgrade vai desfazer ou quebrar a alteração.

Propriedade do código e onde ele fica

Este é o assunto que donos de loja mais pulam e depois se arrependem.

• De quem é o código escrito para você? O contrato deve dizer que o código custom pertence a você depois de pago. Deixe claro o que fica de fora, como as bibliotecas reutilizáveis do próprio desenvolvedor, e em que termos você pode usá-las.
• Onde está o repositório? O código deve ficar em um repositório Git que seja seu, no GitHub, GitLab, Bitbucket ou similar, com o desenvolvedor adicionado como colaborador. Não na conta do desenvolvedor. Se vocês se separarem, você fica com o histórico.
• Quem tem acesso a quê? Dê a cada pessoa suas próprias contas para o admin, o servidor e o painel de hospedagem. Logins compartilhados não podem ser revogados para uma pessoa sem quebrar o acesso de todo mundo.
• As extensões pagas estão licenciadas para você? Módulos comerciais devem ser comprados com a conta da sua empresa, para que a licença e as atualizações fiquem com a loja.

Ambientes

Pergunte com quantos ambientes ela espera trabalhar. O mínimo para uma loja que vende todo dia:

• Um ambiente local na máquina do desenvolvedor, normalmente baseado em Docker. Warden, DDEV e o docker-magento do Mark Shust são escolhas comuns.
• Um ambiente de staging que bate com a produção em versão do PHP, mecanismo de busca, Redis e RabbitMQ, com uma cópia recente do banco sem dados pessoais dos clientes.
• Produção.

Um desenvolvedor que propõe trabalhar direto em produção "para economizar tempo" está oferecendo economizar tempo na parte fácil e gastá-lo depois em quedas. Existem exceções, como ler logs durante um incidente, mas as alterações devem passar sempre pelo mesmo caminho.

Pergunte também como ela trata os dados dos clientes. Uma cópia do banco para trabalho local deve ter e-mails, endereços e dados relacionados a pagamento anonimizados. Isso importa para a LGPD, a GDPR e leis parecidas, não só como boa prática.

Testes

Pergunte o que "pronto" significa para ela. As respostas possíveis vão de "funciona na minha máquina" a testes automatizados rodando em CI. Para a maioria das lojas pequenas e médias, um meio-termo realista e honesto é:

• Checagens estáticas com PHP CodeSniffer e o coding standard do Magento, e PHPStan onde fizer sentido.
• Testes unitários ou de integração para regras de negócio fáceis de errar, como cálculo de preço, regras de frete ou integrações.
• Uma checklist escrita de testes manuais do caminho crítico: busca, página de produto, adicionar ao carrinho, checkout com cada método de pagamento, pedido no admin, invoice e shipment.

Desconfie dos dois extremos. A promessa de cobertura total de testes com orçamento apertado não será cumprida, e nenhum teste significa que você é o teste.

Deploys

Peça que descreva como o código vai do repositório para a produção. Você quer ouvir algo repetível: um script ou pipeline que instala as dependências, compila, faz o deploy do conteúdo estático e troca para a nova versão, com modo de manutenção só quando o banco muda. Pergunte quanto tempo a loja fica fora do ar em um deploy normal e como ela faz rollback se algo der errado depois do release.

Pergunte quando ela faz deploy. Deploys na sexta à noite e nos seus horários de pico são riscos evitáveis. Um desenvolvedor que levanta isso sem ser perguntado está pensando no seu negócio, não só na tarefa.

Comunicação e preço

• Como ela estima? Preço fechado para trabalho bem definido e por hora para investigação e manutenção é uma divisão comum e justa. Desconfie de preço fechado para algo que ninguém olhou ainda.
• Como reporta o andamento? Atualizações semanais por escrito, um board compartilhado, ou os dois. Você nunca deveria precisar perguntar o que aconteceu com o seu dinheiro.
• Quais são os horários de trabalho e o fuso? Combine como incidentes fora desse horário são tratados, e se isso custa a mais.
• O que acontece quando algo que ela entregou quebra? Um período razoável de garantia para bugs no próprio trabalho é normal. Problemas causados por alterações posteriores de outras pessoas normalmente são cobrados.

Entrega

Todo trabalho termina em algum momento, e a melhor hora de planejar o fim é no começo. Pergunte o que você vai receber quando o trabalho acabar:

• Todo o código no seu repositório, com mensagens de commit que expliquem por que as alterações foram feitas.
• Um documento curto por módulo custom: o que faz, onde é configurado, quais cron jobs ou consumers de fila adiciona e o que depende dele.
• Notas sobre o ambiente: versão do PHP, serviços, configuração do cron, passos de deploy.
• Uma lista de todas as contas e credenciais que ela usou, para você poder rotacionar ou remover.

Um desenvolvedor confortável com essa lista não tem medo de ser substituído. Isso normalmente quer dizer que o trabalho foi feito de um jeito que outra pessoa consegue manter.

Sinais de alerta

• Pede acesso root completo ao servidor e credenciais de admin antes de qualquer acordo, sem plano para staging.
• Não consegue explicar trabalhos anteriores em termos técnicos, só com screenshots.
• Propõe editar arquivos do core ou desabilitar patches de segurança para fazer algo funcionar.
• Não quer commitar código no seu repositório, ou quer manter no dele.
• Dá preço para um projeto grande depois de uma call de cinco minutos.

Um pequeno teste pago

Se você está em dúvida, comece com uma tarefa paga pequena e com resultado claro: uma auditoria da loja, um bug específico ou um plano de upgrade. Isso mostra como o desenvolvedor se comunica, estima e entrega, a um custo que você pode se dar ao luxo de perder. Também dá ao desenvolvedor uma olhada no seu código antes de se comprometer com um preço maior, o que leva a estimativas melhores dos dois lados.

FAQ

Quanto custa um desenvolvedor Magento freelancer?

Os valores variam muito por região e experiência. Compare pelo custo total e pelo risco, não só pelo valor da hora, porque um desenvolvedor experiente muitas vezes termina mais rápido e causa menos problemas em produção.

Devo contratar um freelancer ou uma agência Magento?

Um freelancer serve para manutenção contínua, features específicas e upgrades, com linha direta com quem faz o trabalho. Uma agência serve para projetos grandes que precisam de design, gerência de projeto e vários desenvolvedores ao mesmo tempo.

De quem deve ser o código que um desenvolvedor freelancer escreve?

Seu, depois de pago. Coloque no contrato, mantenha o código em um repositório da sua empresa e compre as licenças de extensões em seu nome.

O que um desenvolvedor Magento deve entregar no fim de um projeto?

Todo o código no seu repositório, documentação curta de cada módulo custom, notas de ambiente e deploy, e uma lista das contas que ele usou para que os acessos possam ser removidos.

Sou o Rodrigo Biazzi, desenvolvedor Magento certificado, trabalhando com Magento e Adobe Commerce há mais de 12 anos. Atendo como freelancer em Magento, de correções pontuais a projetos mais longos. Se esse é o tipo de problema que você tem na sua loja, fale comigo.