Antes de pedir orçamento a um dev Magento, mande estes 9 dados da loja

Por que o dev precisa desses dados antes de estimar

Imagine um pedido de orçamento para uma loja que já está no ar: "quero um campo de CPF no cadastro, quanto fica?". A resposta honesta depende de coisas que a frase não diz. Em que versão a loja está? O tema é Luma ou Hyvä? Já existe módulo de terceiros mexendo no cadastro? Tem ERP que precisa receber esse campo?

Sem essas respostas, o dev tem duas saídas ruins: estimar com margem larga para cobrir o que não sabe, ou pedir acesso à loja antes de existir contrato. Com elas, a estimativa fica mais estreita, e você compara propostas que partem do mesmo retrato da loja. Se ainda não sabe que tipo de profissional a demanda pede, veja antes o que faz um programador Magento e os quatro perfis.

Os 9 dados e onde encontrar cada um

Os comandos rodam na pasta raiz da loja, a mesma do bin/magento. Quem tem acesso ao servidor (a hospedagem ou o dev atual) consegue tirar tudo de uma vez.

Como descobrir a versão, a edição e listar os módulos instalados sem cair em armadilha

Três detalhes que fazem o inventário sair errado:

• A versão não diz a edição. O bin/magento --version imprime Magento CLI seguido do número, e esse nome vem fixo no próprio arquivo bin/magento. Quem diz se a loja é Magento Open Source ou Adobe Commerce é o pacote no composer.json: product-community-edition é Open Source; product-enterprise-edition é Adobe Commerce.
• O PHP do terminal pode não ser o do site. Um servidor pode ter mais de uma versão de PHP instalada, e o php -v mostra só a do terminal. Confirme no painel da hospedagem qual versão atende o site.
• Nem todo módulo fora de Magento_ é de terceiro. Conferi a árvore de dependências do pacote padrão do Magento Open Source 2.4.8-p4: ele já traz sete módulos com nome começando por PayPal_Braintree, que podem aparecer no filtro. E não esqueça o --enabled: sem ele, o comando lista também os módulos desativados, em dois blocos com cabeçalho, e o filtro mistura tudo. O que interessa é o que sobra depois dos PayPal_Braintree.

O modo de execução merece uma linha à parte. O deploy:mode:show responde Current application mode: seguido de default, developer ou production. Loja no ar fora de production é informação que muda o orçamento, porque trocar o modo mexe no deploy e no desempenho.

E se eu não tiver acesso SSH?

Dá para começar pelo admin. Ele responde direto quatro dos nove dados: a versão no rodapé, o tema, as lojas e idiomas e as integrações cadastradas. Também mostra o cache de página, no caminho do item 9, e dá uma pista da edição pelo menu Content > Elements: a documentação da Adobe diz que Dynamic Blocks é recurso exclusivo do Adobe Commerce e não existe no Magento Open Source.

O resto você pede a quem tem acesso ao servidor. Mande a lista de comandos da tabela e peça a saída colada como texto, não como print. Você não precisa entender o resultado; o dev que vai orçar entende.

Uma ressalva sobre o item 8: a tela Integrations mostra só o que foi cadastrado ali, com token. Integração feita por módulo próprio não aparece nela. Por isso, liste também, com as suas palavras, quais sistemas conversam com a loja: ERP, emissor de nota, gateway, frete, marketplace.

Preciso dar acesso à loja para receber orçamento?

Não. Tudo neste inventário é informação, não credencial. Senha do admin, usuário do servidor, o arquivo app/etc/env.php e cópia do banco ficam fora do pedido de orçamento. Acesso entra depois, com contrato, usuário próprio para o dev e só nas áreas da tarefa.

Se o dev insistir em entrar na loja para dar qualquer número, peça que ele diga quais dados faltam. Com o inventário completo, muitas demandas já dão para estimar; o que não der pode virar uma etapa paga de diagnóstico, com escopo próprio.

Modelo de mensagem para pedir orçamento a programador Magento

Copie, preencha e mande junto com a descrição da demanda:

Assunto: Pedido de orçamento - loja Magento

O que eu preciso:
(descreva a mudança, com exemplo e print da tela atual)

Inventário da loja:
1. Versão:
2. Edição (Open Source ou Adobe Commerce):
3. PHP do site:
4. Modo (deploy:mode:show):
5. Módulos de terceiros ativos (lista em anexo):
6. Tema aplicado:
7. Lojas e idiomas:
8. Sistemas integrados (ERP, frete, pagamento, marketplace):
9. Hospedagem, staging e cache (Built-in ou Varnish):

Prazo desejado:
Quem aprova do meu lado:
Acesso: só depois do contrato, com usuário próprio.

A linha "quem aprova do meu lado" parece detalhe, mas evita que a proposta volte com perguntas que ninguém responde. Se a loja tiver algo fora do comum, como vários sites no mesmo admin ou um checkout de terceiros, escreva numa linha no fim.