Um desenvolvedor meu passou um mês tentando atualizar o Vue de um sistema nosso. Não conseguiu, ficou abalado e pediu pra sair da empresa. Uma escolha de arquitetura fez isso. Aqui está a arquitetura mínima que eu recomendo pra quem quer vender software em 2026 — e o erro que eu vejo quase todo mundo cometer no começo.
Resposta rápida: antes de qualquer linha de código, responda uma pergunta: o sistema é pra resolver o seu problema aqui na sua máquina, ou é um SaaS pra você vender? Local, o nível de exigência despenca e você faz quase qualquer coisa. Pra vender, o caminho mínimo é este: (1) escolha o banco de dados pelo que o projeto faz; (2) escolha back end e framework sabendo que framework prende; (3) não faça front end separado se você não precisa — esse é o erro que mata; comece monolito; (4) criptografe dado sensível e nunca salve cartão no seu banco; (5) use MVC, SOLID e migration; (6) Docker + Git ligados num CI; (7) ambientes separados, sandbox e produção no mínimo; (8) log de tudo, senão nem a IA consegue te ajudar a debugar.
Gravei 23 minutos sobre isso em 11/08/2026 no canal @josimarjmv, direto, sem corte. Assista e leia junto: aqui embaixo eu conto a mesma coisa por escrito, com mais calma e com as referências de segurança conferidas por mim.
🎧 PREFERE OUVIR? · 24 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Meu nome é Josimar Machado e eu sou CEO de uma empresa de tecnologia de verdade. Eu tenho CNPJ desde os 18 anos e mexo com esse negócio há mais de 20 anos. Eu coordeno a equipe e boto a mão na massa: tenho todas as IAs que você pensar contratadas e testo todas — Cursor, Codex, Claude, Gemini, Antigravity, VS Code. Eu testo, a minha equipe testa junto, e a gente decide.
E o que a gente opera não é sistema de brincadeira: milhões de views todos os dias, milhares de uploads de vídeo por semana. É um negócio bem pesado. Não é palpite de fora — é o que eu pago pra manter de pé.
Aviso logo: esse texto não é pra quem é muito técnico. É pra empresário, empreendedor, microempreendedor, pra quem é vibe coder e não entende muito de código mas quer entender. Se um cara muito sênior ler isto aqui, vai me xingar bastante — porque eu vou abstrair coisa que ele acha sagrada. Beleza? Vamos lá.
Essa é a primeira coisa de todas, e é onde quase todo mundo pula etapa.
Você chega e fala: "ô Claude, faz pra mim uma dashboard e conecta no Google pra trazer o relatório financeiro do CSV que eu exportei do meu banco". Ele faz. Muito simples. Resolve o seu problema local e está tudo bem.
Aí você acha a sua dashboard muito legal, conversa com outras pessoas, enxerga um gap de mercado e resolve subir essa dashboard. Subir, no nosso jargão, é tornar ela disponível online. E aí começam todos os problemas.
Eu já escrevi aqui sobre quando vale fazer o seu software em vez de contratar um SaaS pronto. Este texto é o passo seguinte: você decidiu fazer e vender.
Vou direto no que dá título a isso aqui, porque é o vacilo que eu mais vejo.
Você conversa com a IA e ela quer fazer pra você um container, um build, um CI de um front end em React — porque todo mundo usa React, o mundo usa React. E você aceita. Isso é um erro gigante se você não precisa.
Você só faz front end separado se precisa de algo que o Laravel ou o Django não te entregam integrado. No Django, por exemplo, você faz inline: o visual, o CSS e o JavaScript misturados no código, igual era 20 anos atrás. É meio porquinho, mas funciona — e funciona muito bem, muito estável.
Pergunta que resolve a discussão: o seu sistema é um CRUD? Se é, pra que front separado? É besteira. E é besteira cara, porque assim que você separa, você precisa de uma API pro front conversar com o back — aí entra Node pra fazer API, ou FastAPI do Python — e o grau de complexidade sobe de degrau. Dois CIs, dois builds, dois deploys, duas coisas pra quebrar.
Front separado se justifica quando você vai usar os componentes do React de verdade: aplicação que precisa funcionar muito no componente, sem conexão com o back end, efeito visual pesado, coisa que não é CRUD. Aí sim, vale o preço. Fora disso, é over engineering.
Se você está começando, faça tudo junto: monolito. É mais fácil pra você lidar com um monolito do que ficar fazendo coisa tudo separada. Acredite. E ele não te amarra — por mais que seja um monolito, dá pra separar depois, quando existir um motivo de verdade e não um motivo de moda.
Antes de falar de banco, preciso te contar por que eu levo escolha de tecnologia tão a sério. Uma coisa importante que quem está começando não sabe: quando você escolhe um framework, você fica preso nele pro resto da vida — a não ser que depois você queira refatorar tudo.
A gente tinha um sistema grande e complexo na empresa que usava Vue, e foi pro Vue 2. Quando precisou atualizar esse Vue, quebrou tudo, porque mudaram muita coisa de uma versão pra outra e o sistema era muito complexo.
Um desenvolvedor meu ficou um mês tentando atualizar. Tentando, tentando, tentando. E o negócio foi tão complicado que ele não conseguiu — e ficou tão abalado psicologicamente que pediu pra sair da empresa. Olha o tamanho do estrago de uma escolha de arquitetura. Pode ter sido escolha errada, pode ter sido falta de manutenção a cada atualização do Vue — e aí vem a bomba gigante de uma vez.
Final feliz: recentemente a gente conseguiu atualizar, graças à ajuda da inteligência artificial. A gente pegou todos os gaps e deu uma limpada boa naquele backlog. Mas o preço já tinha sido pago, e não foi em dinheiro.
Tem um monte de banco pra necessidades diferentes, e muita aplicação usa mais de um ao mesmo tempo:
Pra escolher, você tem que responder o que o seu projeto vai fazer. O meu projeto é um CRUD. O que é CRUD? Cadastro, leitura, edição e remoção de conteúdo — é uma sigla em inglês que quer dizer isso. Manutenção de formulário, basicamente.
Exemplo de CRUD simples: um sistema de supermercado. Você cadastra produto, coloca estoque; na outra ponta lê produto, lê estoque, bipa e dá baixa. E olha, não caia na besteira de achar que sistema de supermercado é simples — tem entrada, saída, retenção, caixa, maquininha, cruzamento de informação, e hoje em 2026 tem muita automação e conciliação de estoque no meio, que é um problema grande por si só. É um sistema grande e complexo. Mas é um CRUD. São vários CRUDs.
Outro exemplo, mais leve: um CRM pra dentista controlar cliente, disparar e-mail, disparar WhatsApp e fazer gestão de agenda. Mais simples que o supermercado. Qual a necessidade desse cara? Um MySQL, um MariaDB — curva de aprendizado muito menor e documentação mais farta. Entre eles e o PostgreSQL é meio pau a pau pro dia a dia, mas o PostgreSQL é mais robusto, é um negócio pra aguentar muito mais porrada. Em compensação, clusterizar um PostgreSQL é mais complexo que clusterizar um MySQL ou MariaDB. Escolha pelo que você vai precisar, não pelo que é mais bonito no currículo.
Você vai ter um front conversando com um back — e back end é aquilo que processa o que você está fazendo. Qual tecnologia? Aqui vai a minha opinião, e ela é minha mesmo:
O meu motivo é prático: eu acho que ele quebra mais fácil. Ele permite você fazer código mais cagado — desculpa o termo chulo — e permite botar no ar uma coisa que pode quebrar mais fácil. Diferente de um Python ou de um PHP, que nem sobem se estiver errado.
E se você é bem cru, usar um framework — um Django, um Laravel — vai te ajudar muito, muito mesmo. Sim, eu acabei de contar o caso do Vue. As duas coisas convivem: framework prende, e framework também é o que te faz sair do zero sem cometer 200 erros de segurança sozinho. Escolha sabendo do peso, e mantenha atualizado — o estrago vem quando você deixa a atualização acumular.
E sim, eu sei que existem centenas de frameworks, back ends e linguagens. Eu estou falando aqui pra quem está começando esse negócio e quer fazer uma coisa minimamente aceitável entendendo o que está fazendo.
Se o seu negócio é botar no ar e vender, saiba os riscos que você está correndo: LGPD, vazamento de dados. Anote isto aqui:
Esse último item é o que separa quem vai sobreviver de quem vai aparecer no jornal. Se a IA falou que criptografou nome, CPF e e-mail, você tem que ir lá olhar se está criptografado de verdade. Você tem que conferir as coisas que a IA faz. Essa maldade você tem que adquirir. Jogar só na IA pode te dar problemas gigantescos. Gigantescos.
Checagem minha em 13/09/2026, pra você não ter que acreditar em mim: a Lei Geral de Proteção de Dados (Lei 13.709/2018) diz no artigo 46 que quem trata dado pessoal deve adotar medidas de segurança técnicas e administrativas aptas a proteger esse dado de acesso não autorizado e de situações acidentais ou ilícitas. E o OWASP Top 10 lista "Cryptographic Failures" como a categoria A02:2021, a segunda maior classe de risco em aplicação web — exatamente dado sensível trafegando ou parado sem proteção. Não é frescura minha: é a lei de um lado e o consenso técnico do outro.
É a mesma linha de raciocínio que me faz escolher onde o meu código mora. Eu já expliquei aqui por que eu não uso GitHub, Supabase ou Firebase em produção — e no vídeo eu falo a mesma coisa: eu não gosto de GitHub, pra mim vaza código e vaza informação, e vive dando problema. Paciência, eu sou contra. Eu uso GitLab desde sempre e sempre vou usar. E o meu é o meu mesmo: instalado na minha rede, na minha operação, e só funciona dentro da minha VPN. Segurança, medo, soberania. É o meu jeito de trabalhar.
Tem três coisas que eu mando colocar em qualquer projeto, e você pode pedir pra IA em uma frase cada:
Migration é o item que ninguém valoriza até precisar. Ela é o seu seguro pro momento de catástrofe. Deu pau, preciso subir em outro lugar, como é que eu faço? O seu sistema tem que estar pronto pra começar do zero a qualquer momento — você roda um ou dois comandos e ele está no ar inteiro, rapidinho, em outra estrutura. Ele tem que estar pronto pra isso.
Ah, e os ORMs da vida existem justamente pra fazer a conexão com os bancos de forma organizada. Use.
Tudo que você for fazer, você vai usar Docker: Docker build, Dockerfile, imagem do back, do front, do banco. Por que Docker? Porque é assim que você integra com o seu GitLab ou GitHub: você desenvolve local no Docker, sobe pro Git, e o Git faz o build e o deploy no ambiente que você configurou. Isso é o CI.
Aliás, é isso que o CI é, sem mistério: o CI é o mesmo Docker build que você faria na mão, só que remoto — e com a vantagem de armazenar e versionar tudo fora da sua máquina, pra você voltar a versão antiga a qualquer momento.
E o Git: se você quer trabalhar com software, aprenda a trabalhar com Git. É essencial. Não dá pra mexer com software sem Git. Git não é GitHub nem GitLab, que são plataformas — se você quiser fazer um Git num pen drive, funciona normal, cara. Normal.
No desenvolvimento com IA, o Git é parte fundamental pro seu negócio dar certo. É ele que garante o seu rollback. Vou fazer uma feature nova, um botão que posta automático no Facebook: eu abro uma branch pra isso, testo, faço o merge do sandbox pra produção — e se quebrar, se estragar, se danificar alguma coisa, eu volto pra versão antiga. Você não precisa ser o maior especialista do mundo, mas precisa entender minimamente branch, commit, merge, versionamento e rollback.
O Git conecta os seus ambientes. E o padrão numa empresa de desenvolvimento é este:
O ponto que eu faço questão de bater: o sandbox tem que ser separado de verdade — outro banco de dados, outro back, outro front, outro tudo, igualzinho à produção. É pra você quebrar à vontade. Dali você faz o merge pra produção.
Esse é o fluxo que você precisa entender minimamente pra conseguir colocar uma IA dentro desses processos pra fazer o trabalho pra você. E é também o que tira o seu medo: eu já contei aqui como eu perdi o medo de subir em produção, e não foi coragem — foi processo.
E por fim, todo esse fluxo tem que ter observabilidade. Eu tenho que ter logs claros: quem fez o quê, onde e quando. Seja usuário, seja sistema, seja pessoa.
Senão, no momento em que der problema e um cliente te mandar mensagem, você não vai saber ajudar o cliente. Isso é uma bomba. E tem o agravante novo de 2026: você, que não entende de código pra fazer debug, vai ter que pedir pra IA fazer o debug. Como é que ela vai debugar se não tem log?
Então coloca isso no pré-requisito da IA, lá no desenvolvimento do sistema: log completo, de tudo. A partir daí você tem um ambiente de observabilidade pra ver tudo que acontece no sistema. Esse assunto merece um texto só dele, e eu vou escrever — por ora, fica a regra: quem fez, o quê, onde, quando.
Fazendo o overview por cima: em 2026, a inteligência artificial entra em todos esses estágios. Hoje ela pode assumir o posto de um desenvolvedor júnior pra você.
Na prática funciona assim: você cria as tarefas explicando o que quer, ela desenvolve, você testa, lê o código, faz review e faz o merge pro staging. Testa de novo no staging. Deu certo? Merge pra produção. Simples de descrever, e funciona — desde que o caminho já exista.
Repare que a IA não substituiu nenhuma decisão deste texto. Ela não escolheu o seu banco, não decidiu se você precisa de front separado, não criptografou por conta própria e não inventou o seu log. Ela anda rápido no caminho que você construiu. Se o caminho não existe, ela anda rápido em círculos — e é por isso que eu já escrevi aqui que MicroSaaS em 2 dias não existe.
Dentro do fluxo que eu descrevi acima, você tem um overview da fórmula completa pra ter um ambiente de desenvolvimento de verdade e desenvolver o seu SaaS em 2026. Não é a fórmula completa — é o mínimo que eu não abro mão.
Se você quer fazer isso comigo, na prática: a Imersão de SaaS é exatamente este caminho com o seu projeto na mesa — segurança, banco, deploy, domínio, monitoramento e cobrança. Tem também a Imersão de Sites, que é a fábrica de sites com a parte comercial junto, e ainda chatbot e infraestrutura. Data, preço, formato e condição de cada uma estão em todas as imersões — é a página que vale, nunca o que eu falei num vídeo.
Nota de cronologia (importante). Esse relato é da gravação que eu publiquei em 11/08/2026, e você está lendo em setembro. Duas coisas mudaram desde lá: a imersão de 15/08/2026 que eu convido no vídeo já aconteceu, e a Imersão de SaaS, que na gravação ainda não tinha data nem formato fechado, hoje tem página própria com tudo definido. Por isso não use este texto nem a gravação pra saber data, preço, formato ou condição — use todas as imersões, que é o que vale. A parte técnica — arquitetura, banco, framework, Docker, Git, ambientes e log — continua valendo igual.
TODA SEGUNDA · MEIO-DIA · AO VIVO
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.
Baseado na gravação do canal @josimarjmv publicada em 11/08/2026 (23min35), com transcrição própria das legendas do próprio vídeo. O caso do sistema em Vue, o desenvolvedor que passou um mês tentando atualizar e pediu pra sair, a atualização recente com ajuda de IA, o GitLab próprio rodando dentro da VPN, os milhões de views por dia, os milhares de uploads de vídeo por semana, o CNPJ desde os 18 anos e as preferências de linguagem e banco são da minha vivência tocando a JMV Technology. Conferido por mim em 13/09/2026: o artigo 46 da Lei Geral de Proteção de Dados (Lei 13.709/2018), que obriga medidas de segurança técnicas e administrativas para proteger dado pessoal, e a categoria A02:2021 — Cryptographic Failures do OWASP Top 10. Documentação oficial citada: PostgreSQL e Docker, sem relação comercial. Data, preço, formato e condição de cada imersão são os que estão em todas as imersões.