br2dev · sistemas sob medida

Seu sistema não devia depender do computador em que ele roda.

Tiramos o que já funciona do desktop, da planilha e do banco legado e colocamos na web — com os dados em um lugar só, acesso controlado e histórico de tudo que acontece.

o que a gente faz, em uma imagem

O mesmo dado. Outro lugar, outra forma.

Primeiro, o que existe hoje: linhas soltas numa tela só, sem estrutura que diga o que é o quê. Depois, o mesmo conteúdo com endereço — banco, serviços, painel.

terminal · dados brutos · um micro que ninguém pode desligar

web · dados governados · nuvem

postgresapirotinasrelatóriospainel
antes · terminal, dados brutos
postgresapirotinasrelatóriospainel

Uma tela só, tudo no mesmo lugar. Nada ali diz o que é cadastro, o que é lançamento e o que já foi conferido.

depois · web, dados governados
postgresapirotinasrelatóriospainel

postgres → api, rotinas e relatórios → painel. Cada pedaço com endereço, e o caminho de cada número visível de ponta a ponta.

quem somos

Dois desenvolvedores. Um CNPJ. Nenhum intermediário.

Uma software house de duas pessoas não é uma versão pequena de uma agência. É outra coisa — e a diferença aparece no primeiro problema difícil.

Você fala com quem escreveu a linha.

Não existe gerente de conta entre você e o código. O mesmo par que levantou o escopo é o que atende quando alguma coisa trava às sete da noite de uma sexta.

O time não muda no meio do projeto.

Ninguém é realocado, ninguém entra sem contexto na semana seis. O que foi combinado na primeira reunião continua na cabeça de quem está entregando.

Não pegamos dez projetos ao mesmo tempo.

É a limitação de sermos dois — e é exatamente por isso que o seu não vira o terceiro da fila. Quando dizemos que cabe, cabe.

Bruno confirmar: sobrenome do Bruno

confirmar: frente principal do Bruno — back-end, dados, infra?

Reginaldo confirmar: sobrenome do Reginaldo

confirmar: frente principal do Reginaldo

o que fazemos

Três frentes. Sempre o problema antes da solução.

01

levar para a nuvem o que já existe

  • banco relacional versionado
  • acesso pelo navegador
  • migração conferida
o problema

O sistema funciona. O problema é onde ele mora: um micro que ninguém pode desligar, uma licença de banco que saiu de suporte, um backup que é um pendrive na gaveta. Quem sabe mexer é uma pessoa só, e ela tira férias.

o que fazemos

Reescrevemos para web mantendo a regra de negócio que já está certa, migramos os dados com conferência contra o sistema antigo e mantemos os dois rodando lado a lado até os números baterem. A virada acontece quando bate — não quando o cronograma manda.

02

dados e governança

  • fonte única
  • trilha de auditoria
  • relatório rastreável
o problema

A informação existe, mas está em quatro lugares e nenhum bate com o outro. O relatório da diretoria é recortado à mão de três planilhas, leva dois dias, e ninguém consegue dizer de onde veio cada número.

o que fazemos

Um banco só como fonte de verdade, com histórico de alteração e trilha de quem mudou o quê. O relatório passa a sair do mesmo lugar que a operação, e o caminho de cada número é rastreável até o lançamento que o originou.

03

IA aplicada ao processo

  • classificação
  • extração de documento
  • rascunho com revisão
o problema

IA em apresentação é fácil. Dentro do processo é outra conversa: alguém precisa responder pelo que a máquina decidiu, e a maior parte das demonstrações não sobrevive ao primeiro caso fora do padrão.

o que fazemos

Usamos onde o erro é barato e a revisão é natural — classificar o que chega, extrair campo de documento, rascunhar a primeira resposta. O ponto de decisão continua sendo humano, e fica registrado o que o modelo sugeriu e o que a pessoa fez com aquilo.

cases

Dois projetos, dois problemas que a gente já viu de perto.

01

R1Decon

Chamados e acompanhamento de obras

  • React
  • Node.js
  • PostgreSQL
  • Flyway
confirmar: número de chamados por mês, número de usuários, ganho de tempo — qualquer métrica realconfirmar: autorização do cliente para citar o nome e usar a logo
contexto

Uma operação que atende chamados e toca obras ao mesmo tempo. Duas rotinas diferentes que dependem da mesma informação: quem pediu, quem está resolvendo e para quando ficou de ficar pronto.

o problema

O chamado nascia no WhatsApp e morria numa planilha. Entre um e outro, a informação atravessava três aplicativos e nenhum guardava o caminho. Ninguém conseguia dizer de quem era o chamado, desde quando estava parado, nem o que já tinha sido tentado — e quando alguém perguntava, a resposta era rolar conversa para cima.

o que foi feito

Um sistema único, em React e Node.js sobre PostgreSQL, com o schema versionado em Flyway desde o primeiro dia. Todo chamado tem responsável, prazo e histórico; toda obra tem etapas com quem executou e quando. O WhatsApp continua existindo — só deixou de ser o lugar onde a informação mora.

resultado

Chamado e obra passaram a viver no mesmo lugar, com histórico consultável em vez de reconstruído de memória. O que era conhecimento na cabeça de quem estava há mais tempo virou registro que qualquer pessoa da equipe abre.

02

SR Consultoria

