Escopo fechado por fase. O código é seu, e o repositório vai para o nome da sua empresa.
Aqui está o método, fase por fase, com o que você recebe em cada uma. Quem faz o diagnóstico é quem escreve o código. Você não conversa com um vendedor e depois recebe outra pessoa no projeto. O processo abaixo é o mesmo para o sistema de uma loja e para um ERP de três unidades. O que muda é o tamanho do escopo.
Cada fase termina com um entregável que existe como documento ou como sistema no ar. Se a fase acabou e você não tem nada na mão, ela não acabou.
Entregável: um resumo escrito da sua operação e do problema, no seu e-mail.
Uma conversa. Você mostra como a operação funciona hoje: a planilha, o app improvisado, o caderno, o grupo de WhatsApp. Perguntamos onde o dado é redigitado, onde a equipe perde tempo e o que quebra quando alguém falta. No fim dizemos se dá para resolver, e se o caso não for para a H&I, dizemos isso também. Quem participa: você e quem executa o processo todo dia. Essa pessoa costuma conhecer o problema melhor do que o dono.
Entregável: o documento de Blueprint, com escopo item a item, o que fica de fora, o desenho técnico e o valor do que está escrito.
É o documento que define o que você compra. O Blueprint lista cada tela e cada regra que entra, e lista também o que não entra, a parte que quase ninguém escreve e que depois vira discussão. Traz o desenho técnico (banco, integrações, o que precisa funcionar sem internet), as decisões de arquitetura com o motivo de cada uma, e o valor do que está escrito ali, com a regra de reajuste para quando o escopo mudar. Nada é construído antes de você aprovar esse documento. Se o Blueprint mostrar que o projeto não se paga, você sai com um documento útil e sem obra começada. Quem participa: a H&I escreve, você lê e aprova.
Entregável: a cada ciclo, uma versão funcionando em ambiente de teste, com o seu login.
Nada de sumir por meses e reaparecer com um sistema pronto. Cada ciclo entrega uma parte que funciona de ponta a ponta e termina com uma demo ao vivo: abrimos a tela, você usa, sua equipe aponta o que está errado enquanto ainda é barato mudar. Durante o ciclo você acompanha a lista de tarefas, o que está feito, o que está em andamento e o que foi para o próximo. Quem participa: você e a pessoa da equipe que mais vai usar o sistema.
Entregável: relatório de testes e o checklist de segurança aplicado, item a item.
Antes de qualquer coisa ir ao ar, os caminhos que param a operação são testados de forma automatizada: login, pedido, cálculo de preço, pagamento, fechamento de caixa. Esses testes rodam de novo a cada versão, então uma correção numa ponta não quebra a outra em silêncio. A parte de segurança segue um checklist escrito aplicado em todo projeto: controle de acesso revalidado a cada requisição, limite de tentativas de login por e-mail e por IP, dado pessoal criptografado em repouso e segredo obrigatório em produção. Quem participa: a execução é nossa, o relatório é seu.
Entregável: sistema em produção, treinamento com quem vai operar e um manual curto do uso diário.
Sistema que a equipe não sabe usar volta para a planilha em duas semanas. Por isso o go-live inclui treinamento com quem opera, na linguagem de quem opera, e um manual curto, do tamanho que a equipe realmente lê. Acompanhamos a primeira rodada de uso real, que é quando aparecem as perguntas que nenhuma reunião prevê. Quem participa: a equipe inteira que vai usar o sistema.
Entregável: canal direto com quem construiu e um registro de versões, o que mudou, quando e por quê.
Depois do go-live o sistema continua vivo: a lei muda, o fornecedor muda a API, a operação cresce. Você fala direto com quem construiu, no WhatsApp ou no e-mail. Toda correção e toda função nova entram numa versão registrada, então dá para olhar seis meses depois e saber exatamente o que mudou. Um dos PDVs que mantemos já teve 15 versões publicadas. É esse o formato quando o cliente continua usando o sistema de verdade.
A H&I é uma equipe pequena, e é exatamente por isso que o método é rígido.
Equipe grande esconde erro atrás de reunião. Equipe pequena não tem onde esconder, e o que protege é método: nada entra sem revisão, nada vai ao ar sem teste, e toda decisão técnica fica escrita no repositório da sua empresa.
Todo trecho de código passa por revisão dedicada antes de virar parte do sistema: correção, segurança e se já não existe algo pronto que faça aquilo. Essa revisão roda por papéis separados, arquitetura, QA, segurança e um papel cuja função é tentar quebrar o que acabou de ser escrito.
Nem tudo precisa de teste automatizado. O que para a operação, sim: login, preço, pedido, pagamento, fechamento. Esses caminhos são exercitados por robô de navegador a cada versão. É o que impede que um ajuste no estoque derrube o caixa sem ninguém notar até o sábado à noite.
Desenvolvimento, homologação e produção são bancos separados, com produção isolada do resto. Você testa em homologação, com dado de mentira, e aprova. Só então a versão vai para produção. Ninguém mexe direto no ambiente onde estão os seus clientes.
Toda decisão de arquitetura vira um arquivo curto: qual era o problema, quais eram as opções, o que foi escolhido, por quê e em que data. Seis meses depois, quando alguém perguntar por que o estoque é calculado daquele jeito, a resposta está escrita no repositório da sua empresa.
Todo projeto passa pelo mesmo checklist escrito de segurança antes de ir ao ar, e o que ficou de fora é registrado com o motivo. O que está implementado, com nome e detalhe, está na página de tecnologia.
Usamos IA para acelerar o que é repetitivo, sempre dentro das regras acima: revisão, teste e decisão registrada. Se a resposta para "por que isso está assim?" for "a IA fez", o trabalho não está pronto. O limite completo está escrito na página de tecnologia.
O código é seu em definitivo: sem licença de uso, sem aluguel e sem prazo de validade.
Muita gente descobre tarde demais que pagou por um sistema e recebeu apenas o direito de usá-lo, e que trocar de fornecedor significa começar do zero. Aqui não funciona assim, e isso está no contrato, não só nesta página.
O código-fonte fica num repositório transferido para a conta da sua empresa no go-live, ou antes disso se você pedir. Não é uma cópia em zip enviada por e-mail: é o histórico inteiro, commit a commit, com os registros de decisão junto.
Domínio, banco de dados, chaves de integração e gateway de pagamento são criados no nome da sua empresa, com o seu cartão e o seu acesso de dono; a H&I entra como colaboradora e você pode remover esse acesso a qualquer momento. O servidor é a única peça que pode ser nossa, quando você prefere não gerenciar máquina, e nesse caso o contrato diz de quem ele é e o que acontece na saída.
Junto com o repositório vai a documentação de quem assume: como subir o projeto do zero, quais variáveis de ambiente existem, como o banco é migrado, como uma versão é publicada, o checklist de segurança e os registros de decisão. O teste é simples: se a H&I sumir amanhã, outra pessoa sobe tudo seguindo o documento. Se isso não for verdade, a documentação não está pronta.
Next.js, TypeScript, PostgreSQL, Docker. Nenhum framework proprietário nosso, nenhuma plataforma que só a H&I sabe operar, nenhuma mensalidade obrigatória para continuar usando o que você já pagou. Qualquer desenvolvedor competente consegue continuar de onde paramos.
Se o projeto for interrompido, por qualquer motivo e de qualquer lado, você fica com tudo que foi construído até a última fatura paga: no repositório, funcionando ou documentado exatamente como está. Não existe entrega que só se torna sua no fim.
O que é do seu negócio não vira template para o próximo cliente: regra de preço, planilha, base, processo interno. Assinamos NDA sem discussão. O que reaproveitamos entre projetos é o nosso ferramental de infraestrutura e o checklist de segurança, nunca a sua regra de negócio.
As bibliotecas usadas são de licença permissiva e ficam listadas no repositório, com a versão travada. Não existe componente nosso com licença que expire, nem peça que exija pagamento futuro para o sistema continuar rodando.
Se um dia você quiser trocar de fornecedor, passamos o projeto para quem entrar e respondemos às dúvidas da transição. Sem segurar dado, sem segurar senha, sem sumir do telefone. Fornecedor que precisa te prender é fornecedor que sabe que não seria escolhido de novo.
Ele vai mudar. Essa é a pergunta certa a fazer antes de assinar.
Nenhum projeto de software termina exatamente como foi desenhado. Quem promete que sim está vendendo. A diferença entre um projeto tranquilo e um pesadelo é o que foi combinado para a hora da mudança. A regra geral aqui é uma só: nada entra em silêncio e aparece na fatura.
Ficou diferente do que está no Blueprint? Entra no ciclo e não custa nada a mais. Erro de entendimento nosso é custo nosso.
O que foi entregue e não funciona como combinado é consertado, sem discussão sobre quem paga.
Surgiu uma função que não estava no Blueprint? Dizemos quanto custa e o que isso desloca na fila de entregas. Você responde sim ou não por escrito, um e-mail basta. Só depois começamos.
Algumas mudanças não são "mais um campo na tela": elas mudam o desenho do sistema. Nesse caso paramos, revisamos o Blueprint e decidimos junto. Uma conversa difícil agora custa menos que uma entrega errada depois.
Se no meio do caminho ficar claro que uma parte não vale o que custa, avisamos e propomos tirar. Escopo que sai reduz o valor. Não temos interesse em vender tela que a sua equipe não vai abrir.
Três que aparecem em quase toda primeira conversa.
O número honesto só existe depois do Blueprint, porque antes dele qualquer prazo é chute. O que dá para dizer agora é o formato: trabalhamos em ciclos curtos e, ao fim de cada ciclo, existe uma parte funcionando que a sua equipe usa em ambiente de teste. Você não fica meses sem ver nada, e a primeira entrega útil não espera o projeto inteiro terminar.
Melhor assim. No diagnóstico olhamos o que já existe e dizemos o que dá para aproveitar, o que dá para integrar e o que precisa ser refeito, trocar tudo de uma vez raramente é a opção mais barata, e dizemos isso quando for o caso. Uma ressalva: assumir a manutenção de código escrito por outra pessoa passa antes por uma auditoria paga. Sem ler o que está lá, qualquer prazo seria chute.
É o risco mais comum e o que mais derruba projeto, mais do que qualquer decisão técnica. Por isso quem executa o processo participa desde o diagnóstico, vê cada demo enquanto ainda é barato mudar de ideia, e é treinado no go-live na linguagem do dia a dia. Sistema que a equipe não ajudou a desenhar volta para a planilha em duas semanas, e aí o problema não foi o software.
Diagnóstico de 30 minutos, gratuito e sem compromisso: você sai com um resumo escrito do seu problema, e ele é seu mesmo que a gente não trabalhe junto. Traga o que a sua operação usa hoje: a planilha, o app improvisado, a papelada, o grupo de WhatsApp.
Atendimento
Brasil inteiro, remoto. Base em São Sebastião: no litoral norte e no Vale do Paraíba, presencial quando faz diferença. Projetos internacionais a partir de Londres.
