Escopo de projeto de software: como escrever em uma página o que você quer antes de pedir orçamento

**O que é escopo de projeto de software e por que ninguém dá preço sem ele**

**Escopo de projeto de software** é o documento que descreve o **resultado esperado** — não a solução técnica. Quem escreve é o lado que conhece o problema, ou seja, quem contrata. O fornecedor escreve a proposta depois, a partir dele.

Um escopo orçável cabe em uma página e responde cinco perguntas: **quem usa**, **o que essa pessoa precisa fazer**, **o que o software precisa lembrar**, **com quais sistemas ele conversa** e **como saber que está pronto**. Lista de telas não substitui nenhuma delas.

Uma página basta e costuma funcionar melhor que dez. Documento longo ninguém lê inteiro, e ele envelhece antes da primeira entrega: parte das regras que você escreveu no começo se revela diferente quando alguém olha o caso real.

Sem escopo, o fornecedor precifica por hipótese. Ou ele imagina o pior cenário e o preço fica alto sem motivo, ou imagina o mais simples e o preço fica baixo — e a diferença aparece depois, cobrada como retrabalho.

É por isso que dois fornecedores dão orçamentos distantes para o mesmo pedido: eles não leram o mesmo pedido, leram duas interpretações possíveis do mesmo parágrafo aberto.

Este artigo não é modelo de contrato nem tabela de preço. Se o que você procura são faixas de valor, o [guia honesto de quanto custa criar um site](/blog/quanto-custa-criar-um-site-em-2026/) trata disso. Aqui o assunto é o texto que você manda antes de perguntar o preço.

**As cinco perguntas que transformam "quero um site" em escopo orçável**

Responda as cinco em sequência, com três a cinco linhas cada. Sem anexo, sem jargão, sem diagrama.

Pergunta: Quem usa? · Resposta que não dá para orçar: "Os clientes e a gente." · Resposta orçável: "Visitante não logado, cliente com login e dois atendentes internos."

Pergunta: O que a pessoa precisa fazer? · Resposta que não dá para orçar: "Ter uma área de pedidos." · Resposta orçável: "Enviar um pedido de orçamento e acompanhar o status dele até a resposta."

Pergunta: O que o software precisa lembrar? · Resposta que não dá para orçar: "Os dados dos clientes." · Resposta orçável: "Cadastro do cliente, histórico de pedidos e anexos enviados, entre uma visita e outra."

Pergunta: Com quais sistemas ele conversa? · Resposta que não dá para orçar: "Integrar com tudo." · Resposta orçável: "Abrir conversa no WhatsApp e lançar a venda na planilha que a equipe já usa."

Pergunta: Como saber que está pronto? · Resposta que não dá para orçar: "Quando estiver funcionando." · Resposta orçável: "O atendente encontra qualquer pedido pelo CPF e o cliente recebe confirmação automática."

Duas dessas perguntas merecem cuidado extra.

**Quem usa** mexe no preço sem parecer: cada perfil de pessoa é um conjunto novo de permissões, de telas e de casos de erro. Três perfis não custam o mesmo que um, mesmo quando as funcionalidades parecem iguais.

**Com quais sistemas ele conversa** trata de integração, que aqui significa fazer o seu software trocar informação automaticamente com outro serviço: um meio de pagamento, uma planilha compartilhada, o ERP (o sistema de gestão) que a empresa já usa. Liste os que existem hoje, não os que seriam legais um dia.

Vale separar link de integração, porque o preço é outro. Um botão que abre a conversa no WhatsApp é um link — barato e imediato. Enviar mensagem automática pelo WhatsApp é integração com a plataforma oficial de negócios da Meta: exige conta aprovada, modelos de mensagem autorizados antes do uso e cobrança feita pela própria plataforma.

**O que o software precisa lembrar** é a fronteira real entre site e sistema. Se nada precisa ficar guardado entre uma visita e outra, você está pedindo um site. Se algo precisa, você está pedindo um sistema — e o orçamento muda de faixa.

Guardar dado pessoal (CPF, telefone, endereço) também traz obrigação de LGPD, a Lei Geral de Proteção de Dados: finalidade declarada, acesso restrito a quem precisa e prazo para descartar. Isso é escopo, não detalhe de implementação.

**Lista de telas é escopo ruim; lista de resultados é escopo bom**

Uma forma muito usada de escrever escopo é listar telas: "login, dashboard, cadastro de cliente, relatório". É também uma das que mais geram divergência de orçamento, porque tela é consequência de uma decisão de produto, não causa. Escrever "oito telas" congela uma solução antes de alguém ter entendido o problema.

Duas telas com o mesmo nome podem custar coisas muito diferentes conforme as regras por trás delas — um "cadastro de cliente" com validação de documento, deduplicação e histórico não tem nada a ver com um formulário de cinco campos. E o inverso também vale: dois caminhos bem diferentes podem entregar o mesmo resultado, e um deles costuma ser mais barato.

Quando quem contrata fixa a tela, tira do fornecedor a liberdade de propor o caminho curto. Você passa a pagar pela sua própria hipótese de solução, e o fornecedor entrega exatamente o que foi pedido mesmo enxergando uma saída mais simples.

