PoC, o que é: o guia do fundador não-técnico para a Prova de Conceito

Um fundador que estávamos conhecendo recebeu um orçamento de R$ 180 mil para uma PoC. O escopo dizia “validar a viabilidade técnica da plataforma”. Quatro semanas, três pessoas, uma apresentação final.

Ele queria saber o que era PoC. Eu queria saber por que o cheque tinha o tamanho de um MVP inteiro.

É aqui que mora a confusão. PoC, ou proof of concept (prova de conceito), é um experimento curto e barato que responde a uma única pergunta técnica: “isso aqui é possível, e a que custo?”. Não é um produto. Não é um protótipo. Não é um MVP. É um exercício de redução de risco antes de você comprometer o orçamento de um projeto inteiro. Em um fornecedor sério, dura entre uma e três semanas, custa entre R$ 8 mil e R$ 50 mil, e o entregável principal não é código bonito: é conhecimento.

Para o fundador não-técnico, a sigla aparece em dois contextos. Dentro de propostas de fábricas de software (“antes do projeto, recomendamos uma PoC”) e dentro de conversas internas de produto (“vamos validar isso com uma PoC”). Quase ninguém para para explicar qual das duas você está realmente comprando. Este guia faz isso.

PoC, em uma frase

PoC é uma resposta a uma pergunta técnica que ninguém na sua sala consegue responder com confiança. Três exemplos do que essa pergunta parece, do mundo real:

• “Dá para sincronizar os dados do sistema antigo da clínica com o nosso app sem reescrever o legado?”
• “Esse modelo de IA consegue ler as notas fiscais dos nossos fornecedores com mais de 95% de precisão?”
• “O Open Finance suporta o caso de uso que a gente prometeu para o cliente piloto?”

Cada uma é uma pergunta fechada: a resposta é “sim”, “não”, ou “sim, mas”. A PoC existe para chegar nessa resposta em dias, com código jogável fora, e antes que o orçamento do projeto inteiro fique em risco. Quando a pergunta não é fechada (quando ela é, na verdade, “será que o cliente quer isso?” ou “será que o mercado paga por isso?”), você não precisa de uma PoC. Precisa de outra coisa, e a próxima seção desambigua qual.

PoC, MVP, protótipo, spike: o mapa rápido

Quatro palavras, quatro instrumentos diferentes, e o vocabulário do mercado bagunça todos eles. O resumo honesto:

• PoC. Valida uma hipótese técnica. Responde “isso é possível?”. Código descartável. Audiência: o time de produto e engenharia. Não vai para o cliente.
• Protótipo. Valida uma hipótese de design. Responde “as pessoas entendem essa interface?”. Pode ser estático no Figma ou clicável. Vai para usuários em teste, não para produção.
• MVP. Valida uma hipótese de negócio. Responde “alguém usa, alguém paga?”. É um produto pequeno, mas é produto: vai para clientes reais, no mundo real, com dados reais. Essa é a fase para a qual a maior parte do trabalho de discovery de produto serve de preparação.
• Spike. É a versão menor da PoC, geralmente dentro de uma sprint, sem entregável formal. O time mergulha em uma questão técnica por 2 a 5 dias e volta com uma recomendação. Martin Fowler descreve o padrão em uma página, vale ler.

Quando alguém te oferece uma PoC e o escopo lê como “vamos construir uma primeira versão do produto”, você não está olhando para uma PoC. Está olhando para um MVP com nome trocado, e o preço quase sempre confirma isso.

O que uma PoC séria entrega

A entrega de uma PoC útil tem quatro componentes, e a falta de qualquer um deles é um sinal de que o trabalho não foi feito com rigor:

1. Um relatório que diz “sim”, “não” ou “sim, mas”. Em uma ou duas páginas. Com a pergunta original no topo e a resposta no segundo parágrafo. Se você precisa ler 30 slides para entender o veredito, não é um relatório, é uma defesa de orçamento.
2. O código (ou os artefatos) usados para chegar nessa resposta. Mesmo que descartável, fica no seu repositório. Você comprou; é seu. Se o fornecedor diz “o código fica com a gente”, é um sinal de algo errado, e a melhor hora de descobrir isso é agora. Esse é um dos pontos que separa um contrato de desenvolvimento de software sério de um template baixado da internet.
3. Uma lista honesta do que ficou de fora. Toda PoC corta corner. Performance, segurança, casos extremos. A entrega precisa nomear o que foi pulado, para que ninguém leia o “sim” do relatório como “está pronto para escalar”.
4. Uma estimativa atualizada do projeto que vem em seguida. Faixa de horas, faixa de risco, faixa de custo. O motivo principal da PoC existir é que a estimativa antes dela era um chute. Depois dela, deveria ser menos chute.