Contabilidade rural

  • Java 21
  • Spring Boot
  • PostgreSQL
  • Flyway
  • 10 semanas
confirmar: volume de lançamentos migrados, número de produtores e propriedades atendidosconfirmar: autorização do cliente para citar o nome e usar a logo
contexto

Escritório de contabilidade rural rodando sobre um sistema legado em Firebird. Anos de lançamento acumulado, e um calendário fiscal que não abre exceção para migração de sistema.

o problema

O Firebird 2.5 saiu de suporte, e substituir a base de um sistema contábil não admite arredondamento. Migração de contabilidade não é 'quase certo': se um lançamento diverge em um centavo, o balanço fecha errado e a responsabilidade é de quem assina.

o que foi feito

Dez semanas de engajamento reescrevendo em Java 21 e Spring Boot sobre PostgreSQL, com Flyway versionando cada mudança de schema. O legado continuou rodando em paralelo o tempo todo, e cada lote migrado foi conferido contra ele — lançamento a lançamento, não por amostragem.

resultado

O critério de aceite não foi 'o sistema novo está pronto'. Foi reconciliação centavo a centavo entre o legado e o novo: nenhum lançamento podia divergir. A virada aconteceu quando a diferença chegou a zero.

divergência entre o legado e o novo, ao fim da migraçãoR$ 0,00Critério de aceite da virada: nenhum lançamento podia divergir em um centavo sequer.

como trabalhamos

Cinco etapas, nesta ordem, sempre.

Nenhuma delas existe para encher proposta. Cada uma produz uma coisa que você recebe e pode conferir.

  1. 01

    Diagnóstico

    1 a 2 semanas

    Olhamos o que existe: o banco, as planilhas, quem usa o quê e onde a informação se perde no caminho. Conversamos com quem opera, não só com quem decide.

    produzum documento do estado atual, com os riscos nomeados

  2. 02

    Escopo fechado

    antes de começar

    Preço e prazo fechados antes da primeira linha. O que ficou de fora está escrito com o mesmo cuidado do que ficou dentro — é a parte que evita discussão no mês três.

    produzproposta com escopo, prazo e preço fechados

  3. 03

    Entregas quinzenais

    durante o projeto

    A cada duas semanas tem software rodando em um ambiente que você acessa e testa. Não existe 'aparece no final': o que estiver errado aparece cedo, quando ainda é barato mudar.

    produzambiente de homologação atualizado a cada quinzena

  4. 04

    Migração assistida

    na virada

    O sistema novo roda ao lado do antigo e os dados são conferidos contra ele. A chave vira quando os números batem — nunca porque a data chegou.

    produzconferência documentada entre o legado e o novo

  5. 05

    Suporte

    depois de entregue

    Continua sendo nosso. Quem atende é quem escreveu, e correção de defeito não é orçamento novo.

    produzconfirmar: modelo, canal e prazo de resposta do suporte

segurança e governança de dados

Onde o dado fica, quem alcança e o que acontece se a gente sumir.

Seis compromissos concretos. Nenhum deles é difícil de verificar — e é para isso que eles estão escritos aqui.

O banco é seu.

Os dados ficam no banco do cliente, não em uma base nossa multi-inquilino. Se um dia a BR2DEV sair do mapa, o dado continua onde está, em PostgreSQL padrão, e qualquer desenvolvedor abre sem precisar de nós.

Acesso por perfil, não por confiança.

Cada pessoa vê o que o papel dela permite. Não existe usuário genérico compartilhado pela equipe, porque com login compartilhado a trilha de auditoria não vale nada.

Trilha de auditoria de verdade.

Quem viu, quem alterou, o que era antes, o que virou e quando. Registro imutável, separado da tabela que ele audita — não um campo `updated_by` que a própria alteração sobrescreve.

O schema tem histórico.

Toda mudança de estrutura entra como migration versionada, com Flyway nos projetos Java e Drizzle nos projetos Node. Dá para dizer exatamente qual era o formato do banco em qualquer data, e dá para voltar.

LGPD com base legal escrita.

Dado pessoal só entra se houver base legal para ele estar ali, com finalidade declarada e prazo de retenção definido. Eliminação a pedido do titular é função do sistema, não um chamado para o suporte executar SQL na mão.

Segredo não mora no código.

Credencial de banco, chave de API e token de integração ficam em variável de ambiente do servidor. Nada disso entra no repositório, e nada disso viaja para o navegador.

ainda em definição
confirmar: política de backup: frequência, retenção, onde fica a cópia e com que periodicidade o restore é testadoconfirmar: prazo de retenção por tipo de dado, acordado com cada clienteconfirmar: revisão de toda esta seção por assessoria jurídica antes do go-live

solicite um orçamento

Conte o problema. A gente responde se cabe.

Duas etapas, nenhuma pergunta de qualificação disfarçada. Se o que você precisa não for para nós, dizemos isso — e, quando dá, indicamos quem faz.

01

O que você precisa

Tipo de projeto, o que roda hoje, prazo e faixa de investimento.

02

Como te encontramos

Nome, empresa e a melhor forma de responder.

a confirmar antes do go-liveconfirmar: faixas de investimento que fazem sentido para vocês — as atuais são um ponto de partida
  1. 01o que você precisa
  2. 02como te encontramos

Quanto mais concreto o problema, mais preciso o orçamento.

Serve para saber se cabe. Não é proposta.