Como Contratar um Desenvolvedor Freelancer

A maioria dos projetos de desenvolvimento falhos não foi mal codificada. Eles foram mal especificados, contratados com o sinal errado e entregues de forma tão incompleta que o próximo desenvolvedor teve que começar de novo. A parte técnica raramente é onde o dinheiro desaparece.

Essa é uma boa notícia para um comprador não técnico, porque significa que as decisões mais importantes são aquelas que você está qualificado para tomar. Você não precisa avaliar o JavaScript de alguém para contratar bem. Você precisa ser capaz de descrever o problema com precisão, reconhecer evidências relevantes, fazer perguntas difíceis de blefar e insistir em uma entrega que o deixe com as chaves. Este guia aborda todos os quatro.

Decida o que você realmente está construindo

Comece com o resultado, não com a tecnologia. “Preciso de um aplicativo” não é um briefing; “os clientes precisam reservar e pagar por um horário no telefone, e preciso ver as reservas de amanhã em uma lista” é. A segunda versão pode ser orçada, testada e discutida. A primeira não.

Antes de falar com alguém, anote quatro coisas:

• O trabalho a ser feitoO que um usuário deve ser capaz de realizar que não consegue hoje. Uma frase por capacidade, na linguagem do usuário em vez de uma técnica.
• Os itens essenciaisAs poucas coisas sem as quais a construção é inútil. Se sua lista tiver mais de seis, é uma lista de desejos, não uma especificação.
• O que já existeSite atual, hospedagem, domínio, provedor de pagamento, CRM, planilhas. Cada integração é trabalho, e integrações não declaradas são onde as estimativas falham.
• Quem o mantémSoftware não é uma compra, é um compromisso. Decida agora se você manterá o desenvolvedor, contratará outra pessoa ou o gerenciará você mesmo.

Uma disciplina útil: descreva a primeira versão como a menor coisa que seria genuinamente útil. Todo o resto vai para uma segunda lista. Os desenvolvedores orçam a primeira lista; a segunda lista é o que você financia assim que a primeira estiver gerando receita.

Que tipo de desenvolvedor você precisa

“Desenvolvedor” abrange uma dúzia de ofícios distintos que não são intercambiáveis. Contratar o errado é o erro de categoria mais comum e mais caro neste processo.

• Front-endO que o usuário vê e toca: layout, interação, responsividade, acessibilidade. Contrate para um redesenho, um site de marketing ou uma nova interface em um sistema existente. Veja freelancers de desenvolvimento front-end.
• Back-endDados, lógica, APIs, autenticação, pagamentos. Contrate quando o valor estiver no que acontece depois que o botão é pressionado. Veja freelancers de desenvolvimento back-end.
• Full-stackAmbos, para um padrão de trabalho. A escolha certa para a maioria das pequenas construções, porque a coordenação entre dois especialistas custa mais do que economiza em pequena escala.
• CMS e plataformaWordPress, Shopify, Webflow e similares. Se sua necessidade for atendida por uma plataforma existente, contratar um desenvolvedor personalizado para reconstruí-la é dinheiro queimado. Veja desenvolvimento WordPress e desenvolvimento Shopify.
• MobileiOS ou Android nativo, ou multiplataforma. Uma disciplina genuinamente diferente da web, com suas próprias restrições de revisão e lançamento de loja. Veja desenvolvimento de aplicativos móveis.
• Manutenção e correçõesDepuração, atualizações, desempenho, segurança. Muitas vezes, a contratação de maior valor de todas, e a que os compradores adiam por mais tempo. Veja manutenção de sites.

Se você realmente não consegue dizer qual precisa, isso em si é um trabalho pequeno, barato e bem definido: pague a um desenvolvedor experiente por uma breve conversa de escopo antes de encomendar qualquer coisa.

Escolhendo a tecnologia antes da pessoa

Você não precisa escolher o idioma. Você precisa tomar uma decisão: plataforma ou personalizado. Isso tem mais efeito no seu custo total do que qualquer outra escolha neste guia.