Note o que não está na lista: telas finalizadas, documentação técnica completa, manual do usuário, vídeo promocional. PoC não entrega isso. Se a proposta promete tudo isso por R$ 180 mil em quatro semanas, alguém vai sair decepcionado, e historicamente é o fundador.

Quando uma PoC faz sentido para o fundador não-técnico

Existem quatro cenários em que vale a pena gastar dinheiro em uma PoC antes do projeto principal. Fora deles, geralmente é desperdício:

1. O projeto depende de uma integração que ninguém da sua equipe nunca fez. Open Finance, ERPs legados de hospital, sistemas de cartório, APIs de operadoras de saúde. Se a viabilidade do produto depende dessa integração funcionar, e ninguém pode te garantir isso no papel, a PoC é mais barata do que descobrir o problema na metade do projeto.

2. O caso de uso depende de um modelo de IA atingir um nível de qualidade específico. “Extrair dado X de documento Y com 95% de precisão” é uma pergunta de PoC. “Construir uma plataforma de IA” não é. Quando a viabilidade do produto depende de uma métrica quantitativa de um modelo, valide essa métrica primeiro, isolada, antes de construir a interface ao redor dela.

3. A arquitetura proposta tem uma decisão de R$ 200 mil embutida. Microserviços ou monolito; banco relacional ou de grafos; nuvem A ou nuvem B. Quando a escolha errada no início custa caro para reverter depois, uma PoC focada em comparar dois caminhos paga o próprio custo dez vezes.

4. Você precisa de munição factual para uma conversa com um investidor ou um cliente piloto. “Sim, a integração com o ERP do cliente é viável; aqui está o relatório técnico” é um argumento diferente de “achamos que é viável”. Quando o ciclo comercial está condicionado a um sinal técnico, a PoC compra esse sinal.

Quando “PoC” virou outra coisa

A palavra também é usada com outros significados, e o fundador não-técnico precisa reconhecer cada um para não pagar pelo errado:

PoC como “MVP barato”. O fornecedor chama de PoC o que é, na prática, a primeira versão do produto. Geralmente é uma forma de baixar o preço de entrada do projeto, ou de fechar uma venda em ciclo curto. Não há problema em comprar uma primeira versão pequena. Há problema em chamá-la de PoC, porque o vocabulário muda as expectativas: PoC é descartável, MVP é fundação. Se você acha que está validando viabilidade e na verdade está construindo fundação, vai usar atalhos perigosos.

PoC como “diagnóstico pago”. Comum em projetos de IA generativa em 2025 e 2026. O fornecedor cobra para descobrir se a tecnologia que ele vende funciona no seu caso. Em alguns mercados isso é razoável. Em outros, é cobrar pelo aprendizado do próprio fornecedor. A diferença está em quem sai dono do conhecimento ao final: você, ou ele.

PoC como “discovery disfarçada”. Quando o que o projeto realmente precisa é entender o problema do usuário, mapear processos, fazer entrevistas, e o fornecedor empacota isso como PoC para evitar a palavra “consultoria”. É uma discovery, vale a pena fazer, mas o vocabulário correto importa: discovery e PoC têm entregáveis e times diferentes.

O teste de quatro perguntas antes de aprovar uma PoC

Antes de assinar, leia o escopo da PoC proposta e responda estas quatro perguntas. Se você não consegue responder a três delas, pare e devolva o documento:

1. Qual é, em uma frase, a pergunta que esta PoC responde? Se a resposta for “validar a viabilidade técnica da plataforma”, o escopo está vago. Você quer “validar se conseguimos sincronizar os dados do sistema X com o nosso sistema Y dentro de um SLA de 5 minutos”. Específico. Fechado. Verificável.

2. Qual é o critério de “sim” e o critério de “não”? A PoC deveria descrever, antes de começar, o que conta como sucesso e o que conta como falha. “Mais de 95% de precisão” é critério. “Apresentar resultados promissores” não é. Sem critério, qualquer resultado vira “sim”.

