Desenvolvimento de app e produto digital: o que separa um protótipo de algo que aguenta cliente

O que “pronto” quer dizer

Um protótipo está pronto quando alguém consegue ver a ideia. Um produto está pronto quando um estranho consegue usá-lo sem você por perto, e continua conseguindo amanhã. A distância entre as duas definições é quase todo o custo de um projeto — e ela é invisível na apresentação, que é justamente onde as duas se parecem.

Essa confusão ficou mais cara desde que gerar a interface deixou de ser trabalho. Quando a tela aparece em uma tarde, a sensação é de que o produto está a 80% do caminho. Está a 80% da parte que se vê, que costuma ser a menor.

Os quatro caminhos

Há quatro caminhos para construir um produto digital — no-code, software house, time próprio e time pequeno com IA —, e eles se distinguem pelo que cobram. O no-code cobra a propriedade da plataforma; a software house cobra o ciclo; o time próprio cobra tempo e caixa antes da primeira linha; o time pequeno com IA cobra o critério de quem dirige.

Os quatro se misturam ao longo da vida de um produto, e a sequência mais comum é a mais barata: descobrir em no-code, construir o primeiro corte com um time pequeno, e montar time próprio quando o produto já provou que merece um.

O que toda demonstração esconde

Toda demonstração esconde as mesmas seis coisas: autenticação de verdade, pagamento que concilia, permissão entre usuários, o caso de erro, o tratamento do dado de cliente e o plantão. Elas somem da apresentação porque nela existe um usuário só, que é o dono, e nada dá errado.

• Autenticação de verdade. Recuperação de senha, sessão que expira, dois fatores, alguém que perdeu o acesso ao e-mail.
• Pagamento que concilia. Cobrar é a parte fácil. Estorno, assinatura que falha, imposto e o relatório que fecha com o banco é o trabalho.
• Permissão. Quem vê o quê. Some da demonstração porque nela só existe um usuário, que é o dono.
• O caso de erro. Rede caindo no meio, duplo clique, arquivo gigante, dado que já existia.
• Dado de cliente. Onde fica, quem alcança, por quanto tempo, e o que acontece quando alguém pede exclusão.
• O plantão. Cair às duas da manhã é evento normal. Não ter quem atenda é que é a escolha.

A lista não é um argumento contra demonstrações rápidas — é o que se pergunta na frente de uma. Uma demonstração que responde às seis é uma demonstração de produto; uma que responde a nenhuma é uma tela bonita, e elas custam ordens de grandeza diferentes.

Como cortar o primeiro escopo

O primeiro escopo — o MVP, quando o termo é usado direito — se corta por jornada inteira, e não por camada: um caminho que vai do início ao fim ensina alguma coisa; três telas bonitas sem nada atrás não ensinam nada. E há três coisas que não se corta — modelo de dados, autenticação e permissão —, porque refazê-las no meio custa mais que construí-las certo na largada.

• Escreva a pergunta que o primeiro corte responde. Uma só. Se não couber numa frase, ele não é o primeiro corte.
• Corte por jornada inteira, não por camada.
• Escolha o caminho mais comum, não o mais impressionante.
• Deixe de fora tudo o que pode ser feito à mão no começo. Painel administrativo, relatório e configuração costumam esperar — alguém do time faz no banco enquanto o volume é pequeno.
• Não corte o que é caro de acrescentar depois: modelo de dados, autenticação e permissão.

As cinco variáveis que decidem a conta

O custo de um aplicativo é decidido por cinco variáveis — integrações com o mundo de fora, decisão de produto tomada ou não, exigência de conformidade, número de plataformas e a operação depois — e a dominante é a primeira. Não existe preço de tabela honesto: o mesmo pedido varia por um fator grande conforme onde ele cai nas cinco.

Publicar uma faixa de preço sem as variáveis seria mais fácil e seria pior: quem lê levaria embora um número que não descreve o próprio caso. Publicar as variáveis permite estimar de que lado o seu cai — e é isso que qualquer proposta séria vai discutir na primeira conversa.

Duas dessas variáveis você controla antes de falar com qualquer fornecedor: fechar a decisão de produto e escolher uma plataforma só para o primeiro corte. As duas juntas costumam ser a diferença entre um orçamento e o dobro dele.

Quanto tempo leva, e o que faz o prazo escorregar

O prazo de um produto digital é decidido pelas mesmas variáveis do custo, e escorrega quase sempre pelos mesmos três motivos: decisão de produto tomada durante a construção, homologação de terceiro que não depende de ninguém do projeto, e o escopo que cresce porque nunca foi escrito como lista fechada.

A homologação é a que mais surpreende: integrar um meio de pagamento, uma emissora de nota ou uma transportadora envolve aprovação de outra empresa, com fila e critério próprios. É tempo que não acelera com mais gente no projeto, e por isso ele deve começar na primeira semana, não na última.

