Eu criei um SAAS de criar SAAS, mas não do jeito que você imagina

De 5.000 linhas de caos em um arquivo só… para o projeto dos meus sonhos

Tudo começou com um simples diagrama UML.

Eu sempre gostei de desenhar antes de codar;
Mas, assim que o projeto começava, o diagrama era abandonado (em menos de uma semana).

Não porque eu "não curtia documentação"
mas porque o fluxo era errado: o diagrama virava só uma muleta velha.

E as ferramentas tradicionais de diagramação nunca me ajudaram nisso.
Elas são boas em “desenhar”, mas são burocráticas, frias e desconectadas do código.

Eu queria me sentir bem arquitetando.
Queria me divertir. Criar com calma, com propósito (Ikigai). Deixar a criatividade fluir.

Queria um workspace com a minha cara, ao abrir de manhã me sentir num software que usava quando era criança.

Foi assim que nasceu o AeroUML, com a estética Frutiger Aero, a grande nostalgia dos anos 2000, pensada pra trazer paz e conforto visual enquanto você modela o seu SAAS ou ERP da oficina mecânica do seu tio.

A primeira versão era só vibe coding mesmo:

Um index.html, um React via CDN e mais de 5.000 linhas de código espaguete rodando localmente.

Mas a gente sabe a verdade: quando o contexto cresce, a IA começa a alucinar.
E transformar um arquivo só em um SAAS de sucesso é bem complicado (bem, o Facebook conseguiu em PHP).

Eu precisava de um caminho do meio:

Vibe Coding se torna insustentável a médio/longo prazo se não souber o que está fazendo

Low-code te prende (vendor lock-in) com runtime próprio

Código manual é elegante se bem feito… mas caro e lento de escalar

Diagrama de classes tradicional vira “documentação morta” em poucos dias, isso SE o dev tirar tempo pra fazer um (quem tem tasks pra entregar sabe como funciona).

Arquitetar tudo do zero pra muitos é perda de tempo, e dependendo do escopo do projeto, é mesmo.

Foi aí que veio o estalo:

e se eu automatizasse a elegância?

E se o diagrama deixasse de ser “desenhar e esquecer”
e virasse um modelo vivo que gera código de verdade?

AeroCoding: você só modela o DOMÍNIO. O resto nasce sozinho.

Eu e minha esposa transformarmos o AeroUML em AeroCoding (sim, inspirado diretamente em VibeCoding, mas devolvendo um pouco do controle da qualidade pro dev).

A ideia é direta:

Você modela apenas o domínio (DDD)
e o AeroCoding gera toda a infra ao redor dele, de forma consistente.

Ou seja: você não perde tempo montando o “esqueleto do mundo” toda vez.

O que você modela (e só isso)

Você modela somente o que interessa de verdade:

Aggregate Roots

Entities

Value Objects

Enums

Validações

Reactions (handlers de eventos do domínio)

Sem controller, sem DTO manual, sem repository na mão, sem plumbing infinito.

Você descreve a intenção do sistema.
O resto vira código.

O que o AeroCoding gera automaticamente?

A partir do domínio, ele gera “tudo que normalmente vira repetição e inconsistência”:

✅ DTOs completos (back e front)

input / output

request / response

create / update

tipagem consistente

✅ Validações MULTI CAMADA sincronizadas (back e front)

as regras implacáveis nascem uma vez no modelo

vira validação no backend

vira validação no frontend

✅ Mensagens de erro semânticas e legíveis

menos 400 Bad Request misterioso

mais “campo X é obrigatório / inválido” de forma consistente

✅ Repositories e contratos de persistência

interface + implementação (dependendo do target)

mantendo coerência com a arquitetura escolhida

✅ Unit of Work (UoW)

pra garantir consistência transacional e orchestration limpa

✅ Domain Events

eventos do domínio gerados com estrutura consistente

✅ Reactions / Handlers

você modela a reação (efeito colateral de um evento)

ele monta a infra ao redor: assinatura, wiring, logging, telemetria

✅ Arquitetura pronta ao redor do domínio

Clean, Hexagonal, MVVM, Event Driven (dependendo do preset)

sem gambiarra: cada stack recebe o que é idiomático daquele ecossistema

✅ Principais testes unitários e de integração (back e front)

✅ Lógica de formulários validados no front

E o principal:

✅ Código 100% seu

sem runtime proprietário

sem lock-in

você gera direto na CLI e segue a vida, e se quiser, nem precisa usar o AeroCoding depois disso

Como isso funciona por baixo: engine determinística + templates

Aqui não tem “mágica imprevisível”.

O AeroCoding funciona como uma engine determinística, conectada diretamente ao seu UML:

Você desenha cards e relacionamentos (Aggregate Roots, Entities, VOs, etc)

Isso vira um modelo estruturado (um “graph do domínio”)

Esse modelo alimenta uma camada de geração com templates Handlebars

Os templates geram código de back e front, com variações por framework e arquitetura.

Isso tudo sem IA (ainda não temos esses recursos, mas vamos implementar features muito bacanas no futuro cobrindo essa parte, e não de maneira previsível!)

O ponto aqui é essencial:

Se o domínio é o mesmo, o output é o mesmo.
geração reprodutível, testável, sem “drift”.

Isso resolve um problema clássico do mundo real:
consistência deixa de ser “disciplina do time” e vira propriedade do sistema.

O impacto no dia a dia (na prática)

Coisas pequenas que viram um inferno em projeto real deixam de existir:

❌ esquecer DTO

❌ backend aceitando algo que o frontend não valida

❌ refatorar nome de campo e quebrar metade do sistema

❌ copiar/colar, ajustar, esquecer import e descobrir em runtime

❌ inconsistência em regras e mensagens de erro entre camadas

O AeroCoding não acelera só o início do projeto.
Ele reduz atrito em todas as fases:

menos retrabalho

menos bug bobo

menos fricção entre times

mais entrega com previsibilidade

facilidade em migrar de stack, com documentação viva pronta do zero

Produtividade não é “escrever código mais rápido”.
É não precisar escrever o mesmo código chato toda semana.

Multi-stack, multi-framework, multi-arquitetura

O objetivo nunca foi gerar “código genérico”.

O foco é gerar código que respeita o ecossistema:

backend: Node / .NET (futuramente expandiremos pra Go, Java, PHP e muito mais)

frontend: React (teremos Angular e Flutter também)

arquiteturas modernas: Clean, Hexagonal, MVVM, DDD + Event Driven

E tudo isso partindo do mesmo núcleo: o domínio modelado.

O AeroCoding não existe pra substituir devs

Ele existe pra resolver uma dor real:

boilerplate + inconsistência + documentação morta.

Arquitetura boa não deveria morrer por falta de tempo.
E domínio bem modelado não deveria virar “trabalho manual infinito ao redor dele”.

O AeroCoding é uma tentativa de fazer isso virar o padrão:

você modela o domínio.
e o sistema nasce inteiro ao redor dele.

Queremos tornar o AeroCoding o melhor amigo do desenvolvedor, e não uma ferramenta que vai substituí-lo.

Se você quiser testar / ver funcionando, que tal criar um projeto hoje com o AeroCoding?
Segue o link:
aerocoding.dev

PS: por ser beta, alguns bugs e ajustes visuais podem aparecer, e faz parte. A gente tá iterando rápido e ouvindo feedback real da galera todo dia. Deem uma chance ao AeroCoding! Contamos com a sua presença!