Rotina de dev solo: como organizo meu dia sem burnout

O problema de ser tudo ao mesmo tempo

Dev independente não é só dev. É vendedor, atendimento, financeiro, marketing e gestor de projeto. Tudo na mesma pessoa, no mesmo dia, na mesma mesa.

Quando comecei a trabalhar sozinho, fazia tudo ao mesmo tempo. Codava de manhã, respondia lead no meio do código, parava pra postar no Instagram, voltava pro código sem lembrar onde tinha parado, e no final do dia sentia que trabalhou 10 horas sem entregar nada concreto.

O problema não era falta de esforço. Era falta de estrutura. Sem rotina definida, cada tarefa compete com todas as outras por atenção. E context switching é o maior assassino de produtividade que existe pra quem programa.

Depois de meses ajustando, cheguei numa rotina que funciona. Não é rígida. Não é perfeita. Mas me permite entregar projetos com qualidade, prospectar clientes, e ainda ter vida fora do trabalho.

Blocos de tempo: a base de tudo

Divido o dia em blocos de 2-3 horas com função definida. Não misturo blocos. Quando estou codando, não respondo mensagem de lead. Quando estou prospectando, não abro o editor.

Minha divisão típica:

Manhã (8h-12h): código. As 4 horas mais produtivas do dia vão pra desenvolvimento. Sem reunião, sem WhatsApp, sem email. O celular fica em modo foco. Se o cliente precisa de algo urgente, vai ver minha resposta ao meio-dia.

Esse bloco é sagrado. É onde o trabalho que paga as contas acontece. Cada interrupção nesse período custa 15-20 minutos pra retomar o contexto mental do código. Numa manhã com 3 interrupções, perco quase 1 hora só voltando pro raciocínio. Com zero interrupções, entrego em 4 horas o que antes levava 6.

Almoço (12h-13h30): descanso real. Não como no computador. Não “descanso” vendo reel de tech no Instagram. Saio da mesa, almoço, e faço algo que não envolve tela. Parece improdutivo, mas a qualidade do código da tarde depende diretamente desse intervalo.

Tarde (13h30-16h): tarefas leves e comunicação. Respondo clientes, reviso copy, ajusto CSS, faço deploy, atualizo documentação. Tarefas que precisam de atenção mas não de concentração profunda. É o bloco onde reuniões acontecem (quando inevitáveis).

Final da tarde (16h-17h30): prospecção e conteúdo. Mando mensagens pra leads no Instagram e WhatsApp, escrevo posts pro blog, atualizo o portfólio. Esse bloco é o investimento no futuro do negócio. Se pulo ele toda semana, em 2 meses não tenho pipeline de clientes.

O erro de trabalhar até “acabar”

Dev solo tem uma tendência perigosa: trabalhar até o projeto acabar. “Só mais essa feature.” “Deixa eu só ajustar esse bug.” “Vou terminar essa página e paro.” E quando vê, são 22h e você tá no computador desde as 8h com 30 minutos de almoço.

Isso funciona por 2-3 semanas. Depois a qualidade cai, os bugs aumentam, a criatividade some, e você começa a odiar o trabalho que escolheu fazer. Burnout não é drama. É consequência matemática de gastar mais energia do que recupera.

Minha regra: às 17h30, o computador fecha. Não importa se a feature está 90% pronta. Amanhã ela vai estar mais fácil de terminar porque eu vou estar descansado. Código escrito cansado gera bug que leva mais tempo pra corrigir do que o tempo que você “economizou” ficando até tarde.

Exceções existem. Deadline apertado, bug em produção, entrega no dia seguinte. Mas exceção que vira rotina não é exceção. É problema de planejamento.

Prospecção não é opcional

A armadilha mais comum do dev solo: tá com projeto, para de prospectar. O projeto acaba, não tem pipeline, fica sem renda por 2-3 semanas até fechar o próximo. Repete o ciclo.

Prospecção precisa acontecer todo dia, mesmo quando você tá ocupado com projeto. 30 minutos por dia são suficientes. 5 mensagens no Instagram, 3 follow-ups no WhatsApp, 1 post no blog por semana.

No meu modelo de prospecção pra clínicas de odontologia estética, o ciclo funciona assim: identifico dentistas que postam casos de estética no Instagram, mando DM personalizada, acompanho por WhatsApp, e uso minha LP de prospecção como material de apoio.

Esse trabalho de 30 minutos diários garante que quando o projeto atual termina, já tenho 2-3 conversas em andamento. Sem vale entre projetos, sem desespero pra fechar qualquer coisa. Detalhei o modelo completo de operação solo no post sobre dev independente sem virar agência.

Ferramentas que organizam sem complicar

