Política de entrega: prazos e o que fazemos quando algo quebra

O medo que eu mais escuto de founders não é sobre tecnologia. É sobre dinheiro: “e se eu pagar e o estúdio sumir?”. É um medo justo. Muita gente já pagou sinal, recebeu promessa e ficou sem produto no ar.

Promessa falada não resolve esse medo. Política escrita, sim. A inspiração para esta página veio da Linear, a ferramenta de gestão de projetos, que publicou em setembro de 2025 a sua política de zero bugs, com prazos e números. Esta é a nossa versão para entrega de produto.

O que a Linear fez com os bugs

O texto, assinado por Tuomas Artman e Sabin Roman, conta como a empresa decidiu parar de acumular bugs. Os pontos principais:

• Zerar a fila. A Linear tinha cerca de 175 bugs abertos. O time pausou todos os outros projetos por três semanas para corrigir tudo.
• Prazos fixos. Bugs de alta prioridade têm 48 horas para serem corrigidos. Os de baixa prioridade, 7 dias.
• Sem backlog. Quem recebe o bug decide: corrige ou marca como “não vai ser corrigido”. Mandar para uma lista de espera não é opção.
• Rotina diária. Os engenheiros começam o dia pelos bugs atribuídos a eles.

O resultado: mais de 2.000 bugs corrigidos em um ano, mais de 700 nos últimos três meses, e bugs vindos do suporte muitas vezes resolvidos no mesmo dia. Quando o time discutiu abandonar a prática, ninguém quis. Nas palavras dos autores: “Nobody could imagine going back” (ninguém conseguia imaginar voltar atrás).

Por que publicar uma política de entrega

O que a Linear fez de mais interessante não foi corrigir bugs. Foi escrever a regra e publicar. Regra escrita tira a decisão do humor do dia e coloca na frente do cliente.

Para um estúdio, o equivalente é dizer, por escrito e antes do contrato, o que acontece em cada etapa: quanto custa, quando fica pronto, o que você recebe e o que fazemos quando algo dá errado.

Nossa política de entrega

Parte destes compromissos já vale em todos os nossos projetos. Outra parte está sendo formalizada, e por isso aparece entre colchetes até ser fechada.

1. Preço fechado depois do diagnóstico. Não damos preço antes de entender o problema. Depois do diagnóstico, o preço é um número, não uma faixa de horas.

2. Prazo escrito no contrato. A data de entrega vai no contrato. [O que acontece em caso de atraso causado pelo Studio: desconto, multa ou outra condição].

3. No máximo [três] projetos ao mesmo tempo. Para que quem desenha e constrói esteja de fato no seu projeto e o prazo seja realista.

4. Pagamento ligado a entrega. [Como o pagamento é dividido entre as etapas e o que é entregue em cada uma].

5. Você vê o produto cedo. [Frequência com que o cliente recebe versões navegáveis durante o projeto].

6. Tudo é seu. [Condições de entrega de código, arquivos do Figma, acessos e documentação ao fim do projeto].

7. Agente de IA desde o primeiro dia no ar. Todo sistema que entregamos sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido.

O que acontece quando algo quebra

Software quebra. A diferença está no que acontece depois. Inspirados na Linear, organizamos a resposta por gravidade:

• Crítico (sistema fora do ar, perda de dados, cobrança errada): [prazo de primeira resposta e de correção para falhas críticas].
• Alto (funcionalidade principal com erro, sem alternativa): [prazo de correção para falhas altas].
• Baixo (erro visual, detalhe com alternativa): [prazo de correção para falhas baixas].

[Por quanto tempo depois da entrega essas correções estão cobertas sem custo adicional, e o que acontece depois desse período].

O agente diário ajuda a encurtar o primeiro passo, que é saber que algo quebrou. Ele aponta falhas e confere se os dados fazem sentido todos os dias, o que permite agir antes de o problema chegar ao seu usuário em muitos casos. [Como o relatório do agente chega ao cliente e ao Studio].

O que isso muda para você

Use esta página como lista de conferência, conosco ou com qualquer outro fornecedor. Antes de assinar, pergunte:

1. O preço é fechado? Veio depois de entender o problema?
2. O prazo está no contrato? O que acontece se atrasar?
3. Quantos projetos o time atende ao mesmo tempo?
4. Como o pagamento se liga às entregas?
5. O código, o design e os acessos são seus no final?
6. O que acontece quando algo quebra, e em quanto tempo?

Quem responde por escrito tem processo. Quem responde só falando está pedindo confiança.

Como fazemos no Studio

Estamos nisso desde 2014, com mais de 600 projetos para clientes em 13 países. Dois prazos de case: a LCX ficou no ar em 29 dias, unificando o sistema de mais de 10 países da América do Sul. A AI Vou Eu, que tinha gastado R$200 mil em 3 estúdios sem produto no ar, foi ao ar em 4 semanas.

[Esta política vai ser atualizada sempre que um compromisso mudar, com data.] Se você quer colocar seu SaaS no ar com esses compromissos no contrato, o nosso serviço de sistemas e SaaS começa pelo diagnóstico.