Contratar desenvolvedor remoto no Brasil: o que muda

A pergunta certa não é se desenvolvimento remoto funciona, funciona, é assim que a maior parte do software do mundo é feita hoje. A pergunta é o que muda na sua responsabilidade como contratante. E a resposta é: muda a disciplina de acompanhamento. Presencialmente, você percebe que um projeto está travado pelo clima na sala. Remotamente, você só percebe se criou os pontos de verificação de propósito.

Este texto lista o que precisa existir para o remoto dar certo.

O que não muda

Vale começar por aqui, porque boa parte do receio é infundado.

A execução técnica é idêntica. Código é escrito no editor, versionado em repositório, revisado em pull request e implantado em servidor, o mesmo fluxo, esteja o desenvolvedor no andar de baixo ou em outro estado. Ninguém programa melhor por estar na sua sala.

A relação contratual também é idêntica entre empresas brasileiras: nota fiscal de serviço, ISS recolhido no município do prestador, mesma legislação, foro definido em cláusula. Não há complicação fiscal relevante em contratar de outro estado.

E o fuso é o mesmo em quase todo o país. A maior diferença horária dentro do Brasil é de duas horas em relação ao Acre, e mesmo isso raramente aparece na prática.

O que muda de verdade

Sinais fracos somem. No escritório, você vê a pessoa travada, ouve a reclamação sobre a API que não responde, percebe o desconforto na reunião. À distância, esses sinais só existem se alguém os escrever. Por isso o ritmo precisa ser explícito.

"Quase pronto" dura mais tempo. Sem entrega frequente em ambiente acessível, é fácil um projeto ficar 80% pronto por dois meses. A correção é estrutural: entrega em homologação a cada duas ou três semanas, sempre.

A documentação vira infraestrutura, não luxo. Decisão combinada por voz e não registrada desaparece. Toda mudança de rumo precisa de registro escrito, nem que seja uma mensagem no canal.

A dependência de uma pessoa fica mais perigosa. Se o único desenvolvedor sabe implantar o sistema e não escreveu como, você tem um refém contratado. Exija documentação de deploy junto com a entrega, não depois.

O ritmo mínimo que faz funcionar

Trinta minutos por semana bastam se houver disciplina. O que não funciona é reunião de duas horas quando alguém lembra.

O item que mais atrasa projeto não é o fornecedor

É a ausência de um responsável interno com tempo alocado. Todo projeto gera dúvidas de regra de negócio, "e quando o cliente tem dois contratos ativos?", "quem pode aprovar acima de tal valor?". Se essas perguntas ficam três dias sem resposta, o desenvolvedor ou para ou adivinha. As duas opções custam caro.

O que essa pessoa precisa ter:

• Tempo real reservado, algumas horas por semana, não "além das outras funções".
• Autoridade para decidir regra de negócio sem escalar tudo.
• Compromisso de responder dúvidas em até 24 horas úteis.
• Acesso ao ambiente de homologação e disposição para testar.

Sem isso, nenhum fornecedor entrega no prazo, remoto ou presencial.

Como acompanhar sem entender de código

Ignore relatório de horas e percentual de conclusão. Acompanhe por funcionalidade em uso:

• Ruim: "o módulo de pedidos está 70% concluído".
• Bom: "você já consegue criar um pedido, editar e ver na listagem; falta aprovar e cancelar".

Peça sempre a segunda forma. Ela é verificável, você entra no ambiente de homologação e testa. A primeira é opinião.

Outro indicador útil: com que antecedência o fornecedor avisa de problema. Quem avisa na sexta que a integração vai atrasar duas semanas está gerenciando. Quem avisa no dia da entrega estava torcendo.

O contrato, em itens

• Cessão de direitos patrimoniais sobre código, scripts, migrações e configuração de infraestrutura.
• Contas em nome da sua empresa: repositório, servidor, domínio, serviços de terceiros. Nada em e-mail pessoal de terceiro.
• Acesso ao repositório desde o primeiro dia, não na entrega final. Isso não é desconfiança; é continuidade.
• Garantia de 60 a 90 dias para correção de defeito sem custo, com definição escrita do que é defeito e do que é mudança de requisito.
• SLA por gravidade: sistema fora do ar tem prazo diferente de ajuste de layout.
• Cláusula de saída: documentação de arquitetura e deploy, transferência de acessos, período de acompanhamento na transição.
• LGPD: quem é controlador, quem é operador, onde os dados ficam e o que acontece com eles no fim do contrato.

Fornecedor sério aceita todos esses itens sem discussão. Resistência a qualquer um deles é informação.

Como começar com risco baixo

Contrate um recorte pequeno e pago antes do projeto inteiro, uma integração, um módulo, uma automação, com entrega em quatro a seis semanas e escopo escrito.

Por uma fração do valor total você descobre o que nenhuma proposta revela: se o fornecedor estima com honestidade, se comunica com clareza e o que faz quando algo dá errado. Se as três respostas forem boas, feche o resto. Se não, você perdeu semanas em vez de meses.

A Retti Tech atende empresas em todo o Brasil e em Portugal remotamente, com esse mesmo formato. A localização do fornecedor deixou de ser o critério relevante faz tempo; o que decide é se existe processo de trabalho dos dois lados.