Arquitetura, produto e código com propósito

Este repositório representa dois universos que se cruzam: Steply, uma operação de tecnologia focada em execução real de produto, e LucasHiago, a identidade técnica por trás das decisões, arquitetura e código.

Não é sobre frameworks da moda.
É sobre resolver problemas reais com engenharia sólida.

Site: https://steply.com.br

Steply é uma operação de outsourcing técnico e desenvolvimento de produto focada em startups, empresas em crescimento e fundadores que precisam de execução, não de promessa.

A Steply nasce da dor clássica do mercado:

• Projetos que não saem do papel
• Código sem dono
• Arquitetura improvisada
• Times inchados sem eficiência

Aqui, a proposta é simples: engenharia responsável, entrega contínua e visão de negócio.

Site: https://www.lucashiago.com.br

Este site é o manifesto técnico.
Não é portfólio genérico. É um mapa mental de como eu penso software, produto, arquitetura e crescimento.

É onde ficam:

• Estudos
• Experimentos
• Manifestos
• Provas de conceito
• Artigos técnicos
• Ideias que ainda não viraram produto

Código é uma consequência.
Arquitetura é uma decisão.
Produto é um compromisso.

Alguns princípios que guiam tudo aqui:

• Simplicidade antes de abstração
• Escala pensada desde o MVP
• Código legível vence código esperto
• Frontend não é só UI, é estado, performance e experiência
• Backend não é CRUD, é regra de negócio
• Infra existe para não ser percebida

Usado quando o projeto exige:

• Estado complexo
• Forms robustos
• Longa vida útil
• Escalabilidade de equipe

Destaques:

• Signals
• Standalone Components
• SCSS com design system próprio
• PWA first
• Arquitetura orientada a domínio no front

Usado quando a prioridade é:

• Performance
• SEO
• Time-to-market
• Dashboards e produtos B2B

Destaques:

• App Router
• Server Components
• TanStack Query
• Bryntum Gantt
• Integração pesada com APIs e estados complexos

O coração de quase tudo.

Motivos:

• Arquitetura clara
• Escala natural
• Código previsível
• Ótimo para times

Destaques:

• DTOs bem definidos
• Guards e Interceptors
• Domain-driven migrations
• Integração com filas, workers e IA
• APIs pensadas para evolução, não só para funcionar hoje

Usado estrategicamente em:

• Sistemas administrativos
• Backoffices
• Projetos legados bem tratados

Destaques:

• Laravel 9+
• Vue 2.7
• Policies bem definidas
• Permissões com Spatie
• Performance cuidada, sem magia desnecessária

Quando o projeto é sério.

• Domínios customizados
• Tipos fortes
• Triggers conscientes
• Migrações versionadas

Quando o contexto pede compatibilidade ou legado.

• Diagnóstico de performance
• Slow query log
• Índices bem pensados
• Sem SELECT *

• Docker & Docker Compose
• PM2
• Vercel
• Linux first
• Monitoramento real, não só dashboard bonito
• Scripts próprios para diagnóstico e manutenção

Infra aqui não é luxo.
É fundação.

Não como buzzword. Como ferramenta.

• LLMs locais (Ollama)
• APIs de IA para geração de conteúdo e interfaces
• TTS com Piper
• Experimentos com agentes e automação de processos
• IA integrada ao produto, não jogada por cima

Alguns projetos que orbitam este ecossistema:

• Organos
  PWA de gestão para MEI e pequenos negócios

• Dashboards internos

• Ferramentas de automação

• Provas de conceito em web, jogos e IA

Construir:

• Produtos sustentáveis
• Código que envelhece bem
• Times que entendem o que estão fazendo
• Sistemas que não implodem em 6 meses

Steply é o veículo.
LucasHiago é o arquiteto.

• Site Steply: https://steply.com.br
• Site pessoal: https://www.lucashiago.com.br
• LinkedIn: https://www.linkedin.com/in/lucashdsf/

Software não é arte abstrata.
É engenharia aplicada ao mundo real.

Este ecossistema não nasceu de tutoriais.
Nasceu de problemas reais, demandas de cliente, gargalos técnicos e curiosidade aplicada.

Alguns projetos viraram produto.
Outros viraram base arquitetural.
Todos deixaram código melhor do que encontraram.

Um módulo reutilizável para documentação viva de APIs em NestJS.

Não é só Swagger plugado.
É uma camada pensada para padronizar, versionar e organizar documentação em projetos médios e grandes.

