SaaS ou software house? O atraso na entrega que custou R$ 263 mil
A Justiça de Minas mandou uma software house devolver R$ 263 mil porque o software não chegou no prazo. Eu já fui software house, já passei raiva desenvolvendo pros outros, e nunca tomei nem dei prejuízo a cliente. Aqui eu conto o processo que eu uso: escopo fechado antes do orçamento, do jeito que a gráfica faz.
🎧 PREFERE OUVIR? · 22 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 22 minutos no canal @josimarjmv em 11 de outubro de 2026, direto, sem edição. Assista e leia junto. Aqui embaixo eu conto a mesma coisa por escrito, com mais calma, e ponho o que eu fui conferir depois, a começar pelo valor da condenação: na gravação, no título e na capa está R$ 236 mil, e o número publicado pelo Tribunal é R$ 263 mil.
o que quebra uma software house não é o código, é o escopo aberto e o prazo mal combinado. Eu fecho o escopo nas reuniões, com protótipo aprovado e assinado pelo cliente, e só depois faço orçamento e contrato. Coloco prazo relaxado, entrego por fase e mostro cada entrega. E levanto antes os custos que ninguém lembra: domínio, conta na loja da Apple, infraestrutura, banco de dados e pagamento. Trabalhando assim, eu ainda acho software house o caminho mais simples pra viver de software. SaaS é uma empresa inteira.
O caso: seis meses de prazo, um ano e meio sem software
Você quer devolver mais de 200 mil reais por um software que você não entregou a tempo? Pois é. Viver de software tem as suas particularidades.
O Tribunal de Justiça de Minas Gerais mandou uma software house devolver o dinheiro pra uma empresa de rastreamento de frotas de Belo Horizonte. O motivo você adivinha: entrega atrasada. O prazo era de seis meses. Teve atraso, e atraso, e atraso.
Fui conferir na notícia do próprio TJMG, publicada em 2 de junho de 2026, e aqui vai uma correção minha. Na gravação eu falei R$ 236 mil. O valor que o Tribunal publicou é R$ 263 mil. Vale o do Tribunal, e é ele que eu uso daqui pra frente.
O resto do que está publicado lá:
- O contrato é de dezembro de 2022 e previa um sistema gerencial em seis meses.
- Um ano e meio depois, o software ainda não tinha sido entregue. A cliente pediu a rescisão e o dinheiro de volta.
- A 15ª Vara Cível de Belo Horizonte rescindiu o contrato e mandou devolver. A 12ª Câmara Cível manteve a decisão.
- A software house disse que implantar sistema é "processo colaborativo" e que o atraso era culpa da cliente. Não ficou provado.
- Também disse que já tinha entregado uma parte relevante. O Tribunal respondeu que sistema de gestão é um conjunto: entrega parcial não serve pra nada.
- O acórdão é o de nº 1.0000.25.074181-6/003.
Tem uma frase da relatora que eu acho que todo dono de software house devia ler duas vezes. Segundo a notícia, ela registrou que circunstâncias específicas deveriam ter sido previstas em contrato, inclusive a possibilidade de prorrogar o prazo. Ou seja: o que não está escrito não te protege. É exatamente disso que eu trato aqui.
E se você entrar no Reclame Aqui e procurar software house, a coisa que você mais vai ver é isso: atraso na entrega.
De onde eu falo
Vou dar minha carteirada antes. Meu nome é Josimar e eu tenho empresa de tecnologia desde os meus 18 anos. Aos 18 eu fundei o CNPJ que eu tenho até hoje. Passei por todas as fases que você imaginar: hardware, software, lan house, site. A coisa foi subindo, e hoje eu tenho alguns SaaS e uma equipe enxuta, que usa muita inteligência artificial.
"Josimar, você já passou raiva com software house, desenvolvendo software pros outros?" Já. Mas eu nunca tomei prejuízo e nunca dei prejuízo pra cliente meu. Vou usar um termo bem chulo: eu sou cagão. Eu tenho medo. Então eu trabalho com as coisas no mais certinho possível, pra evitar problema pros dois lados.
Se você digitar no YouTube "desisti da minha software house", "tive prejuízo", "não aguento mais ser escravo da minha software house", você vai ver a quantidade de coisa que aparece. E ao mesmo tempo abrem milhares de empresas no Brasil todos os meses, e todas precisam de software. Mercado é mato. A pergunta é se a gente sabe trabalhar como software house.
Esse é mais um texto da série sobre viver de software. Ela começou por como escolher o nome do seu SaaS, e lá eu fiquei devendo falar de software house. Está aqui.
A estimativa de prazo da IA é humana
A primeira e óbvia grande falha de uma software house é a estimativa de tempo. E aqui tem um adendo da inteligência artificial.
Manda a IA estimar um software pra você. Ela vai escrever lá: sete dias. Onde ela colocar sete dias, você pode colocar sete horas. Sem brincadeira, eu estou testando isso exaustivamente. Toda vez que a IA me diz "vou gastar três dias pra fazer", são três horas. "Vou gastar uma semana", é um dia, e olha lá.
Isso acontece porque a estimativa dela é uma estimativa humana. Ela aprendeu prazo com gente, com o tempo que gente levava pra fazer.
E aí vem o ponto importante: o código não é mais o grande problema. Com IA, na minha cabeça, atrasar a entrega de um sistema hoje é injustificável. O que continua quebrando software house é o que vem antes do código.
Erro 1: escopo aberto é suicídio
O cliente chega: "eu quero um site pra minha loja". Você vai lá e fecha um contrato com o cara. Você está pedindo pra ter problema.
Eu vivo isso até hoje. A gente atende cliente de pay-per-view: um canal privado de venda de conteúdo, com aplicativo iOS, Android, site, às vezes até Smart TV. E a gente faz personalização pra cada um. Se você não fechar o escopo de um projeto desses, é um negócio infinito.
Agora vou pegar pesado com o desenvolvedor back-end. Em geral, o back-end não sabe vender, não sabe conversar com o cliente, não sabe fechar escopo. Ele é mais na dele. O sonho dele é fazer o SaaS dele e nunca ver um cliente na vida. Só que tem mercado em que, se você não botar a cara e não conversar com as pessoas, você não vende.
Quer ter software house? Entenda: você tem que conversar com gente. Uma, duas, três, quatro, cinco reuniões, por videoconferência ou pessoalmente. Eu sempre privilegio o presencial. E não tenha vergonha nem medo de fazer mais uma.
O método da gráfica: esboço, arte, aprovação assinada
Eu sempre usei o processo de gráfica pra fazer software. Explico de onde veio.
Quando eu era moleque, com 20 e poucos anos, eu fazia evento. Evento mesmo: festa, show grande. Tomei uns prejuízos, deu errado, parei de mexer com isso há muitos anos. Mas foi ali que eu aprendi a lidar com muita pressão e com muito fornecedor ao mesmo tempo, entre eles silk-screen e gráfica. Eu mandava fazer muito folder e muito cartaz pra divulgar as festas, então eu vi o processo de produção da gráfica do lado do cliente.
Era assim. Primeiro a gráfica me fazia um esboço. Esboço mesmo, desenhado: "aqui a gente coloca um banner, aqui o preço, aqui isso. O que você acha dessa distribuição?". Pra mim aquilo era um bando de risco, mas parecia legal. Era a baixa fidelidade.
Depois vinha a arte pronta. Eu olhava a arte, e tinha um documento pra assinar com a aprovação.
E já aconteceu comigo. Ponto de venda errado. Telefone errado. Eu conferi, naquela correria danada, e eu assinei. Vou fazer o quê? Imprimiu errado porque eu aprovei errado. Se a gráfica não tivesse essa proteção, olha a bomba que ia chegar pra ela: "imprime tudo de novo pra mim, eu não aprovei isso".
Esse é o processo perfeito de escopo fechado. A gráfica mandou a arte, o cliente assinou aprovado, está no contrato. Pronto, acabou.
Primeiro o escopo, depois o orçamento, depois o contrato
"Ah, Josimar, então eu faço o contrato e depois faço o escopo." Não, né, meu filho. O escopo você fecha durante as reuniões de alinhamento.
E pode ser que você faça as reuniões, feche o escopo, e o cara vá embora e não contrate. Faz parte. Depois do escopo é que você faz o orçamento. Como é que você quer fazer orçamento sem fechar escopo?
"Ah, mas o cara está agarrado, está sem tempo." Então você não vende. Porque senão você vai ter problema.
As reuniões servem pra fechar o escopo igual a gráfica fecha: o que cada botãozinho vai fazer, a função de cada um. Desenhou, entregou pro cliente, o cliente assinou. Aí você passa o orçamento. Aprovou o orçamento, o escopo fechado vai dentro do contrato, e aí você estipula os prazos de entrega.
Hoje está mais fácil fazer isso, porque a IA te ajuda a prototipar e a fechar o escopo. "Ah, eu sou só empreendedor, sou vibe coder, não entendo muito." Manda a IA fazer uma busca pra você pelo menos entender. O que essa função faz? Quais são os riscos dela? Não dá pra vender um troço sem entender o que está vendendo. É o mesmo cuidado que eu descrevo em o que eu confiro antes de subir pra produção.
Prazo relaxado, entrega por fase, e a balança pra não perder o contrato
Trabalhe com o cronograma de uma forma relaxada. Prazo estendido.
- Acha que vai gastar 30 dias? Coloque 60.
- Acha que vai gastar 90? Coloque 120.
Mas tenha cuidado: é uma balança. Você pode perder o contrato por causa do prazo relaxado. Prazo é fator decisivo pra fechar, então diminua até o máximo que você consegue cumprir com folga. O melhor dos mundos é você prometer um mês e entregar em 15 dias. O cliente fica rindo de orelha a orelha.
Só não exagera pro outro lado. Combinou seis meses e entregou em 15 dias? O cliente pensa: "eu paguei 200 mil por isso?". Tem isso também. Não desvalorize o seu prazo. Faz um negócio justinho.
E faça entregas por fase. Fase um: vou te entregar a home em tantos dias. Pro cliente é extremamente importante ver que você está entregando. Não é subir tudo no fim e pronto. Subiu uma página nova, manda pra ele. Subiu uma função nova, manda pra ele.
Tem desenvolvedor, principalmente a turma que se acostumou mal na época da pandemia, que acha que está fazendo um favor pro cliente. Você é contratado. Quanto mais valor você gerar e quanto menor o prazo que você cumprir, melhor.
Site é outra conversa. Site dá pra fazer em um dia, e eu mostro como em um site por dia com Claude Code. Aqui eu estou falando de algo mais complexo: software, que pode ser só web, aplicativo, ou web com aplicativo.
Os custos que ninguém lembra na hora de fechar o escopo
Com IA dá pra tocar vários projetos ao mesmo tempo. Mas você precisa entender o fluxo inteiro do software que vai subir pro cliente. Olha a quantidade de nuance:
| Item | A pergunta que eu faço antes do orçamento |
|---|---|
| Domínio | Você avisou o cliente que precisa de um domínio? Ou esqueceu? |
| Loja da Apple | Tem taxa anual pra publicar. A conta é sua ou você vai cobrar dele? |
| Direito sobre o conteúdo | Se publicar na sua conta, o cliente tem direito sobre o que vai subir? Se não tiver, o banimento e o processo vêm pra você. |
| Hospedagem e vídeo | Vai mexer com vídeo? Onde hospeda, quanto custa o armazenamento, quem cobra tráfego? Faz a conta. |
| Notificação push | Vai ter? No celular ou só na web? |
| Banco de dados | Vai rodar onde? Você explicou os riscos de cada opção pro cliente? |
| Pagamento | Qual banco ou fintech? Tem API pro que você precisa? Quantos por cento cobra? |
Sobre a loja da Apple, o valor que eu fui conferir: o Apple Developer Program custa US$ 99 por ano, conforme a página oficial que eu li em 12 de outubro de 2026. É pouco, mas é todo ano, e alguém tem que pagar. Isso precisa estar combinado.
Sobre infraestrutura com vídeo: vai botar na Amazon? No R2 da Cloudflare? Na JMV, que não cobra tráfego? Faz a conta antes. Só nesses poucos detalhes você já viu o custo subindo. E um projeto desses, mesmo com a IA trabalhando o dia inteiro igual doida, é projeto de mais de mês. Bem mais de mês.
Sobre banco de dados: vai rodar Supabase, pra ser invadido e ficar preso no fornecedor, com o seu cliente sem conseguir sair de lá nunca mais? "Ah, eu só quero vender o software, o resto é com o cliente." Mas você explicou os riscos pra ele? Você foi responsável na hora de vender? "Essa opção aqui eu te amarro numa mensalidade e cuido pra você. Essa outra é direto com o fornecedor." Os motivos da minha implicância estão em os três riscos do Supabase em produção.
O boleto que eu tirava por print
Pagamento merece um caso meu. Há muitos anos eu fui integrar com o Sicoob, e o boleto deles era uma gambiarra. Eles não tinham API pra eu emitir boleto. Eu tinha que abrir o navegador automatizado, na época com Selenium, dar print do boleto e mandar pro meu cliente. Um absurdo.
Hoje eu acho que já tem. Eu não sou mais cliente deles, e tive altos problemas com cooperativa. Não fui conferir como está hoje, então fica como eu disse: eu acho.
O ponto continua valendo. Às vezes o seu cliente é mais antigo, conhece o gerente da conta, faz questão daquele banco. Vai ser Banco do Brasil, Itaú, uma fintech? Você olhou a API antes? Tem cliente que quer receber em criptomoeda. Como você integra? Vai usar uma carteira? Quantos por cento ela cobra? Você passou isso pro cliente?
Tudo isso gera fricção. E tudo isso é dinheiro, é tempo, é prazo. Essas maldades todas têm que estar na sua cabeça na hora de fechar o escopo, não no quinto mês do contrato.
Vendedor que não é dev, dev que não é vendedor
A gente tem dois cenários engraçados. O dev, que não é vendedor. E o vendedor, que não é dev: ele vai lá, vende o software no oba-oba e esquece que precisa de alguém pra desenvolver. "Ah, eu faço no vibe code." Se você não entende, você não vai conseguir botar um software em produção pra vender.
Sem entender de pipeline, de infraestrutura e de segurança, vai dar ruim. Pagamento, invasão: vai dar ruim. Quando envolve dinheiro, a gente tem que entender do assunto, se não quiser tomar um processo igual ao de Belo Horizonte. O seu projeto talvez seja pequeno, de 5 mil, 10 mil reais. Aquele era grande. A lógica é a mesma.
E você, empresário: tem a mão de obra? Tem alguém pra fazer pra você? Pesquisou as nuances de botar um software no ar?
Software house ou SaaS: qual eu acho mais simples hoje
Bota uma coisa na cabeça: cada SaaS que você fizer é uma empresa. Exige profissionalismo e várias etapas pra funcionar. Não é um troço do dia pra noite. Não dá pra pegar um caso que estourou no mundo e achar que aquilo é a regra. A regra é o contrário.
Por mais absurdo que pareça, a forma mais fácil que você ainda tem de empreender com software hoje é ser software house. Só que trabalhando certinho e fechando escopo. Entregar software ficou muito fácil.
| Software house | SaaS | |
|---|---|---|
| Com o que você se preocupa | Com o seu trabalho: entregou, está no prazo, está certo. | Com tudo: fazer o produto virar. |
| Se o software vai dar certo no mercado | É problema do cliente. Você pode ajudar em outras fases. | É problema seu. |
| Venda, marketing e suporte | Do cliente. | Seus. |
| O que te quebra | Escopo aberto e prazo estourado. | Achar que é do dia pra noite. |
Essa despreocupação torna a software house muito mais vantajosa no aspecto psicológico, desde que você trabalhe direito. O SaaS é muito mais responsabilidade do que entregar um software. Pra você ter a medida da parte financeira, eu fiz a conta dos 250 clientes em outro texto.
E dá pra fazer isso sozinho. Fechando escopo, você consegue trabalhar sozinho e faturar bem entregando software: é o exército de um homem só. Só que tem que entender do fluxo inteiro, ou ter uma equipe que entenda.
Do lado do SaaS eu ainda vou tratar na série: a venda, o marketing e o suporte ao cliente. Aqui eu quis trazer a visão da software house.
O que eu abro na Imersão de SaaS em Produção
Muitas dessas maldades você às vezes nem faz ideia que existem. É o que eu vou passar numa imersão presencial, em São Paulo, que se chama "em produção": como você bota um software em produção. É pra quem quer ter software house, pra quem quer viver de SaaS e pro empresário que virou vibe coder e quer colocar um software no ar.
Eu levo o meu pipeline de desenvolvimento com inteligência artificial. Hoje eu tenho 19 serviços 100% autônomos, que funcionam sozinhos, literalmente sozinhos. E levo o atalho mastigado de cada item que eu citei aqui, que eu já gastei alguns milhões de reais pra aprender.
Se você não quiser pagar, acompanha a série. Está tudo bem. Você vai bater muita cabeça pra aprender o que eu aprendi, mas vai aprender de graça. Vale pros dois lados.
Nota de cronologia: data e condição valem na página da imersão
Gravei em 11 de outubro de 2026, com a pré-inscrição aberta. Gravação envelhece, então eu não repito aqui duração, valor nem condição. O que vale é o que está na página da Imersão de SaaS em Produção, e é lá que fica a pré-inscrição.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
O que é escopo fechado num contrato de software?
É o cliente ter aprovado, por escrito, o que vai ser entregue antes de existir orçamento e contrato. Eu faço igual à gráfica: primeiro um esboço, depois a arte, o protótipo com cada botão e a função de cada um, e o cliente assina a aprovação. Só depois eu passo o orçamento, e o escopo fechado vai dentro do contrato, com os prazos de cada fase.
Software house pode ser condenada a devolver o dinheiro por atraso?
Pode, e aconteceu. A 12ª Câmara Cível do Tribunal de Justiça de Minas Gerais manteve a condenação de uma empresa de desenvolvimento a devolver R$ 263 mil a uma companhia de rastreamento de frotas de Belo Horizonte. O contrato, de dezembro de 2022, dava seis meses pra entregar um sistema gerencial, e um ano e meio depois o software ainda não tinha sido entregue. Na gravação eu falei R$ 236 mil. O número publicado pelo Tribunal é R$ 263 mil.
Faço o orçamento antes ou depois de fechar o escopo?
Depois. Eu não coloco valor e não faço contrato antes de fechar o escopo. O escopo se fecha nas reuniões de alinhamento, uma, duas, cinco, quantas forem necessárias. Pode acontecer de eu fazer as reuniões, fechar o escopo e o cliente ir embora sem contratar. Faz parte. Se o cliente está sem tempo pra fechar escopo, eu não vendo, porque senão eu vou ter problema.
Como estimar o prazo de entrega de um software feito com IA?
Eu trabalho com prazo relaxado no contrato: se eu acho que vou gastar 30 dias, coloco 60; se acho que vou gastar 90, coloco 120. Mas é uma balança, porque prazo grande demais perde o contrato. E a estimativa que a IA dá é humana: nos meus testes, quando ela fala em sete dias de trabalho, eu faço em horas. Isso é o tempo de escrever o código, não o tempo do projeto inteiro.
Quais custos o cliente esquece num projeto de software?
Domínio, a conta de desenvolvedor pra publicar aplicativo na loja da Apple, a infraestrutura pra rodar, o armazenamento e o tráfego se tiver vídeo, o banco de dados, a notificação push e o meio de pagamento com a taxa dele. Eu levanto tudo isso na hora de fechar o escopo, porque cada item é dinheiro, é tempo e é prazo.
O que é mais fácil hoje: software house ou SaaS?
Por mais absurdo que pareça, eu acho que a forma mais simples de empreender com software hoje ainda é ser software house, desde que você trabalhe certinho e feche escopo. Você se preocupa com o seu trabalho: entregou, está no prazo, está certo. No SaaS, cada SaaS é uma empresa: você tem que fazer a venda, o marketing e o suporte ao cliente. É muito mais responsabilidade.
Dá pra ter uma software house sozinho?
Dá. Com IA você consegue trabalhar sozinho e faturar bem entregando software, o que eu chamo de exército de um homem só. Só que você precisa entender do fluxo inteiro, do pipeline de desenvolvimento à infraestrutura e à segurança, ou ter uma equipe que entenda.
Baseado na gravação do canal @josimarjmv publicada em 11/10/2026 (22min07s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: a empresa de tecnologia desde os 18 anos, as fases de hardware, software, lan house e site, os SaaS de hoje e a equipe enxuta; nunca ter tomado nem dado prejuízo a cliente; a condenação de uma software house pelo Tribunal de Justiça de Minas Gerais a devolver o valor a uma empresa de rastreamento de frotas de Belo Horizonte, com prazo de seis meses e atrasos, citada com o valor de R$ 236 mil; a menção ao Reclame Aqui; a estimativa de prazo da IA (sete dias viram sete horas, nos meus testes); o escopo aberto como suicídio; os clientes de pay-per-view; o desenvolvedor back-end que não sabe vender; os eventos que eu fazia com 20 e poucos anos e o processo da gráfica (esboço, arte, aprovação assinada, o ponto de venda e o telefone errados que eu assinei); escopo antes de orçamento e de contrato; o prazo relaxado (30 vira 60, 90 vira 120), a balança pra não perder o contrato e as entregas por fase; domínio, taxa anual da loja da Apple, direito sobre o conteúdo, hospedagem de vídeo, notificação push, banco de dados, Supabase e pagamento; a integração antiga com o Sicoob por print de boleto via Selenium; o vendedor que não é dev e o dev que não é vendedor; cada SaaS ser uma empresa; a software house como caminho mais simples; os 19 serviços autônomos; a imersão presencial em São Paulo. Tudo dito de cabeça, direto, sem edição.
Apuração minha (12/10/2026): o valor de R$ 263 mil, a data do contrato (dezembro de 2022), o prazo de seis meses, o um ano e meio sem entrega, a 15ª Vara Cível de Belo Horizonte, a 12ª Câmara Cível, os argumentos de "processo colaborativo" e de adimplemento substancial, a observação da relatora sobre prever em contrato a prorrogação do prazo e o número do acórdão (1.0000.25.074181-6/003) estão na notícia Empresa é condenada por não entregar software no prazo, do TJMG, de 02/06/2026. Eu li a notícia do Tribunal, não o acórdão. A gravação, o título dela e a capa trazem R$ 236 mil; o número publicado pelo Tribunal é R$ 263 mil, e é o que eu uso no texto. Os US$ 99 por ano estão na página do Apple Developer Program, lida em 12/10/2026. Não conferi a situação atual da API de boleto do Sicoob; o relato é da minha integração antiga. A leitura de que o que não está no contrato não protege a software house é minha, não texto do Tribunal.