Como definir o escopo de um projeto de SaaS que você realmente consiga concluir

O texto parte de uma premissa simples: lista de telas não basta para orçar um SaaS. Antes de cotar, o autor, que hoje atua como freelancer de design e desenvolvimento, quer entender o que as pessoas vão fazer no produto e quanto dele já funciona. Ele conta que, quando tocava a agência Drool, dizia sim demais, e que isso tornou escopo e prazos difíceis de controlar.

O exemplo usado é uma tela de aprovação de rascunhos para um SaaS de agências. "Adicionar uma tela de aprovação" esconde decisões: quem aprova, se várias pessoas precisam concordar, o que acontece quando alguém sobe um arquivo substituto. A versão mínima do exemplo tem um aprovador nomeado, feedback em texto simples e nova decisão a cada novo rascunho. Também entram no orçamento o que já existe (contas, acesso de clientes, armazenamento, componentes em código), o que fica com o time do cliente, custos recorrentes, marcos de pagamento e regras para mudanças. O autor lembra que um design system em Figma não significa componentes prontos em código.

Sobre preço, ele compara valores inventados em dólares: US$ 10.000 para a versão completa e US$ 7.000 para a menor, e avisa que cortar metade da lista de desejos não corta metade da cotação. Defende reserva para imprevistos, sob controle do cliente, e investigação paga antes de fechar preço quando há incógnita relevante. Cita o Shape Up, da Basecamp, que começa pelo tempo que o problema merece.

Para quem gerencia produto, o texto funciona como roteiro de priorização com orçamento na mesa. Dizer o teto cedo permite negociar escopo em vez de descobrir tarde que a feature não cabe. A regra de cortar funcionalidade antes de deixar o fluxo pela metade é uma boa régua para decidir o que entra na primeira versão. Vale ler o exemplo como ilustração, não como referência de preço.