Software custom enxuto pra empresa de manutenção agrícola: roda a operação (OS, ativo, estoque, custeio, portal do cliente) e alimenta a contabilidade que o Hugo já usa. Sem reinventar fiscal/razão. Stack, CAPEX × OPEX e métricas de construção.
Como o Hugo é contador (CRC ativo) e já fecha os livros no sistema dele, o software novo não precisa ser a contabilidade — precisa alimentá-la com dado limpo. Isso libera o melhor caminho pro time de vocês: construir custom só a camada operacional (a praia de vocês dois), emitir nota por API e exportar pra contabilidade do Hugo. Sem carregar o passivo de um motor fiscal próprio bem no meio da Reforma Tributária.
Caminho C — custom enxuto que alimenta a contabilidade do Hugo. Você constrói o miolo operacional (OS, ativo, estoque e custeio = sua especialidade), o portal do cliente e o app de campo. A parte chata e perigosa — razão contábil, motor de tributos, emissão de NF-e — você não constrói: nota sai por API (PlugNotas/Focus) e a contabilidade fica no sistema que o Hugo já roda. Você possui 100% do código operacional (vira ativo revendável) sem o passivo fiscal eterno.
Ter Hugo (CRC) + você (suprimentos/planejamento) é raro e de-risca o projeto. Mas isso barateia especificação e validação, não a engenharia. Saber a regra fiscal ≠ ser barato construir e manter um motor fiscal que sobrevive a auditoria e a mudança de lei. Daí o ranking frio:
| Caminho | Esforço | Manutenção fiscal | Veredito |
|---|---|---|---|
| A · Custom ERP completo do zero | ~280–320h | Sua, eterna, na Reforma | Não reinventa razão + tributos |
| B · Odoo all-in-one | ~140h | OCA/comunidade | Plano B troca a ferramenta do Hugo |
| C · Custom enxuto + alimenta o Hugo | ~143h | Não é sua (API + Hugo) | Recomendado encaixa nas 2 expertises |
Os 3 motivos frios de não construir o motor fiscal: (1) NF-e/NFS-e do zero é armadilha — certificado, webservice por estado, contingência, NFS-e por município migrando pra Nacional; time pequeno usa API. (2) Reforma Tributária 2026–2033 (CBS+IBS substituindo PIS/COFINS/ICMS/ISS) — motor próprio = você re-engenheira durante 7 anos de transição. (3) O Hugo carimba o CRC nos números — ele não troca um razão validado por um caseiro.
Ciclo completo: abertura → avaliação → orçamento → aprovação → execução por etapas → fechamento, com fotos e assinatura.
Cadastro dos equipamentos dos clientes (frota, horímetro, histórico) — base da manutenção preventiva e corretiva.
Sua praia: entrada/saída de peças, custo médio, custo real da OS, margem. O coração operacional.
Pedir manutenção, ver prévia de custo, acompanhar etapas, aprovar valores. Detalhe abaixo.
NF-e/NFS-e emitida a partir da OS via PlugNotas/Focus. Você não constrói SEFAZ — você chama.
Receita, custo e movimento de estoque exportados pro sistema que o Hugo já usa. A operação alimenta os livros.
O fluxo do dado: a operação acontece no AgroService → gera receita/custo/baixa de estoque → a nota sai por API → tudo é exportado limpo pra contabilidade do Hugo, que fecha os livros e cuida do fiscal lá. "As operações refletem na contabilidade" — seu pedido original, feito do jeito certo.
É o trecho mais custom — e o que separa isto de um sistema de OS genérico. Duas entradas:
ação do cliente ação do backoffice interno/técnico — adoção do portal é opcional: o backoffice cobre quem não quiser usar.
Referência de padrão-ouro: o mercado (ServiceTitan) é cloud-native, mobile-first, API-first e modular. O caminho C honra esses pilares no que importa pra operação, e deliberadamente terceiriza os dois pilares mais caros de manter — fiscal e contábil — pra quem já faz (API de nota + Hugo). Decisão de engenharia, não de preguiça.
Ordem de grandeza (R$), operação de uma empresa (a do Hugo). CAPEX = build único (assinatura Claude; suas horas entram como presença, não caixa). OPEX = recorrente mensal.
A assinatura é custo por mês corrido, não por hora. O lever do CAPEX não é "quantas horas" — é quantos meses você segura o tier alto. Como o build queima em ~5–7 semanas, você fica no Max 20× só nas ~3–4 semanas de construção pesada e cai pro 5× na validação/piloto. Por isso ~R$1,3–1,7k, não 3 meses de assinatura. Comprimir o calendário corta o CAPEX direto.
| Caminho | CAPEX (build) | OPEX (R$/mês) | Manutenção fiscal |
|---|---|---|---|
| A · Custom ERP completo | ~R$ 4,5–6,6k | ~R$ 150–400 | Alta sua, na Reforma |
| B · Odoo all-in-one | ~R$ 2,8–3,3k | ~R$ 200–500 | Compartilhada OCA |
| C · Custom enxuto + Hugo | ~R$ 1,3–1,7k (Max 20× só nas ~3–4 sem de build, 5× no resto) | ~R$ 200–450 infra + API de nota + WhatsApp | Não é sua API + sistema do Hugo |
Quase nada de caixa novo. A F0 é majoritariamente tempo (você + Hugo); o desembolso pra começar é mínimo:
| Item | Custo | Nota |
|---|---|---|
| Certificado digital A1 (e-CNPJ) | R$ 0–150 | Reusar o da empresa — ela já emite nota |
| Domínio .com.br | ~R$ 40/ano | — |
| Hosting (VPS) 1º mês | ~R$ 100 | Sobe pouco conforme uso |
| Conta API de nota (PlugNotas/Focus) | R$ 0 setup | Paga por documento emitido, depois |
| Pra ligar (fora a assinatura Claude) | ~R$ 140–290 | O resto é tempo |
| Assinatura Claude (mês do build) | R$ 550–1.100 | 5× na F0, sobe p/ 20× quando o build pega |
Saídas do projeto. O build comprime em ~M0–M1; daí vira só OPEX. Sem linha de receita aqui — o retorno é a eficiência operacional da empresa (e o upside de virar SaaS do setor depois, fora deste escopo).
| Mês | O que roda | Claude | Infra+API+Wpp | Saída | Acum. |
|---|---|---|---|---|---|
| M0 | F0→F4 (build pesado) | R$ 1.100 (20×) | R$ 150 | R$ 1.250 | R$ 1.250 |
| M1 | F5→F7 (tail + piloto) | R$ 550 (5×) | R$ 350 | R$ 900 | R$ 2.150 |
| M2 | operação | — | R$ 350 | R$ 350 | R$ 2.500 |
| M3 | operação | — | R$ 350 | R$ 350 | R$ 2.850 |
| M4 | operação | — | R$ 350 | R$ 350 | R$ 3.200 |
| M5 | operação | — | R$ 350 | R$ 350 | R$ 3.550 |
Consistência: build (M0–M1) = ~R$ 2,15k, dos quais ~R$ 1,65k é a assinatura Claude (1 mês 20× + 1 mês 5×) — bate com o "IA do build ~R$ 1,3–1,7k". OPEX estabiliza em ~R$ 350/mês. Em 12 meses: R$ 2,15k + 10×R$ 350 ≈ R$ 5,7k = o TCO. Quando virar SaaS do setor, uma linha de receita per-seat por oficina inverte o fluxo pra positivo — fora do escopo deste build.
Claude codifica, você valida e dá as chaves; Hugo define o que a contabilidade precisa receber e valida o fiscal. ~143h de presença sua. A 35h/semana, isso é ~4 semanas do seu tempo; com as esperas externas, ~5–7 semanas corridas.
O calendário não é gargalo das suas horas — é das esperas externas. O que estica além das suas ~4 semanas de trabalho não acelera por você queimar mais: a sessão de mapeamento com o Hugo (F0), o certificado A1 + homologação da NF-e, e o piloto rodando OS real (F7 precisa de mundo rodando, não dá pra forjar). Se o Hugo estiver disponível e o certificado sair rápido, encurta.
| Fase | Entregável visível | Suas horas |
|---|---|---|
| F0 · Mapeamento | Hugo: o que a contabilidade precisa receber + mapeamento. Você: fluxo de OS/suprimentos. Stack e ambiente decididos | ~10h |
| F1 · OS + Ativo | Ciclo da OS rodando + equipamentos dos clientes cadastrados | ~22h |
| F2 · Estoque + Custeio | Entrada/saída de peças, custo médio, custo real da OS, margem | ~20h |
| F3 · Portal + aprovação crítico | Cliente pede, vê prévia, aprova escopo/etapas; backoffice abre OS em nome do cliente | ~28h |
| F4 · Nota por API | NF-e/NFS-e emitida a partir da OS via PlugNotas/Focus | ~15h |
| F5 · Ponte contábil | Export/integração de receita, custo e estoque pro sistema do Hugo | ~14h |
| F6 · App de campo | Skin do protótipo como PWA offline-first + WhatsApp | ~20h |
| F7 · Piloto | Operação real do Hugo rodando de ponta a ponta | ~14h |
| Total | Sistema operando a empresa, alimentando a contabilidade | ~143h |
Custo de IA do build: ~R$ 1,3–1,7k — Max 20× só nas ~3–4 semanas de build pesado, 5× na validação/piloto. Não 3 meses de assinatura. Praticamente o único gasto de caixa pra sair do zero.
| # | Risco | Por quê | Mitigação |
|---|---|---|---|
| 1 | Portal de aprovação médio | Prévia pré-avaliação + escopo pós-avaliação + aprovação por etapa = regra custom | Espelhar o processo real do Hugo na F0; é o foco da F3 |
| 2 | Ponte com a contabilidade médio | Mapear receita/custo/estoque pro plano de contas do sistema do Hugo | Hugo define o de-para (é a praia dele); confirmar qual sistema na F0 |
| 3 | Integração de nota (API) baixo | Certificado + particularidades do município/estado | API (PlugNotas/Focus) abstrai; Hugo valida o enquadramento |
| 4 | Custeio de estoque baixo | É dado financeiro — erro vira custo errado | Sua especialidade; Hugo confere o resultado contábil |
| 5 | Conectividade no campo baixo | Fazenda sem sinal | PWA offline-first; sincroniza ao voltar o sinal |
| 6 | Adoção pelos clientes negócio | Nem todo cliente vai usar o portal | Backoffice abre OS por ele — adoção é opcional |
Repara: sumiram os riscos fiscais pesados (motor de tributos, SEFAZ, Reforma). É o ganho central do caminho C.
Exercício invertido: assumir o fracasso e trabalhar de trás pra frente. Não é pessimismo — é blindagem. Os antídotos viram itens de checklist de cada fase.
| Fase | Como o projeto morre aqui | Sinal precoce | Antídoto (vira checklist) |
|---|---|---|---|
| F0 · Mapeamento alto | Levantamento raso: modela a operação ideal, não a real. Ou o Hugo não engaja e a F0 nunca fecha. | Respostas "depende"; passou de 2 sessões; ninguém abriu o sistema contábil real. | F0 só fecha com artefato concreto: fluxo da OS real validado por quem opera + tabela de serviços/peças + plano de contas exportado + formato da ponte definido. |
| F1 · OS + Ativo médio | Máquina de estados errada (falta retrabalho, garantia, OS reaberta) → reescrita cara. Ativo subdimensionado (sem implemento/horímetro/série). | Técnico dizendo "e quando acontece X?" que o fluxo não cobre. | Validar a máquina de estados contra 5–10 OSs históricas reais antes de codar. Ativo espelha o que a operação já controla. |
| F2 · Estoque + Custeio alto | Custo da OS mentiroso (custo médio errado, baixa que não bate) → margem falsa → Hugo não confia no número. | Custo que não bate com o que o Hugo sabe; saldo de estoque impossível. | Sua praia: reconciliar com o estoque físico real; Hugo confere o custo contra a realidade; testar com movimentações reais. |
| F3 · Portal + aprovação crítico | O fluxo não espelha como o cliente decide. Ou over-engineering: 28h num portal lindo que o cliente não usa. Ou a prévia gera expectativa que a avaliação quebra. | No piloto, o cliente liga em vez de usar o portal; o backoffice abre tudo por ele. | Backoffice primeiro (sempre funciona), portal opcional. Testar a prévia com cliente real antes de generalizar. Manter o fluxo simples. |
| F4 · Nota por API crítico | Enquadramento errado (CFOP/NCM/ISS/CST) → nota rejeitada ou, pior, aceita errada = problema fiscal real. Homologação de NFS-e municipal arrasta. | Rejeições na homologação; Hugo apontando enquadramento errado. | Hugo valida o enquadramento antes de emitir em produção; homologar com casos reais; a API existe pra abstrair a SEFAZ. |
| F5 · Ponte contábil alto | De-para errado/incompleto → dado sujo entra na contabilidade → Hugo volta a lançar na mão → o projeto perde o propósito. | Hugo reconciliando na mão o que devia vir pronto; divergência no fechamento. | Hugo define o de-para (é dele); confirmar na F0 se o sistema dele importa (formato); reconciliar o 1º mês inteiro antes de confiar. |
| F6 · App de campo médio | Offline-first mal feito (perde registro/foto no sync) ou UX ruim no campo (sol, mão suja, muitos toques) → técnico volta pro papel. | Técnico usando WhatsApp/papel em paralelo "porque é mais rápido". | Testar offline de verdade (modo avião + conflito de sync); manter a UX simples do protótipo; um técnico real testa antes. |
| F7 · Piloto crítico | Piloto de mentira (2 OSs forçadas e declara vitória). Ou escopo que nunca fecha (cada OS revela um caso novo). Ou a operação resiste à mudança. | Sistema antigo rodando em paralelo "por segurança"; lista de ajustes que só cresce. | Piloto = N OSs reais de ponta a ponta (ex 15–20), antigo desligado pra esses casos. Congelar o escopo do MVP (caso novo = backlog v2, não bloqueia). Medir adoção. |
Crítica justa: a tabela acima jogou quase toda a morte no Hugo. Dois motivos — um real, um viés. Real: o caminho C tirou de propósito a engenharia mais perigosa (motor fiscal/contábil), então sobra menos risco de código. Viés: tratar "Claude constrói" como seguro — e é onde mais se bateu cabeça no ecossistema. O que é seu:
) extra que quebrou o JS inteiro e foi racionalizado como "pré-existente". Atinge F1/F3/F6. Antídoto: validar no sistema vivo, nunca no doc; node --check; testar no real antes de declarar feito.Padrão por trás das mortes: do lado da operação, quase nenhuma é técnica — é realidade não capturada (F0/F1), confiança perdida no número (F2/F5) ou adoção que não acontece (F3/F6/F7); antídoto = validar contra a operação real, cedo, com quem opera. Do seu lado o padrão é outro: casca, escopo que escorrega e código não-revisado no sistema vivo; antídoto = conferir no real, nunca no doc, e congelar escopo. Os dois lados morrem de excesso de confiança — um no "parece bem" do cliente, outro no "parece pronto" da tela.
As duas expertises cobrem o miolo: você (suprimentos/planejamento/custeio) constrói a operação; Hugo (CRC) garante que o dado chega certo na contabilidade dele.
Sinergia: a empresa onde o Hugo atua é o cliente-piloto perfeito — ele tem o processo, o sistema contábil e a decisão. O produto nasce resolvendo uma dor real, validado por um contador de dentro, sem mexer no que já funciona pra ele. Depois vira SaaS do setor.
Próximo passo: uma sessão com o Hugo pra mapear o processo da operação e bater as decisões. Com isso, a F0 fecha numa sessão e a F1 (primeira OS rodando) começa. Quando bater o martelo, chama "vamo no AgroService".