PRODUTO EM PRODUÇÃO

Nexus IA

Nexus IA — Inteligência artificial centralizada

Usar agora Arquitetura

nexus.expostacker.com.br

live preview

Stack tecnológica: FastAPI Python React Vite AI Groq

5
Modelos Nexus: 3
Provedores de IA: 4.7s
Tempo médio resposta

Cliente

ExpoStacker

Setor

Inteligência artificial e produtividade

Linha do tempo

3 semanas · 2026-08

Produto ao vivo

Usar agora

Resultados

Resultados reportados pelo cliente durante o rollout

25/25 Testes de chat OK

Baseline: 11/25 antes do ajuste de event loop

Fonte: Auditoria NEXUS

2.1s Tempo de carregamento do landing

Baseline: sem cache de assets (estimado)

Fonte: Teste local

15+ Media queries para responsividade

Baseline: layout adaptável de 320px a 1200px

Fonte: Auditoria CSS

Dados reportados pelo cliente

O desafio

Nexus IA é um SaaS de inteligência artificial que centraliza múltiplos modelos em um painel comercial. A plataforma oferece cinco perfis de modelos, chat com memória de contexto, geração e execução de código, workspace com terminal e agente capaz de criar arquivos e editar projetos.

Equipes e profissionais desperdiçam tempo alternando entre múltiplas ferramentas de IA, corrigindo respostas com acentuação quebrada e lidando com limites de uso de APIs individuais, o que reduz produtividade e aumenta custos operacionais.

A abordagem

Partimos de um painel simples e evoluímos para uma arquitetura com roteamento por latência, pool de chaves por provedor, cache persistente e fallback automático. O front-end mantém a identidade visual ExpoStacker com responsividade mobile e acessibilidade.

A solução

Painel com cinco modelos Nexus e roteamento automático por tipo de tarefa
Assistente de código com geração, explicação e revisão
Workspace com chat de agente, terminal e ações rápidas
Pesquisa de URL com contexto para respostas baseadas em páginas
Controle de planos, limites e custos por usuário
Landing comercial com SEO, schema.org, sitemap e robots.txt

Linha do tempo

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

Semana 1

Descoberta

Mapeamento de provedores de IA e chaves
Definição dos modelos Nexus e personas
Arquitetura de roteamento e cache

Semana 2

Construção

API FastAPI com chat, código, crawl e agente
Painel comercial com landing e planos
Workspace Vite com login e autenticação

Semana 3

Validação

Testes de todos os modelos e prompts
Auditoria de SEO, sitemap e responsividade
Ajustes de encoding e fallback de provedores

Metodologia

Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.

Sessões de refinamento contínuo

Testes de carga e latência por modelo

Auditoria de SEO e acessibilidade

Padrões ExpoStacker de componentização

Arquitetura

Usuário

Navegador

FastAPI

Nexus IA

Provedores

Groq / Cerebras / Gemini

Workspace Vite

Painel Web

Cache Redis

Banco SQLite

→ FastAPI orquestra chat, código, crawl e agente
→ Roteador escolhe provedor baseado em latência e quota
→ Pool de chaves round-robin por provedor
→ Cache persistente de prompts e respostas
→ React Vite consome a API via prefixo /api

Diagrama conceitual — não reflete implementação real

Stack tecnológica

Escolhas técnicas e o que ficou para fora.

Backend

FastAPI

Por quê: Python async para APIs externas

Alternativa rejeitada: Django (mais pesado)

SQLite

Por quê: Banco local sem dependência de infra externa

Alternativa rejeitada: Postgres (escala futura)

httpx

Por quê: Cliente async para chamadas externas

Alternativa rejeitada: requests (síncrono, bloqueante)

Frontend

React + Vite

Por quê: SPA rápida para o workspace

Alternativa rejeitada: Next.js (excesso para MVP)

Tailwind

Por quê: Tokens consistentes com ExpoStacker

Alternativa rejeitada: CSS puro (mais lento para prototipar)

IA

Groq

Por quê: Baixa latência e custo competitivo

Alternativa rejeitada: OpenAI (custo maior)

Cerebras

Por quê: Modelos grandes sem infra local

Alternativa rejeitada: Ollama local (excluído por escopo)

Gemini

Por quê: Fallback com excelente português

Alternativa rejeitada: Claude (sem chave no projeto)

Decision log

O que escolhi, o que rejeitei e por quê.

Usar roteamento por provedor com fallback

Por que: Evita falhas por indisponibilidade ou quota de um único provedor externo.

Alternativas rejeitadas: Provedor único simplifica o código, mas cria ponto único de falha.

MVP com SQLite em vez de Postgres

Por que: SQLite remove a dependência de banco externo e acelera o deploy inicial.

Alternativas rejeitadas: Postgres oferece mais escala, mas exige configuração de infra extra.

Painel em HTML/CSS vanilla + React Vite para workspace

Por que: Landing rápida e leve; workspace complexo SPA em React para interatividade.

Alternativas rejeitadas: Tudo em React aumentaria o bundle da landing e prejudicaria SEO.

FASSI.AI

Pipeline de roteamento inteligente

Usuário envia a mensagem

Classificador identifica a tarefa

Roteador escolhe o modelo Nexus ideal

Sistema tenta provedores na ordem de score

Resposta é cacheada e registrada para custo

Mecânicas de engajamento

Planos progressivos

Free, Starter, Pro e Business desbloqueiam modelos e limites conforme o uso.

Workspace ativo

Projetos e arquivos mantêm o usuário retornando ao ambiente.

Modelos por tarefa

Nexus Auto, Fast, Standard, Advanced e Code ensinam o usuário a escolher a ferramenta certa.

Segurança e acesso

Segurança e conformidade

Chaves de API externas nunca expostas no front-end
Autenticação JWT com cookies seguros
Rate limit por rota e por plano
CORS restrito a domínios permitidos
Ambiente de dev sinalizado para hardening futuro

Lições aprendidas

Nem tudo saiu como planejado.

— O compartilhamento de clientes HTTP async globais entre requisições síncronas gera erros de event loop. Criar clientes httpx por requisição resolveu timeouts e erros de encoding de provedores externos.