Experiência
O que o usuário vê e toca.
Tecnologias
A stack é consequência
do problema.
Não escolhemos tecnologia por moda nem por preferência: escolhemos a que o seu caso justifica — e explicamos o porquê. Esta é a lista do que dominamos e usamos em produção.
01 Como a stack se organiza
Quatro camadas, uma requisição.
Todo sistema que construímos tem a mesma anatomia: a experiência que o usuário toca, a aplicação que carrega as regras, os dados que precisam sobreviver a tudo e a operação que mantém o conjunto no ar. A tecnologia entra em uma dessas camadas — nunca solta.
Aplicação
As regras que fazem o negócio funcionar.
Dados
O ativo que precisa sobreviver a tudo.
Operação
O que mantém o sistema no ar.
02 O que usamos
Cada ferramenta, no lugar em que ela resolve.
Esta lista descreve o que a empresa domina — não a stack de um produto específico. Em nenhum lugar deste site atribuímos tecnologia a um produto individual: essa informação não é pública.
01
Frontend
ExperiênciaA camada que o usuário toca. É onde performance e acabamento aparecem — ou não.
AngularReactNext.jsTypeScript
02
Mobile
ExperiênciaNativo quando o recurso do aparelho exige; multiplataforma quando o ganho de tempo compensa.
FlutterReact NativeKotlinSwift
03
Backend
AplicaçãoOnde vivem as regras do negócio. A escolha aqui define o custo de manter o sistema por anos.
JavaSpring BootNode.jsPython
04
Integração e segurança
AplicaçãoO contrato entre sistemas — e o controle de quem pode o quê.
REST APIOAuth2JWT
05
Inteligência artificial
AplicaçãoModelos aplicados a problema definido, com revisão humana onde o erro custa caro.
OpenAIClaudeGemini
06
Dados
DadosO ativo que sobrevive a qualquer troca de tecnologia. Modelagem antes de ferramenta.
PostgreSQLFirebaseMongoDBRedisOracleSQL Server
07
Mensageria
DadosPara que um sistema lento não derrube o outro — e nada se perca no caminho.
KafkaRabbitMQ
08
Cloud e DevOps
OperaçãoInfraestrutura dimensionada para o uso real, com custo sob controle.
AWSGoogle CloudAzureDockerKubernetes
09
Entrega contínua
OperaçãoPublicar deve ser rotina previsível, não evento de risco.
GitHubGitHub ActionsCI/CDGitLab
03 O critério
Nenhuma tecnologia entra sem justificar a própria presença.
O que faz uma escolha ser boa
- Resolve o problema com o menor número de partes móveis.
- Tem comunidade, suporte e futuro — não é aposta pessoal de quem escreveu.
- Alguém consegue manter o sistema daqui a dois anos sem arqueologia.
- O custo de operação cabe no orçamento real da empresa.
O que descartamos
- Tecnologia adotada para constar no portfólio.
- Arquitetura distribuída onde um sistema simples resolveria.
- Dependência que prende o cliente ao fornecedor.
- Novidade sem caminho de migração quando ela for abandonada.
A decisão técnica vem antes do código
Qual stack o seu
projeto realmente pede?
Conte o problema. Nós dizemos o que construir, o que comprar pronto e o que simplesmente não fazer.