Na prática, a reescrita é direta: em vez de "tela de cadastro de cliente", escreva "quero encontrar um cliente pelo CPF em menos de um minuto e ver o histórico de compras dele". Em vez de "tela de relatório", escreva "quero saber no fim do mês quanto cada vendedor fechou".

Desenho de tela ajuda, sim — depois. Uma vez fechado o escopo por resultados, ele vira material de referência visual durante a construção, na fase em que o fornecedor já entendeu o problema. É o momento descrito em [da descoberta ao deploy](/blog/da-descoberta-ao-deploy-com-fabrica-de-software/), não antes dele.

**O que de fato move preço e prazo no orçamento**

Cinco fatores costumam explicar a diferença entre orçamentos do mesmo pedido. Declare cada um de propósito na sua página — inclusive para dizer que não se aplica.

— **Integração.** Cada sistema externo é uma dependência que pode não ter documentação, impor limite de requisições por minuto (*rate limit*) ou exigir homologação — aprovação prévia do dono do serviço — antes de liberar o acesso. O prazo passa a depender de terceiros que não seguem o seu cronograma.

— **Autenticação e permissões.** Autenticação é provar quem a pessoa é (login) e tem soluções conhecidas. Permissão é decidir o que ela pode ver e fazer: "o vendedor vê só os clientes dele e o gerente vê todos" é regra de negócio espalhada por cada consulta, cada relatório e cada tela — e custa mais que o login.

— **Migração de dados.** Trazer o que já existe hoje — planilha, sistema antigo, exportação de um serviço que você vai abandonar — para dentro do novo. O custo está na bagunça do dado de origem, não no volume: mesmo CNPJ escrito de cinco jeitos, campo de data com texto livre, registros duplicados.

— **Volume de conteúdo.** [Quem escreve os textos](/blog/seo-de-conteudo-para-marcas-de-tecnologia-e-servicos/), quem entrega as imagens, quantas páginas. Site sem *copy* (os textos definitivos) pronto trava na etapa de escrita, e essa espera aparece no preço de um jeito ou de outro.

— **Decisões pendentes do seu lado.** Aprovação da identidade visual, acesso aos sistemas de terceiros, definição de quem decide. É o tipo de atraso que o fornecedor não tem como controlar.

Escreva, em uma linha cada, o que já está resolvido e o que ainda não: "logo e cores definidos", "textos ainda não escritos", "acesso ao ERP depende do fornecedor atual". Isso reduz a margem de risco que o fornecedor embute no preço — porque risco não declarado ele precifica por cima.

**MVP e critério de aceite: como combinar o que significa "pronto"**

MVP (produto mínimo viável) é a menor versão que já resolve o problema de alguém de verdade. Não é versão capenga nem demonstração para reunião: é algo que entra em uso. O corte do MVP é de **valor**, não de qualidade — tira funcionalidade, não tira [segurança, desempenho, backup nem deploy](/blog/devops-observabilidade-e-confianca-entre-times-e-clientes/).

Critério de aceite é a frase verificável que decide sozinha se uma entrega está concluída. "O cliente recebe a confirmação no WhatsApp em até um minuto após enviar o pedido" aceita ou reprova sem discussão.

Escreva de três a cinco desses para o MVP, em linguagem de negócio, cada um começando por um verbo observável.

O que não é critério de aceite: "ficar bonito", "ser rápido", "funcionar bem", "ter cara de moderno". Tudo que só se resolve discutindo gosto vira rodada infinita de ajuste — e rodada infinita é prejuízo para os dois lados.

Combine antes quantas rodadas de ajuste entram no preço e o que conta como ajuste versus item novo. A regra simples: mudar o que já estava escrito no critério de aceite é ajuste; acrescentar comportamento que não estava lá é item novo.

**Escopo fechado ou entrega incremental: o trade-off honesto**

Como funciona · Escopo fechado: Preço e prazo definidos antes de começar · Entrega incremental: Pedaços utilizáveis em sequência, reorçados a cada incremento

Funciona bem quando · Escopo fechado: O problema é conhecido e estável: site institucional, landing page · Entrega incremental: O uso real muda as prioridades: sistema web sob medida

Você ganha · Escopo fechado: Previsibilidade para aprovar e planejar · Entrega incremental: Capacidade de mudar de rota sem renegociar tudo

Você perde · Escopo fechado: Rigidez: toda mudança vira negociação · Entrega incremental: Valor total fechado no começo

Escopo fechado pesa contra você quando ainda está descobrindo o que o usuário precisa. O fornecedor embute margem de risco justamente porque sabe que o plano vai mudar, e você acaba pagando por essa incerteza de qualquer jeito.

Incremental também tem hora de não valer: quando você precisa de um valor total fechado para aprovação interna, quando não há ninguém do seu lado disponível para revisar a cada entrega, ou quando o projeto é pequeno demais para justificar o ciclo de reunião, entrega e reorçamento.

O modelo misto costuma resolver: escopo fechado para o MVP, com critérios de aceite escritos, e incremental daí em diante.