Uma construção de plataforma — WordPress, Shopify, Webflow, uma ferramenta sem código — significa que a maior parte do software já existe e você está pagando pela configuração, design e pelas partes que são específicas para você. É mais rápido, mais barato e mais fácil de entregar à próxima pessoa, porque milhares de desenvolvedores o conhecem. O limite é que você vive dentro das suposições da plataforma.

Uma construção personalizada significa que o software é escrito para você. Ele se encaixa exatamente e custa várias vezes mais para criar e manter, porque apenas a pessoa que o escreveu o conhece até que o documente. Personalizado é a resposta certa quando o que você faz é o produto; é a resposta errada para um site de brochura ou uma loja padrão.

Duas regras práticas. Primeiro, se uma plataforma mainstream faz oitenta por cento do que você precisa, comece por aí e pague pelos vinte por cento que faltam. Segundo, o que quer que seja escolhido, pergunte por quê — um desenvolvedor que não consegue explicar a escolha em termos de suas necessidades está escolhendo o que gosta, não o que você precisa. Se você está avaliando a construção de um site completo, nosso guia de custos de sites estabelece as faixas.

Escrevendo um breve resumo que um desenvolvedor pode citar

Um bom resumo técnico é curto e específico. Ele não diz ao desenvolvedor como construir; ele diz o que deve ser verdadeiro quando ele terminar.

• O problema, em um parágrafo. O que está acontecendo agora e por que não é aceitável.
• As histórias de usuário. “Como cliente, eu posso… para que…”. De cinco a quinze delas é uma especificação real.
• As integrações. Nomeie cada sistema externo pelo nome, incluindo aqueles que você considera triviais.
• O que você está fornecendo. Texto, imagens, designs, logins, dados de teste. Lacunas não declaradas se tornam horas faturáveis.
• Restrições. Prazo, faixa de orçamento, hospedagem em que você deve permanecer, conformidade que você deve atender.
• A definição de pronto. Implantado onde, testado como, documentado em que nível, entregue com o quê.

Inclua uma faixa de orçamento. Os compradores a retêm esperando uma cotação mais baixa; na prática, isso apenas produz propostas voltadas para a escala errada, e você perde uma rodada de correspondência descobrindo isso. Nosso guia para escrever um resumo de projeto que gera ótimas propostas tem um modelo mais completo, e preço por hora vs. preço fixo explica qual modelo de precificação seu resumo está solicitando.

Criando uma lista restrita

Procure de três a cinco candidatos. Menos e você não terá comparação; mais e você não fará a avaliação corretamente em nenhum deles.

Existem duas direções para pesquisar. Comece pelo trabalho se seu trabalho estiver bem definido e você quiser comprar algo específico — navegue por listagens de preço fixo em desenvolvimento de sites, desenvolvimento de software ou aplicativos web, ou por marketplace em web design, desenvolvedores WordPress, desenvolvimento de aplicativos móveis ou especialistas Shopify.

Comece pela pessoa se o trabalho precisar de discussão. Navegue por desenvolvedores por disciplina ou por ferramenta — React, WordPress, PHP, Python ou Webflow — ou publique o resumo e deixe as propostas chegarem até você. No Zinn Hub, publicar um projeto é gratuito, e você pode direcioná-lo para uma área específica, como desenvolvimento de sites, desenvolvimento de back-end ou desenvolvimento de aplicativos móveis.

Filtre rigorosamente pela relevância e levemente por todo o resto. Um desenvolvedor que entregou três coisas como a sua supera um com o dobro da experiência em um domínio diferente, quase sempre.

Como ler um portfólio de desenvolvedor

Você não pode auditar o código de alguém, e não precisa. Um portfólio ainda lhe diz muito se você souber o que procurar.