A publicação nas lojas é a segunda. Um aplicativo móvel passa por revisão antes de ficar disponível, e reprovações por detalhe de política são comuns na primeira submissão. Quem planeja o lançamento para a data em que o código fica pronto está planejando para a data errada.

Depois que sobe

Um produto no ar tem custo mesmo num mês em que nada de novo é feito: hospedagem e monitoramento com alguém sendo avisado quando quebra, dependências de terceiro que mudam sem esperar, correção do que só aparece com gente real usando, e backup testado. É a parte que dura mais e que quase nenhuma proposta descreve.

• Hospedagem e monitoramento, com alguém sendo avisado quando quebra.
• Dependência que muda. Biblioteca, API de terceiro, versão de sistema operacional — nada disso espera você.
• Correção do que só aparece com gente real usando.
• Backup, e o teste de que ele restaura. Backup que nunca foi restaurado é uma suposição, não um plano.

Decida cedo quem assume isso: o fornecedor, o seu time, ou um contrato de operação separado. A decisão adiada vira a descoberta de que ninguém assumiu — e ela costuma acontecer no dia em que o produto cai.

De quem é o código, e por que isso decide o resto

O código é de quem o contrato disser que é, e essa cláusula decide mais coisas que qualquer escolha técnica: se você pode trocar de fornecedor, se pode contratar alguém para continuar, e se o que foi construído continua existindo caso a relação termine. Ela precisa estar no papel antes do primeiro commit.

Três perguntas resolvem o assunto, e as três se fazem por escrito: o repositório é seu, na sua conta, desde o primeiro dia? A infraestrutura está no seu nome — provedor, domínio, contas de terceiro? A documentação de como subir existe, e alguém de fora conseguiria seguir?

Um “não” em qualquer uma delas não é impedimento — é preço. Significa que trocar de fornecedor custa uma migração, e vale saber disso na assinatura e não no dia em que a troca for necessária.

O que se diz por aí e não se confirma

Três afirmações circulam sobre construção de produto digital sem apuração que as sustente, e todas empurram na mesma direção: fazer parecer que a parte cara acabou. Nenhuma aparece neste guia como fato.

Este guia também não traz estatística de mercado, e a ausência é decisão: os números que circulam sobre custo médio, prazo médio e taxa de fracasso de aplicativos não passaram no critério da Kapstan — estudo nomeado, instituição, amostra, data de campo e endereço primário conferido.

Por onde começar

Comece escrevendo a pergunta que o primeiro corte responde, em uma frase. Depois escolha a plataforma onde as pessoas já estão, corte por jornada inteira e ponha no ar com gente de verdade usando — o que se aprende com dez usuários reais não se aprende com nenhuma reunião.

1. Escreva a pergunta que o primeiro corte responde

   Uma só, numa frase. Se não couber numa frase, ele não é o primeiro corte — é a lista de tudo o que o produto vai ser um dia.

2. Escolha uma plataforma só, e que seja onde as pessoas já estão

   Duas na largada é o dobro do trabalho para aprender a mesma coisa, e o que se aprende é sobre a plataforma, não sobre o produto.

3. Comece a homologação de terceiro na primeira semana

   Pagamento, nota fiscal, entrega. Esse relógio não é seu e corre em paralelo ao seu — quem o começa no fim descobre que ele nunca cabia no prazo que sobrou.

4. Ponha no ar com gente de verdade usando

   Ainda que numa fatia pequena. O que se aprende com dez usuários reais não se aprende com nenhuma reunião, e não se aprende com cem se os dez não foram ouvidos.

5. Decida quem opera antes de subir

   E não depois da primeira queda. Quem responde de madrugada, quem tem a senha e quem decide reverter são três respostas, e as três precisam de nome antes de existir usuário.

O vocabulário mínimo

Cinco termos aparecem em toda conversa sobre construção de produto digital e quase nunca são definidos por quem os usa. Eles estão aqui com o sentido que este guia lhes dá, e é o mesmo que os outros textos desta série usam.

MVP

O menor corte capaz de responder a uma pergunta de negócio — não a versão barata do produto inteiro. Barato é consequência de o corte ser pequeno, e não o objetivo dele.

Jornada

O caminho completo de uma pessoa dentro do produto, do início ao fim de uma tarefa. É a unidade certa para cortar escopo: uma jornada inteira ensina; três telas de jornadas diferentes não.

Homologação

A aprovação de outra empresa para você integrar com o serviço dela — pagamento, nota, transportadora. Tem fila e critério próprios, e é tempo que não acelera com mais gente no projeto.

No-code

Construir sem programar, sobre uma plataforma de terceiro. Vence para descobrir se alguém quer; cobra a propriedade — o custo cresce com o uso e a migração depois é um projeto por si.

Plantão

Alguém sendo avisado quando o produto quebra, e disponível para agir. Cair às duas da manhã é evento normal; não ter quem atenda é que é uma escolha.

Perguntas frequentes