Pular para o conteúdo
Bernardo Fernandez

Desenvolvedor de software & builder · Brasil

Bernardo
Fernandez

Algumas ideias pedem uma landing page. Outras pedem um produto de verdade.

Pra esse segundo tipo, sou eu: pego ideias ainda incertas e problemas técnicos cabeçudos e transformo em aplicações que sobrevivem à primeira versão.

Começar um projetoVer o que eu construí

Disponível para novos projetos.

Como eu trabalho

De “precisamos de um sistema” até no ar.

A maioria dos projetos começa com um pedido vago. O valor aparece cedo — quando alguém transforma essa névoa num escopo que dá pra construir. Esse desenho é onde eu rendo mais.

Entra vago, sai definido
A maioria dos projetos começa com um 'precisamos de um sistema pra isso'. Gosto de pegar algo que ainda não tem forma e transformar em escopo, decisão e entrega — primeiro o problema, depois o código.
O sistema por trás da interface
O que acontece depois do demo me interessa: modelo de dados, APIs, estados de erro, migrations e performance — porque o software precisa sobreviver à primeira versão.
Dono de ponta a ponta
Eu não paro no componente. Deploy, observabilidade e o que fazer quando o primeiro usuário real faz algo inesperado fazem parte do trabalho — não são ticket de outra pessoa.
Design como parte da engenharia
Tipografia, hierarquia e ritmo são como o sistema mostra a qualidade que tem por dentro — trato isso com o mesmo rigor do modelo de dados, não como enfeite por cima.

Trabalhos selecionados

Coisas que eu construí

Projetos meus, protótipos e experimentos — classificados sem maquiagem, porque trabalho de cliente inventado não prova nada. O que cada um mostra é como eu desmonto um problema técnico.

Todos os projetos

PROJETO PESSOAL · 2024

Fieldnote — Um MVP construído em seis semanas

Um exercício de produto que impose a mim mesmo: pegar uma ideia de um parágrafo — guias escritas pela comunidade, organizadas por bairro — e levar do conceito a um MVP funcionando em seis semanas.

Next.js · TypeScript · PostgreSQL · Mapbox

Ler o case study

EXPERIMENTO · 2025

Typeset — Um playground interativo de tipografia

Uma ferramenta no navegador pra explorar tipografia: eixos de fonte variável ao vivo, previews de escala fluida em todas as larguras de uma vez e pareamento lado a lado — construída pra afiar meu próprio olhar.

Next.js · TypeScript · Canvas API · Variable fonts

Ler o case study

Tem algo parecido na sua cabeça?

Me conta

Onde eu ajudo

Soa familiar?

01

“Tenho uma ideia, mas não sei por onde começar.”

Desenvolvimento de MVP e produto: a gente corta a ideia até a menor versão que vale construir, e eu levo do escopo ao modelo de dados até um produto que dá pra usar de verdade.

Desenvolvimento de MVP · Lançamentos de produto · Protótipos que sobrevivem ao contato com usuários

02

“A gente precisa de uma aplicação de verdade, não de mais uma landing page.”

Aplicações web com lógica de domínio real — contas, modelos de dados, permissões, fluxos — construídas pra serem mantidas depois do lançamento, não só demonstradas uma vez.

Produtos SaaS · Portais de clientes · Sistemas de reserva · Marketplaces

03

“Nosso processo vive numa planilha e num grupo de WhatsApp.”

Eu transformo coordenação manual em ferramentas internas que dão ao time um lugar confiável de onde operar — dashboards, automações e integrações que se encaixam em como o trabalho acontece de verdade.

Dashboards de operação · Automação de fluxos · Painéis de administração · Integrações

04

“O produto funciona, mas o código virou o problema.”

Arquitetura e refatoração: modelos de dados, APIs, type safety e performance — trabalho estrutural que torna os próximos seis recursos baratos em vez de assustadores.

Desenho de APIs · Modelagem de dados · Trabalho de performance · Auditoria técnica

05

“Preciso de alguém técnico que realmente assuma isso.”

Desenvolvimento de produto ponta a ponta: uma pessoa que transita entre decisões de produto, design e implementação — sem perdas de tradução entre o que é decidido e o que é construído.

Construção com fundadores · Product engineering · Do zero ao lançamento

Se identificou? Isso já basta pra começar uma conversa.

Me conta o que você quer construir

Além da interface

Construir é uma coisa. Engenharia é o que faz durar.

Qualquer um monta uma interface. O que decide se o software vive depois do demo é o que fica por trás: o modelo de dados que torna o próximo recurso barato, a API que falha alto em vez de calada, o deploy que sobrevive a um dia ruim.

É esse alcance que eu levo pro projeto — do primeiro schema à interface que as pessoas realmente usam.

Interface
ReactNext.jsTypeScript
Backend
Node.jsNestJSJavaGo
Dados
PostgreSQLPrismaTypeORMSupabase
Infraestrutura
DockerKubernetesGrafana

Explorando agora

  • Sistemas distribuídos — os padrões por trás de serviços confiáveis
  • Go para serviços e tooling de backend
  • Kubernetes e o lado operacional de rodar software
  • Observabilidade — métricas e traces que explicam o comportamento em produção

Como eu trabalho

Da primeira conversa até o produto no ar

  1. 01

    Entender

    A gente descobre o que você está realmente tentando resolver — o primeiro pedido raramente nomeia o problema real.

  2. 02

    Definir

    Escopo por escrito: o que será construído, em que ordem e o que significa 'pronto' — pra não ter ambiguidade onde se esconder depois.

  3. 03

    Construir

    Prefiro te mostrar uma versão funcional grosseira na primeira semana do que um plano. Software funcionando cedo, decisões baseadas no que existe.

  4. 04

    Refinar

    Performance, casos de borda e estados de falha — os detalhes que decidem se o software sobrevive ao uso real.

  5. 05

    Entregar

    No ar, documentado e passado adiante — pra você não ficar dependente de mim pra manter vivo.

Tem algo faltando no seu produto atual?

Vamos conversar

Trabalhar juntos

A gente combina se…

  • Você tem uma ideia e precisa de alguém técnico pra transformar em produto.
  • Você já tem um produto, e a próxima versão precisa de engenharia mais profunda.
  • Seu time tem um problema técnico que volta sempre e precisa ser resolvido direito uma vez.
  • Sua operação depende de planilhas, grupos de chat e repasses manuais.
  • Você quer uma pessoa só que transite entre decisões de produto e implementação.

Provavelmente não combina se

  • Você só precisa de alguém pra executar tickets prontos, sem contexto.
  • Você quer a implementação mais barata, não a certa.
  • Você precisa de um time grande ou de estrutura de agência agora.

Não sabe de que lado você está? É exatamente pra isso que existe o briefing.

Soa com a sua situação?

Vamos conversar sobre isso

Escritos

Como eu penso

Todos os textos

Começar um projeto

Não precisa estar tudo resolvido.
Uma ideia rascunhada já basta pra começar.

O briefing existe porque ninguém chega com tudo pronto — nem quem no fim acaba entregando. Me conta o que você está girando na cabeça.

Tenho uma ideia