• Abra os links ativos. Uma captura de tela não prova nada. Carregue o site no seu telefone, use-o, quebre-o. Qualquer coisa quebrada hoje foi aprovada como quebrada.
• Procure problemas como os seus. Não a mesma indústria — a mesma forma. Um fluxo de reserva é um fluxo de reserva, quer venda cortes de cabelo ou helicópteros.
• Verifique o que eles fizeram. Em projetos de equipe, pergunte quais partes eram deles. “Eu trabalhei nisso” pode significar muito ou muito pouco.
• Teste o básico você mesmo. A página carrega rapidamente? Funciona em um telefone? Os formulários são utilizáveis com um teclado? Estes são sinais de habilidade que um comprador não técnico pode ler perfeitamente bem.
• Leia as avaliações como um corpo de evidências. Uma avaliação brilhante é ruído. Um padrão em muitas, especialmente sobre comunicação e prazos, é um sinal. No Zinn Hub, as avaliações exigem uma compra confirmada.
• Pergunte o que deu errado. A resposta mais forte para “fale-me sobre um projeto que deu errado” é uma história específica, pouco lisonjeira e bem analisada. Não existe um desenvolvedor com apenas projetos tranquilos.

Para uma versão sistemática disso, consulte nossa lista de verificação de 12 etapas para seleção de freelancers.

Perguntas a fazer antes de contratar

O objetivo não é pegar ninguém de surpresa. É ouvir como alguém pensa quando a resposta não é ensaiada.

• Explique uma construção anterior“Me guie por um desses projetos e as compensações que você fez.” Um bom desenvolvedor nomeará algo que ele escolheu não fazer e por quê. Jargão sem compensações é um sinal de alerta.
• O que te preocupa aquiPergunte qual é a parte mais arriscada do seu resumo. Qualquer um que diga “nada, é simples” não o leu corretamente.
• O que está faltando“O que você precisaria de mim que eu não forneci?” Candidatos fortes respondem a isso imediatamente e em detalhes.
• Como verei o progressoUm link de staging, uma atualização semanal, um quadro compartilhado. Qualquer resposta está boa; nenhuma resposta não está.
• O que acontece após o lançamentoJanela de bugs, termos de suporte, documentação. Concorde com isso antes de começar, não quando algo quebrar.
• Quem é o proprietário do códigoPergunte diretamente. A resposta deve ser você, na entrega, por escrito, incluindo tudo o que é necessário para executá-lo.

Teste antes de se comprometer

O seguro mais barato disponível para um comprador é um pequeno trabalho pago antes de um grande. Não um teste não remunerado, que bons freelancers recusam e que não diz nada sobre como alguém se comporta quando há dinheiro envolvido — uma tarefa real, pequena e paga.

Uma boa tarefa de teste é representativa, autocontida e pode ser concluída em uma sessão: corrigir um bug específico, tornar uma página responsiva, adicionar um formulário e conectá-lo, melhorar uma página lenta. O que você está realmente avaliando não é o código. É se eles fizeram uma pergunta esclarecedora antes de começar, se entregaram o que foi pedido em vez do que preferiam, se explicaram o que fizeram e se o prazo que deram foi o prazo que você obteve.

No Zinn Hub, o formato natural é um Micro Zinn — uma tarefa de preço fixo por $5, $10, $15 ou $20. Navegue por correções de bugs e pequenas tarefas de código ou correções e ajustes de bugs de sites, ou comece por um preço com $20 Micro Zinns. Nosso guia sobre como testar um freelancer antes de se comprometer aborda como estruturar e julgar o teste.

Quanto custa e como pagar

Os preços de desenvolvimento variam mais do que qualquer outra categoria de freelancer, porque o trabalho varia mais. O que se segue são faixas de mercado típicas para o trabalho completo, não preços do Zinn Hub, e cada freelancer define os seus próprios.

• Pequena tarefa

  Abaixo de $200

  Uma correção de bug, um conflito de plugin, um formulário, um passe de velocidade, um pequeno recurso em uma construção existente. Melhor comprado como uma tarefa de preço fixo.

• Construção padrão

  $500–$2,000

  Um site ou loja baseada em plataforma: configuração de tema, vários modelos de página, formulários, integrações básicas, lançamento.

• Avançado

  $2,000–$8,000

  Funcionalidade personalizada, contas e logins, pagamentos, integrações de terceiros ou um design sob medida implementado do zero.