Não uso Notion com 15 databases, nem Trello com 8 colunas, nem sistema de produtividade complexo. Quanto mais simples a ferramenta, mais chance de eu usar de verdade.

O que uso no dia a dia pra acelerar o desenvolvimento com IA está detalhado no post sobre entregar projetos mais rápido com IA. Mas mesmo com IA, estrutura importa mais que velocidade.

O que uso:

Arquivo .md por projeto. Cada projeto tem um markdown com spec, checklist de entrega, notas de reunião e backlog. Vive no repositório do projeto. Quando abro o código, o contexto tá ali do lado.

Calendário do Google. Blocos de tempo marcados como evento. O bloco de código da manhã aparece como “DEV [nome do projeto]”. O bloco de prospecção aparece como “PROSPECÇÃO”. Parece bobo, mas ver os blocos no calendário me impede de agendar reunião às 9h da manhã.

Lista de leads em .md. Cada lead é um arquivo markdown com nome, contato, status da conversa, e histórico de mensagens. Simples, buscável, sem ferramenta extra. Meus leads ficam organizados em ~/Desktop/leads/ com a skill de vendas do Claude Code gerenciando o formato.

Timer. Não uso Pomodoro rígido (25 min é muito curto pra código), mas uso timer de 90 minutos pra garantir pausas. Quando o timer toca, levanto, tomo água, volto. Sem timer, fico 3 horas sem levantar e a coluna cobra depois.

Reuniões: menos é melhor

Reunião é o maior roubo de tempo do dev solo. Uma reunião de 1 hora no meio da manhã não custa 1 hora. Custa 1 hora + 30 minutos de preparação + 20 minutos pra retomar o contexto do código. São 2 horas por uma reunião de 60 minutos.

Minhas regras pra reunião:

Só à tarde. Nunca no bloco de código da manhã. Se o cliente só pode de manhã, negocio essa exceção com consciência de que vou perder a manhã produtiva.

Máximo 30 minutos. A maioria das reuniões pode ser resolvida em 30 minutos se tiver pauta definida. “Vamos alinhar o projeto” não é pauta. “Aprovar layout da home e definir copy da hero” é pauta.

Se pode ser mensagem, não vira reunião. “Aprovado o layout?” é uma mensagem, não uma call de 15 minutos. Reservo reunião pra decisões que precisam de conversa ao vivo: kickoff de projeto, apresentação de proposta, revisão de entrega.

No AutoPars, a comunicação com o cliente era principalmente assíncrona. Updates por mensagem, dúvidas por áudio, reuniões quinzenais de 30 minutos pra alinhar prioridades. O projeto andou mais rápido com menos reuniões, não mais.

Saúde física não é extra

Parece fora de contexto num post sobre rotina de dev, mas saúde física impacta diretamente a capacidade de trabalho. Dev que não dorme bem, não se exercita e come mal produz menos, comete mais erros e queima mais rápido.

O que incorporei na rotina e fez diferença:

• Dormir 7-8 horas (não 5-6 achando que é produtivo)
• Exercício 3-4 vezes por semana (não precisa ser academia, caminhada conta)
• Pausas a cada 90 minutos (levantar, água, movimento)
• Almoço longe do computador

Não é conselho de coach. É observação prática. Nas semanas que durmo mal, meu output de código cai visivelmente. Bugs que não cometeria descansado aparecem. Decisões de arquitetura que pareciam boas de madrugada se revelam ruins na manhã seguinte.

O dia que não funciona

Nem todo dia segue a rotina. Tem dia que o cliente manda urgência às 9h e a manhã de código vai pro espaço. Tem dia que a energia não aparece e o bloco de prospecção vira scrollar o celular. Tem dia que tudo dá errado.

A rotina não é pra eliminar dias ruins. É pra garantir que a maioria dos dias seja produtiva. Se 4 de 5 dias da semana seguem a estrutura, o quinto pode ser bagunça sem comprometer o resultado.

O que não pode acontecer é 5 de 5 dias serem bagunça. Se isso vira padrão, o problema não é o dia. É a rotina que precisa de ajuste.

• Seu bloco de código da manhã é protegido de interrupções?
• Você prospecta pelo menos 30 minutos por dia, todo dia?
• Suas reuniões têm pauta definida e duração máxima?
• Você para de trabalhar num horário fixo?
• Tem pausas a cada 90 minutos?
• Dorme 7-8 horas por noite?
• Seu sistema de organização é simples o suficiente pra você usar todo dia?

O dev solo que dura organiza as horas que trabalha, não adiciona mais. Estrutura simples com consistência ganha de qualquer sistema elaborado que você abandona em 2 semanas.