Nas faixas públicas da Projask, sites institucionais e [landing pages](/blog/landing-page-que-converte-whatsapp-pixel/) partem de R$ 600 e costumam caber em escopo fechado. Sistemas web sob medida partem de R$ 2.500 e tendem a compensar mais no incremental, porque a segunda entrega já nasce informada pelo que a primeira ensinou. Nos dois casos o valor final é combinado na conversa, depois de o escopo ficar claro.

**Como mudar o escopo sem virar briga**

Mudança de escopo é normal e esperada. O que azeda a relação não é a mudança: é a ausência de um lugar combinado para registrá-la. Sem esse lugar, a conversa acontece por mensagem solta e cada lado guarda uma versão diferente do combinado.

Reserve uma seção da mesma página chamada "não entra nesta entrega". Nomear o que ficou de fora desde o começo — app de celular, relatório fiscal, integração com o sistema do contador — evita a discussão do "eu achei que estava incluso".

Quando surgir pedido novo, reorce por incremento em vez de renegociar o projeto inteiro. O pedido vira um item com preço e prazo próprios, que você aceita ou adia sem travar o que já está andando. E use o escopo como base da conversa de prazo: o que entra empurra a data, e isso precisa ser dito na hora do pedido, não na véspera da entrega.

Um detalhe organizacional vale mais que qualquer cláusula: quem decide do seu lado precisa ser uma pessoa só. Comitê informal — três pessoas mandando ajustes contraditórios por canais diferentes — encarece qualquer mudança de escopo. Se a avaliação do fornecedor ainda está aberta, o [checklist para escolher uma fábrica de software](/blog/como-escolher-fabrica-de-software-alinhada-a-seu-produto/) cobre o outro lado dessa mesa.

Junte numa página as respostas das cinco perguntas, os critérios de aceite e a lista do que não entra. É material suficiente para uma conversa de preço e prazo com qualquer fornecedor sério — inclusive com a gente, pelo WhatsApp.

**Como escrever o escopo de um projeto de software se eu não sou técnico?**

Quem escreve o escopo é o lado que conhece o problema, ou seja, quem contrata — o fornecedor escreve a proposta depois, a partir dele. Responda em uma página, com três a cinco linhas cada, cinco perguntas: quem usa, o que essa pessoa precisa fazer, o que o software precisa lembrar, com quais sistemas ele conversa e como saber que está pronto. Sem anexo, sem jargão e sem diagrama. Uma página costuma funcionar melhor que dez, porque documento longo ninguém lê inteiro e ele envelhece antes da primeira entrega.

**Por que dois fornecedores me deram orçamentos tão diferentes para o mesmo pedido?**

Porque eles não leram o mesmo pedido: leram duas interpretações possíveis do mesmo parágrafo aberto. Sem escopo, o fornecedor precifica por hipótese — ou imagina o pior cenário e o preço fica alto sem motivo, ou imagina o mais simples e o preço fica baixo, com a diferença aparecendo depois, cobrada como retrabalho. Declarar de propósito os cinco fatores que movem preço (integração, autenticação e permissões, migração de dados, volume de conteúdo e decisões pendentes do seu lado) reduz a margem de risco que o fornecedor embute, porque risco não declarado ele precifica por cima.

**O que é critério de aceite e como eu defino que o projeto está pronto?**

Critério de aceite é a frase verificável que decide sozinha se uma entrega está concluída, como "o cliente recebe a confirmação no WhatsApp em até um minuto após enviar o pedido" — aceita ou reprova sem discussão. Escreva de três a cinco desses para o MVP, em linguagem de negócio, cada um começando por um verbo observável. O que não serve: "ficar bonito", "ser rápido", "funcionar bem", "ter cara de moderno" — tudo que só se resolve discutindo gosto vira rodada infinita de ajuste, o que é prejuízo para os dois lados.

**Migração de dados entra no escopo ou é cobrada à parte?**

Migração de dados é um dos cinco fatores que mais movem preço e prazo, então precisa estar declarada na sua página — inclusive para dizer que não se aplica. Ela é o trabalho de trazer o que já existe hoje (planilha, sistema antigo, exportação de um serviço que você vai abandonar) para dentro do novo. O custo está na bagunça do dado de origem, não no volume: mesmo CNPJ escrito de cinco jeitos, campo de data com texto livre, registros duplicados. Deixar isso implícito é justamente o que faz o fornecedor embutir margem por cima.

**Escopo fechado ou entrega incremental: qual compensa para o meu projeto?**

Escopo fechado define preço e prazo antes de começar e funciona bem quando o problema é conhecido e estável, como site institucional e landing page; você ganha previsibilidade e perde flexibilidade, já que toda mudança vira negociação. A entrega incremental trabalha em pedaços utilizáveis reorçados a cada etapa e compensa quando o uso real muda as prioridades, como em sistema web sob medida; o que você perde é o valor total fechado no começo. Incremental não vale quando você precisa de um valor total para aprovação interna, quando não há ninguém do seu lado para revisar cada entrega ou quando o projeto é pequeno demais para o ciclo de reunião e reorçamento. O modelo misto costuma resolver: escopo fechado para o MVP, com critérios de aceite escritos, e incremental daí em diante.