3. O que sobra para você ao final? Código, relatório, dados, ou só uma apresentação? Quem é o dono do código? Onde ele fica armazenado? Se o fornecedor não responder estas perguntas de forma direta, a PoC está sendo vendida como serviço, não como entrega.

4. Se a PoC der “não”, o que muda no seu próximo passo? Se a resposta for “a gente segue mesmo assim”, você não precisa de PoC. Precisa de coragem para começar e disciplina para ajustar o curso. Uma PoC só faz sentido se o resultado dela pode te fazer parar.

Quanto custa, quanto tempo leva, quem deve fazer

Faixas honestas, do que vemos no mercado brasileiro em 2026, para PoCs de software custom em fornecedores sérios:

• Duração. Uma a três semanas. Acima de quatro, não é mais PoC, é projeto. Abaixo de uma, provavelmente é spike e nem precisaria de orçamento separado.
• Custo. Entre R$ 8 mil e R$ 50 mil, com a maior parte dos casos saudáveis entre R$ 15 mil e R$ 30 mil. PoCs de R$ 100 mil ou mais existem (integrações complexas, regulação), mas a barra de justificativa sobe rápido.
• Time. Uma a três pessoas. Tipicamente um engenheiro sênior que toma as decisões técnicas, eventualmente um especialista (segurança, IA, dados), e meio tempo de uma pessoa de produto que escreve o relatório.
• Quem deve fazer. Idealmente o mesmo time que tocaria o projeto inteiro depois, ou um time que vai entregar a recomendação para outro time executar. Quem fez a PoC tem o contexto; quem só leu o relatório vai inventar metade do que sabia. É um dos motivos pelos quais staff augmentation raramente é o modelo certo para a PoC: o contrato termina e o conhecimento sai com a pessoa.

Se a sua proposta cai fora dessas faixas, pergunte por quê. A resposta pode ser legítima (regulação bancária, integração com sistema federal, equipe especializada). Ou pode ser que você está pagando MVP no preço de PoC, e o vocabulário foi calibrado para o que cabia no orçamento.

Perguntas frequentes

PoC e prova de conceito é a mesma coisa?
Sim. PoC é a sigla em inglês de proof of concept, traduzida como “prova de conceito”. O mercado de tecnologia brasileiro usa as duas formas, às vezes na mesma frase. Não há diferença de significado.

O que significa POC fora do contexto de software?
A sigla aparece em outros lugares e bagunça a busca. Na construção civil, “POC” é uma medida de avanço de obra (percentage of completion). Em medicina, é “ponto de atendimento” (point of care). E no português coloquial, “POC” é uma gíria sem relação alguma com tecnologia. Este guia trata apenas da PoC de software.

PoC, MVP ou protótipo: por qual começar?
Depende da pergunta que você precisa responder. Se a dúvida é técnica (“isso é possível?”), comece pela PoC. Se a dúvida é de design (“as pessoas entendem isso?”), comece pelo protótipo. Se a dúvida é de mercado (“alguém paga?”), pule direto para o MVP. Nenhum dos três é “anterior” ao outro: são instrumentos para perguntas diferentes.

Posso pular a PoC e ir direto para o projeto?
Sim, e na maioria dos casos é o que faz sentido. PoC só vale quando há uma incerteza técnica real que pode matar o projeto e que custa caro descobrir depois. Se o seu produto é uma versão de algo que já existe, com um stack conhecido, a PoC vira teatro de processo.

Quanto tempo dura uma PoC de IA?
Mesma regra das outras: de uma a três semanas para responder uma pergunta específica e fechada. PoCs de IA que duram dois meses geralmente não estão validando uma hipótese; estão construindo um produto sem dizer que é o produto.

O código da PoC vai virar a base do produto?
Não, e essa é a parte mais difícil de aceitar. Código de PoC é otimizado para velocidade de resposta, não para manutenção. A maior parte dele será jogada fora quando o projeto começar. A parte que continua é o aprendizado, registrado no relatório e na cabeça das pessoas envolvidas. Se um fornecedor te promete que o código da PoC “vai aproveitar 80% para o produto”, desconfie: ou a PoC vai virar um MVP mal-feito, ou o produto vai herdar atalhos que pareciam baratos no momento e ficam caros para sempre.