• Swagger espalhado
• Controllers poluídos
• Documentação quebrando a cada refactor
• Falta de padrão entre squads

• Módulo isolado e plugável
• Organização por domínio
• Integração limpa com DTOs
• Pensado para projetos enterprise

Esse módulo nasceu da dor de manter APIs grandes sem virar bagunça.

Asteroth é um projeto experimental que cruza:

• Backend robusto
• Automação
• Conceitos de agentes
• Arquitetura orientada a eventos

É um laboratório de ideias onde arquitetura vem antes da interface.

Aqui entram:

• Testes de LLMs
• Integração de IA com regras reais
• Pipelines que não dependem de hype

Nem todo projeto precisa virar SaaS.
Alguns existem para afiar a lâmina.

Aplicação desktop construída com Electron para gerenciamento e suporte a ambientes de poker.

• Desktop multiplataforma
• Integração com APIs externas
• Gerenciamento de estado local
• Performance cuidada mesmo fora do browser

Esse projeto mostrou claramente que:

Electron não é gambiarra quando bem arquitetado.

API backend construída como núcleo de um ecossistema.

Pensada desde o início para:

• Escalar
• Ser consumida por múltiplos frontends
• Evoluir sem quebrar tudo

• NestJS
• PostgreSQL
• Autenticação sólida
• Domínio bem separado de infraestrutura

galax-api é base.
Sem pressa. Sem atalhos.

Camada de e-commerce desacoplada, construída sobre a galax-api.

• Backend-first
• Regras de negócio claras
• Preparada para múltiplos canais
• Não acoplada a tema ou frontend específico

Aqui a ideia nunca foi “loja bonita”, e sim negócio sustentável.

Sistema focado em microempreendedores individuais (MEI).

Simplificar emissão, controle e entendimento de notas fiscais.

• Interface simples
• Linguagem acessível
• Backend confiável
• Nada de overengineering

NFMEI nasce da observação direta:

Pequenos negócios sofrem porque sistemas são feitos para empresas grandes.

Sistema de gestão voltado para o segmento de moda.

• Controle de coleções
• Estoque
• Processos internos
• Organização de fluxo

Aqui o desafio não era técnico.
Era traduzir um negócio específico para software sem forçar o cliente a se adaptar ao sistema.

Além dos projetos autorais, já atuei em:

• Sistemas administrativos
• Backoffices complexos
• Dashboards operacionais
• Migração de sistemas legados
• Reestruturação de código caótico
• Performance tuning em bancos de dados
• Projetos com prazo curto e impacto real

Muitas vezes entrando quando:

• O projeto já estava atrasado
• O código já estava frágil
• A arquitetura já tinha dado sinais de colapso

Todos esses projetos compartilham algo em comum:

• Código que alguém vai manter
• Arquitetura que explica decisões
• Produto que respeita o usuário
• Engenharia que respeita o tempo

Nem tudo vira vitrine.
Mas tudo vira base.

Projetos passam.
Arquitetura fica.

Além de código, produto e arquitetura, também sou autor do meu próprio livro.

Não é um livro de framework.
Não é tutorial passo a passo.
É um livro sobre fundamentos reais de software, engenharia e pensamento técnico.

O livro nasce da necessidade de registrar algo que quase nunca é ensinado:

• Como pensar sistemas antes de escrever código
• Como evitar decisões técnicas irreversíveis
• Como diferenciar complexidade necessária de complexidade inútil
• Como arquitetura, produto e negócio se cruzam no mundo real

Ele não tenta formar programadores rápidos.
Ele tenta formar engenheiros conscientes.

Alguns temas centrais:

• Fundamentos de arquitetura de software
• Tomada de decisão técnica sob pressão
• O custo invisível de más abstrações
• Backend além do CRUD
• Frontend além da interface
• Por que muitos sistemas quebram mesmo “funcionando”
• Código como responsabilidade de longo prazo

Tudo isso escrito a partir de:

• Projetos reais
• Sistemas que escalaram
• Sistemas que quebraram
• Erros que custaram caro

Porque documentação morre.
Porque posts se perdem.
Porque vídeos envelhecem rápido.

Um livro força clareza de pensamento.

Escrever foi a forma mais honesta de organizar anos de:

• Decisões difíceis
• Refactors dolorosos
• Sistemas herdados
• Produtos que deram certo
• Produtos que ensinaram mais do que sucesso

Software não é sobre ferramentas.
É sobre decisões.

O livro não promete atalhos.
Ele entrega fundação.