• Aplicativo

  $8,000+

  Um produto de software real: sistemas multi-função, painéis, aplicativos móveis, qualquer coisa com lógica de back-end significativa e engenharia contínua.

Os custos variam de acordo com o escopo, complexidade e experiência. Use as faixas para verificar a razoabilidade de um orçamento, em vez de como uma tabela de preços — se um número estiver duas faixas de distância de onde seu projeto se encaixa, essa diferença é a conversa que vale a pena ter.

No Zinn Hub, cada Zinn tem um preço definido pelo seu Zinner, os compradores não pagam taxa de plataforma, e todos os preços são em USD com um equivalente aproximado mostrado em sua própria moeda. Um pedido é pago e protegido como um único valor total; não há liberação em etapas ou marcos, então uma construção faseada é feita como pedidos separados ou acordada como fases separadas com preço em seu resumo de projeto. Escolha um Zinner com Proteção de Plataforma e seu pagamento será retido pelo Zinn Hub até que o pedido seja concluído; qualquer reembolso é creditado em sua Zinn Wallet na íntegra, em USD. Zinners que conectam sua própria conta PayPal ou Stripe são pagos diretamente no checkout.

Propriedade, acesso e entrega

Esta é a seção que os compradores pulam e depois se arrependem. Acorde tudo por escrito antes do início do trabalho, porque após a entrega você não terá mais nenhuma alavancagem.

• Contas em seu nome. Domínio, hospedagem e qualquer serviço de terceiros devem ser registrados em seu nome, com o desenvolvedor adicionado como usuário. Nunca o contrário.
• Propriedade do código na entrega. Declare claramente que, mediante o pagamento final, o trabalho é seu para usar, modificar e levar para outro lugar. Pergunte sobre quaisquer componentes de terceiros com suas próprias licenças.
• Acesso ao repositório. Mesmo que você nunca o abra, você deve ser capaz de entregá-lo ao próximo desenvolvedor.
• Credenciais, todas elas. Logins de administrador, chaves de API, acesso ao banco de dados, acesso de implantação — transferidos e confirmados como funcionando antes do pagamento final.
• Documentação. Uma breve nota escrita sobre como implantar, onde as coisas estão e o que fazer se quebrar. Uma página é suficiente; nada não é.
• Uma janela de bugs. Um período definido após o lançamento em que defeitos genuínos são corrigidos sem custo extra. Trinta dias é um pedido comum e razoável.

Os termos de direitos autorais e licenciamento variam por país e por contrato, portanto, trate isso como orientação geral em vez de aconselhamento jurídico e procure aconselhamento profissional sobre qualquer coisa comercialmente significativa.

Erros que afundam projetos de desenvolvimento

• Contratar antes que o briefing exista. Cada hora gasta especificando economiza várias na construção e retrabalho. Nada mais nesta lista importa tanto.
• Escolher apenas pelo preço. O orçamento mais baixo é frequentemente o que menos entendeu, e a diferença aparece como solicitações de mudança.
• Adicionar escopo discretamente. Pequenos pedidos durante uma construção são como preços fixos se tornam disputas. Agrupe-os, precifique-os, decida sobre eles.
• Nenhum ambiente de teste. Revisar o trabalho apenas quando ele está ativo é como um site quebrado é descoberto pelos clientes em vez de por você.
• Pular a verificação móvel. A maioria dos seus visitantes está em um telefone. Não aprove nada que você não tenha aberto em um.
• Deixar a entrega para o final. O momento de concordar com o acesso e a propriedade é antes do primeiro commit, não durante a última fatura.
• Nenhum plano de manutenção. O software apodrece. Orce para atualizações, backups e segurança desde o primeiro dia, ou pague por um resgate mais tarde.
• Ignorar os sinais de alerta. Respostas vagas, pequenos prazos perdidos e pressão para pagar fora da plataforma estão todos cobertos em nosso guia sobre golpes comuns de freelancers.

Se você ainda está decidindo se um freelancer é o caminho certo, freelancer vs agência compara os dois honestamente para uma construção de pequena empresa.