O texto anterior inventou uma diferença
A versão de 2019 afirmava: "diferente dos desenvolvedor web, este mesmo foca em melhorar a qualidade dos sites de seus clientes". A frase tem erro de concordância, um "este mesmo" que não se sabe a quem se refere — e, principalmente, afirma uma diferença sem dizer qual é.
O texto também abria com um parágrafo inteiro sem oração principal, listava "programadores de computadores" e "programadores de máquinas" como categorias, e tinha uma seção chamada "Mais" cujo conteúdo começava com "No Brasil pode-se encontrar os melhores programadores web de toda a ragião".
A pergunta que ele levantou sem responder é boa e é o que quase todo mundo quer saber ao ler uma proposta. Vamos a ela.
Correção: são o mesmo trabalho
Programador web e desenvolvedor web descrevem a mesma função. Os dois escrevem e mantêm o código que faz um site funcionar, e o mercado brasileiro usa os termos de forma intercambiável — na mesma vaga, na mesma proposta, às vezes no mesmo parágrafo.
Existe uma tentativa de distinção que circula: a de que "desenvolvedor" participaria também de análise e arquitetura, enquanto "programador" apenas executaria o que foi definido. Essa separação não é adotada de forma consistente por ninguém. Você encontrará profissionais chamados de programador fazendo arquitetura e desenvolvedores apenas executando.
A consequência prática é direta: não escolha pelo título. O que o profissional faz está no escopo do contrato — e o detalhamento das atividades do dia a dia está em o que faz um desenvolvedor web.
Correção: código único não evita invasão
Havia uma segunda afirmação errada no texto antigo: "os códigos de definição de um site são de grande importância para que o mesmo continue sendo personalizado e único, evitando também possíveis invasões".
Isso é o que se chama de segurança por obscuridade — a ideia de que algo é seguro porque é desconhecido. Não funciona, por dois motivos. Ataques automatizados varrem endereços testando falhas conhecidas sem se importar com quem construiu o site. E código próprio, escrito por poucas pessoas e revisado por menos ainda, costuma ser menos seguro que software amplamente usado, cujas falhas são encontradas e corrigidas por uma comunidade grande.
O que protege é conhecido e não tem nada de exclusivo: atualização em dia, controle de acesso, senha forte com dupla verificação, backup testado e boas práticas de código. Os limites de cada camada estão em firewall: o que ele não consegue barrar.
Por que os títulos não são padronizados
Vale entender a raiz da confusão, porque ela explica por que a pergunta "programador ou desenvolvedor?" nunca terá resposta definitiva.
Não existe autoridade que defina cargos de tecnologia. Diferente de profissões regulamentadas, onde um conselho estabelece o que cada título significa e o que ele permite fazer, aqui os nomes surgem do uso, da tradução do inglês e do que cada empresa decide colocar no crachá.
O resultado é que dois profissionais com o mesmo título podem fazer coisas completamente diferentes — e dois títulos diferentes podem descrever exatamente o mesmo trabalho. Currículos e propostas refletem isso: o título é uma pista fraca, o escopo é a informação real.
Os 6 títulos e o que significam
Com a ressalva de que nada disso é regra, estes são os usos mais frequentes:
- Programador web / Desenvolvedor web. O mesmo trabalho: escrever e manter o código do site ou sistema.
- Engenheiro de software. Costuma indicar alguém que também decide como o sistema é estruturado, e não apenas o implementa. É o título mais associado a projetos maiores.
- Analista de sistemas. Título mais antigo, ligado a levantar requisitos e desenhar a solução antes da construção. Ainda comum em empresas tradicionais e no setor público.
- Web designer. Decide como o site se parece e como a informação se organiza. Não é quem constrói — e é a confusão mais cara, tratada adiante.
- Full stack. Indica quem atua nos dois lados, front-end e back-end. Diz respeito à abrangência, não ao nível de senioridade.
- Tech lead, arquiteto. Quem decide a estrutura do sistema e orienta tecnicamente o time. Aparece em projetos com várias pessoas.
Web designer não é programador
Esta é a distinção que realmente muda o resultado de um projeto, e ela é ignorada com frequência.
O web designer decide como fica: a estrutura das páginas, a hierarquia da informação, o layout, a tipografia, o comportamento visual em telas diferentes. O programador constrói o que foi decidido: transforma isso em páginas que funcionam, respondem, validam e carregam.
São competências distintas, e há profissionais que fazem as duas — o que não as torna a mesma coisa. Contratar quem desenha esperando quem constrói, ou o contrário, é a origem de metade dos projetos travados: o entregável não é o esperado, e a lacuna só aparece no fim.
O sinal de alerta na conversa: quando o profissional fala apenas de aparência e nunca de comportamento, ou apenas de tecnologia e nunca de quem vai usar, provavelmente falta a outra metade. O trabalho do lado do design está em o que faz um profissional de web design.
Front e back: o que muda na proposta
A distinção que aparece em orçamentos e que vale entender antes de assinar:
Front-end é tudo o que roda no navegador de quem visita — as páginas, o layout, o comportamento dos elementos, a adaptação à tela. Back-end é o que roda no servidor: banco de dados, regras de negócio, integrações, autenticação, envio de e-mails.
Na prática, isso define o tamanho do projeto. Um site institucional pode viver quase inteiramente de front-end, com um formulário simples. Qualquer coisa com login, cadastro, pedido, pagamento ou área restrita exige back-end — e a diferença de esforço entre os dois cenários é grande.
Por isso a proposta precisa dizer, com todas as letras, quem cobre cada lado. É o item que mais gera surpresa quando fica implícito.
O que acontece quando falta um dos dois
Projetos raramente falham por incompetência técnica. Falham por lacuna de escopo — e as lacunas têm sintomas reconhecíveis:
- Falta design. O site funciona e parece um formulário. Ninguém entende o que a empresa faz, porque não houve quem organizasse a informação.
- Falta front-end de qualidade. Bonito no computador, quebrado no celular. Ou lento, porque as imagens e os recursos nunca foram tratados.
- Falta back-end. O formulário existe e o e-mail não chega; a área de cliente é uma promessa que ficou para "a segunda fase".
- Falta conteúdo. O mais comum de todos: o site fica pronto e o projeto trava esperando textos e fotos por meses.
Reconhecer qual peça falta é mais útil que discutir títulos, porque cada uma tem uma solução diferente.
O que ninguém do time faz
Há quatro coisas que a empresa costuma achar que estão contratadas e não estão — e nenhuma delas é trabalho de programador:
- Escrever o conteúdo. Textos, títulos e descrições dependem de quem conhece o negócio. Programador monta a página; não sabe o que a empresa vende nem por quê.
- Decidir posicionamento e preço. São decisões de negócio, tomadas antes de qualquer código.
- Estratégia de conteúdo e busca. Definir sobre o que escrever e para quem é outro trabalho, tratado em a importância do blog para o site.
- Manutenção contínua. Atualizações, backup e correções só acontecem se estiverem contratadas. Entrega não inclui manutenção por padrão.
Essas quatro lacunas são a causa mais frequente de site entregue e abandonado — e nenhuma delas se resolve trocando de programador.
Quantas pessoas um site precisa
A resposta honesta raramente é "uma", e vale por competência em vez de por pessoa:
Site institucional simples: três competências — design, conteúdo e desenvolvimento. Podem estar em duas ou três pessoas.
Site com blog e formulários: as mesmas três, mais alguém responsável por publicar e manter depois da entrega.
Loja virtual ou sistema com cadastro: acrescenta back-end, integrações de pagamento e testes — e, quase sempre, mais de uma pessoa em desenvolvimento.
O erro comum não é subestimar a complexidade técnica: é contratar só a construção e descobrir, no meio do caminho, que faltavam o conteúdo e a manutenção.
Quando uma pessoa só resolve
Em projetos pequenos e bem definidos, uma pessoa cobrindo tudo funciona bem e sai mais barato. É comum e legítimo.
O risco não é técnico — é de continuidade. Quando uma pessoa concentra design, código e manutenção, férias, doença, um cliente maior ou uma mudança de rumo interrompem o projeto inteiro. E é frequente que ninguém mais entenda como o site foi construído.
Três precauções reduzem esse risco sem encarecer: acessos em nome da empresa, não da pessoa; documentação mínima de onde está cada coisa e como publicar; e código e arquivos entregues, não apenas o site no ar. É a mesma lógica de governança tratada em site corporativo.
Como ler uma proposta técnica
Sem saber programar, cinco itens revelam se a proposta está completa:
- Escopo em páginas ou funcionalidades, nomeadas uma a uma — não "site institucional completo".
- O que não está incluído, dito explicitamente. Uma proposta sem essa seção vai gerar discussão depois.
- Quem fornece conteúdo e em que prazo. É o item que mais atrasa projetos.
- O que acontece com o código e os acessos — em nome de quem ficam, e o que você leva se a relação terminar.
- Manutenção depois da entrega: incluída, contratada à parte ou inexistente. Nunca "combinamos depois".
Uma proposta que responde os cinco é comparável com outra. Uma que responde dois é um risco disfarçado de preço melhor.
O que perguntar em vez do título
Voltando à pergunta que abre o texto: em vez de perguntar se a pessoa é programadora ou desenvolvedora, três perguntas resolvem.
"O que exatamente está incluído e o que não está?" Substitui qualquer discussão de nomenclatura por escopo verificável.
"Quem faz o que não está incluído?" Revela as lacunas antes que elas travem o projeto — e deixa claro se a empresa vai precisar contratar mais alguém.
"O que acontece depois da entrega?" Manutenção, acessos, prazo de suporte e o que fazer quando algo quebrar.
Respondidas por escrito, essas três tornam o título irrelevante — que é exatamente o que ele deveria ser.
Perguntas frequentes
O que faz um programador web?
Escreve e mantém o código que faz um site ou sistema funcionar: as páginas que o visitante vê, a lógica que roda no servidor, as integrações com outros serviços e a correção do que quebra. É o mesmo trabalho descrito por "desenvolvedor web" — os dois termos são usados de forma intercambiável no mercado brasileiro.
Qual a diferença entre programador e desenvolvedor web?
Na prática, nenhuma. Há quem defenda que desenvolvedor participa também de análise e arquitetura enquanto programador só executa, mas essa separação não é adotada de forma consistente por ninguém — não existe autoridade que padronize cargos de tecnologia. Vale olhar o escopo descrito, não o título.
Web designer é a mesma coisa que programador?
Não, e essa é a confusão mais cara. Web designer decide como o site se parece e como a informação se organiza; programador constrói o que foi decidido. Alguns profissionais fazem as duas coisas, mas são competências distintas — contratar quem desenha esperando quem constrói é a origem de metade dos projetos travados.
O que é front-end e back-end em um orçamento?
Front-end é tudo o que roda no navegador: as páginas, o layout, o comportamento dos elementos. Back-end é o que roda no servidor: banco de dados, regras, integrações, autenticação. Um site institucional pode viver quase só de front-end; qualquer coisa com login, pedido ou cadastro exige os dois — e a proposta precisa dizer quem cobre cada lado.
Quantas pessoas são necessárias para fazer um site?
Depende do escopo, e a resposta honesta raramente é "uma". Um site institucional envolve pelo menos design, conteúdo e desenvolvimento — três competências, que podem estar em duas ou três pessoas. Um sistema com cadastro e pagamento acrescenta back-end e testes. O erro comum é contratar só a construção e descobrir que faltavam as outras.
Uma pessoa só consegue fazer tudo?
Consegue em projetos pequenos e bem definidos, e é comum que faça. O risco não é técnico: é de continuidade. Quando uma pessoa concentra design, código e manutenção, férias, doença ou saída interrompem tudo — e é frequente que ninguém mais entenda como o site foi construído. Documentação e acesso próprio reduzem esse risco.
Código exclusivo é mais seguro?
Não. A ideia de que um código único e personalizado evita invasões é uma falácia conhecida como segurança por obscuridade. Ataques automatizados testam falhas conhecidas em qualquer endereço, e código próprio mal escrito costuma ser menos seguro que software amplamente usado e revisado. O que protege é atualização, controle de acesso e boas práticas.
O que o programador não faz?
Não escreve o conteúdo do site, não define posicionamento nem preço, não decide o que a empresa vende e não faz a estratégia de conteúdo. Também não é ele quem mantém o site atualizado depois, a menos que isso esteja contratado. Essas quatro lacunas são a causa mais comum de projeto entregue e abandonado.
O que perguntar antes de contratar?
Três perguntas dizem mais que qualquer título: o que exatamente está incluído e o que não está; quem faz o que não está incluído; e o que acontece depois da entrega, em manutenção e em acesso. Se as três forem respondidas por escrito, o título no contrato deixa de importar.