As sete perguntas que revelam se um estúdio vai entregar

Procure como contratar quem desenvolva seu aplicativo e você vai encontrar sempre a mesma lista: verifique o portfólio, desconfie de preço baixo demais, exija contrato, não contrate o primeiro que aparecer. Nada disso é errado. Também nada disso é utilizável na terça-feira, numa reunião, com alguém do outro lado da mesa dizendo coisas que você não tem como conferir.

O problema é que esse conselho descreve o resultado — “escolha uma empresa boa” — sem dar o instrumento. Portfólio bonito qualquer um monta. Contrato todo mundo assina. O que separa um fornecedor do outro não aparece no material de vendas: aparece na forma como ele responde a perguntas específicas, sobretudo as que ele preferiria que você não fizesse.

As sete abaixo são as que mais revelam. Para cada uma há uma resposta que deveria te deixar tranquilo e uma que deveria te fazer pedir a próxima reunião.

A única resposta aceitável é: seu, com o repositório e todo o histórico, desde o primeiro dia. Não ao final, não mediante quitação, não “podemos providenciar uma cópia”.

Cópia do código no fim não é a mesma coisa que o repositório. O histórico é o que permite a outra equipe entender por que cada coisa está do jeito que está — sem ele, quem herdar o projeto recebe uma fotografia sem legenda e vai cobrar por semanas de arqueologia.

Resposta ruim: “o código é nosso, você licencia o uso”. Isso existe e é legítimo em produto de prateleira. Em desenvolvimento sob medida, que você está pagando integralmente, significa que trocar de fornecedor implica recomeçar.

As contas de desenvolvedor da Apple e do Google devem estar no CNPJ da sua empresa, com você como titular. O estúdio entra como acesso, não como dono.

Esta é a pergunta que mais pega gente desprevenida, porque parece burocracia. Não é. Quem controla a conta controla o aplicativo publicado: atualizações, preço, respostas a avaliações e, no limite, a própria existência dele na loja. Recuperar um app de uma conta de terceiros é possível e é um processo demorado, no meio do qual seu produto fica parado.

Resposta ruim: “publicamos na nossa conta, é mais rápido”. É mais rápido mesmo, e é rápido justamente porque pula a parte que te protege.

Note que a pergunta não é “se”. Escopo muda em praticamente todo projeto, e a diferença entre um fornecedor bom e um ruim não é evitar a mudança — é o que ele faz quando ela aparece.

A resposta que você quer ouvir descreve um procedimento: a mudança é avaliada, orçada e aprovada antes de entrar, e o prazo é recalculado junto. A que você não quer ouvir é “a gente encaixa”. Encaixar é o que produz o projeto que atrasa três meses sem que ninguém consiga apontar a semana em que ele começou a atrasar.

Um teste rápido: pergunte quantas vezes o escopo mudou no último projeto e o que foi feito. Quem já viveu isso responde com um exemplo concreto em dez segundos. Quem nunca lidou com o assunto responde com uma afirmação sobre metodologia ágil.

Em estúdio pequeno, as pessoas que aparecem na reunião de venda costumam ser as que vão construir. Em estrutura maior, frequentemente não são — e isso não é necessariamente ruim, desde que seja dito.

O que você quer saber é: essa pessoa vai estar no projeto do começo ao fim, ou vai apresentar e sumir? Quantos projetos simultâneos ela toca? Se sair da empresa no meio, o que acontece?

Resposta ruim é qualquer variação de “temos um time”. Time não responde e-mail; pessoa responde. Você tem o direito de saber o nome de quem vai decidir como a sua tela funciona.

Aplicativo não termina na publicação, e essa é a parte que quase nunca entra na conversa de venda. Todo ano a Apple e o Google lançam versões novas dos sistemas, e o que funcionava pode quebrar sozinho — sem ninguém ter tocado no código.

Você precisa saber, por escrito, duas coisas: por quanto tempo o que aparecer é corrigido sem custo adicional, e como funciona a evolução depois disso — pacote de horas, contrato mensal, orçamento por demanda.

Resposta ruim: silêncio, ou “aí a gente vê”. Traduzido: você vai descobrir o preço da manutenção no momento em que tiver menos poder de negociação, que é quando o aplicativo já está no ar e quebrado.

Não peça o portfólio. Peça o link da loja. Baixe. Use por cinco minutos.

Imagem de tela é fácil de produzir e não prova nada — inclusive porque muita imagem de portfólio é de projeto que nunca foi publicado, ou que foi publicado e saiu do ar. O aplicativo instalado no seu telefone prova que alguém atravessou a revisão da Apple, lidou com contas, certificados e política de privacidade, e chegou até o fim.

Enquanto estiver com ele aberto, olhe a data da última atualização e as avaliações. Um aplicativo sem atualização há dois anos com avaliações reclamando de travamento diz algo sobre o que acontece depois da entrega.

E vale para nós: se um estúdio não consegue te mandar um link de loja de algo que construiu, é justo perguntar por quê.

Esta é a pergunta ao contrário, e ela revela mais do que as outras seis juntas: você está testando se o fornecedor sabe dizer não.

Uma boa resposta é específica e provavelmente menor do que você espera — quem vai usar, qual problema, o que precisa acontecer na primeira versão. Uma boa resposta também costuma incluir alguma coisa que você trouxe e que deveria ficar de fora da primeira versão.

Resposta ruim: “traz que a gente faz”. Fornecedor que aceita qualquer escopo sem discutir não está sendo prestativo; está adiando a conversa difícil para o meio do projeto, quando ela custa dinheiro em vez de custar uma reunião.

Depois das perguntas, o contrato. Cinco itens que costumam faltar e que valem uma leitura atenta: propriedade do código-fonte e a entrega do repositório; titularidade das contas das lojas; o procedimento para mudança de escopo, incluindo como o prazo é recalculado; o período de garantia depois do lançamento e o que ele cobre; e como o projeto termina se qualquer um dos lados quiser encerrar antes.

O último é o mais desconfortável e o mais importante. Um contrato que não descreve como as partes se separam é um contrato escrito supondo que nada vai dar errado — o que é uma suposição estranha para um documento que só existe para o caso de dar.