Eu já sinto isso no meu dia a dia usando o Gemini Flash. Para programar ou criar as automações, eu não preciso de uma IA muito pensante. Eu só preciso de uma ferramenta que entenda o contexto que eu defini nas skills e resolva o problema técnico agora, sem demora.

É como aquela comparação que ouvi: usar um modelo gigante para tarefas simples é como usar um carro de luxo só para buscar pão na esquina. É um desperdício de recurso e, principalmente, de tempo.

O que eu percebi na prática é que a velocidade é o que realmente traz produtividade. Quando a ferramenta responde quase na hora, ela vira uma extensão do meu raciocínio. Eu não perco o foco esperando a resposta carregar.

Para quem cuida de um negócio, isso é puro ganho de eficiência. Na minha consultoria, eu trato o modelo maior como um arquiteto, que planeja e valida as decisões mais complexas. Mas o trabalho braçal de execução fica com esses modelos menores. Eles são rápidos e custam muito pouco, o que democratiza a automação para qualquer empresa.

Claro, esses modelos menores exigem que a gente saiba dar ordens claras. Eles são como estagiários muito inteligentes, se a instrução for vaga, eles podem errar rápido. Mas, sabendo orientar, eles são imbatíveis em escala.

Estou documentando essa jornada justamente porque acredito que o futuro não é um robô gigante, mas sim vários pequenos agentes trabalhando juntos. No fim, o foco é o resultado e a eficiência do negócio, sem complicações desnecessárias.

That’s all folks!

Tenho pensado muito sobre o meu estilo de criar negócios e, olhando para trás, percebi que sempre busquei caminhos alternativos. Hoje, aos 45 anos, as coisas ficaram mais claras. O motivo de todas as minhas decisões sempre teve um viés muito forte: a liberdade.

Nunca quis ficar preso o dia todo numa empresa, então montei a minha. Mas também não queria enfrentar aquele trânsito caótico todos os dias, então construí meu escritório no terreno de casa. Depois, percebi que não queria mais me envolver com vendas diretas, então construí um negócio em parceria com quem vende, as agências.

Hoje, minha cabeça está em outro lugar: automação.

Estou focado em desenvolver ativos digitais que trabalham sozinhos. Meu objetivo agora é desenvolver negócios automatizados, como SaaS e produtos digitais. Isso tem tudo a ver comigo. Mas o que isso tem a ver com o tal do “One Person Business“?

Simples. Eu não tenho aquela visão de CEO de startup com pensamento de crescer eternamente, captar milhões e ter 500 funcionários. Eu quero algo enxuto, baixo custo, poucas pessoas e com limites de crescimento claros.

Meu pensamento tem mais a ver com melhorar a estrutura do que crescer desordenadamente. Acho que todos temos um limite, mas poucos querem aceitar. Querem crescer ao infinito. Em algum momento, a conta não fecha e dá errado. Eu prefiro crescer até um limite e investir em estrutura e processos. Isso me dá paz. É sobre arrumar a casa, melhorar a qualidade e diminuir o Churn Rate.

Quando descobri que outras pessoas também pensam assim, e que até existe um termo para isso, achei demais!

One Person Business é um estilo de vida focado em Melhor, não Maior. O negócio é construído para servir ao estilo de vida do fundador, e não o contrário.

Hoje a Inteligência Artificial tem ajudado muito a viabilizar essa visão. Se você tem habilidades para criar agentes de IA, pode montar uma empresa muito eficiente e de alto valor sem contratar uma equipe gigante. Por exemplo, estou desenvolvendo um SaaS totalmente automatizado. A infraestrutura está nas mãos de empresas especializadas, o meu designer, copywriter, programador, marketing e consultor são todos agentes de IA. Eu me sinto um maestro rsrsrs. Claro, sou desenvolvedor de software a muito tempo, então isso me ajuda a não depender de decisões feitas por IA. Ela não está no controle, apenas me auxilia.

É impressionante o que dá para fazer sozinho. Por isso, hoje, é muito viável pensar em One Person Business.

A Filosofia Central

Melhor, não Maior. Essa ideia foi popularizada por autores como Paul Jarvis, autor de Company of One e criadores modernos como Justin Welsh e Dan Koe. A lógica é inverter o jogo tradicional:

• Anti-Escala Tradicional: Em vez de perguntar “Como posso crescer esta empresa para 100 funcionários?”, eu pergunto “Como posso atingir minhas metas financeiras sem contratar ninguém?”.

• Lifestyle Design: O negócio serve a minha vida. Ponto.

• Alta Margem de Lucro: Sem escritório caro, sem folha de pagamento gigante e sem burocracia, a margem de lucro tende a ser altíssima, muitas vezes acima de 80-90%.

Os Três Pilares

Para conseguir faturar alto sem trabalhar 24 horas por dia, a gente geralmente se apoia em três coisas:

1. Marca Pessoal: Construir uma audiência leal. A confiança na pessoa gera as vendas.

2. No-Code, Automação e IA: Uso intensivo de ferramentas e IA para fazer o trabalho repetitivo que antes exigiria um funcionário júnior.

3. Produtização: Em vez de vender horas, criamos cursos, newsletters pagas, SaaS ou serviços produtizados com escopo fixo.

Claro, nem tudo são flores. Tem vantagens incríveis, como a agilidade de tomar uma decisão e implementar no mesmo dia, sem reuniões chatas de diretoria. O risco é baixo e a resiliência é alta. Em crises, quem tem custo zero sobrevive melhor.

Mas tem os desafios. A solidão bate, afinal, não ter colegas para trocar ideias no café pode ser isolante. E tem o gargalo humano, se você ficar doente e não tiver automação rodando, o negócio para. Além disso, você veste todos os chapéus, é o CEO, o suporte e o financeiro.

Uma recomendação que vale ouro

Eu comecei a dar mais atenção a esse estilo de vida quando assisti a um vídeo do . Achei a visão dele muito pé no chão e quero compartilhar com vocês.

Aqui estão os principais insights que peguei do vídeo:

• O Mito do “Sozinho”: Ele desmistifica o termo. Embora seja possível começar só, o modelo muitas vezes funciona melhor como uma dupla, onde um foca na criatividade/produto e o outro na operação.

• A Escada da Monetização: Não tente escalar imediatamente. Comece vendendo serviços para fazer caixa, e só depois crie produtos escaláveis para desvincular seu tempo do dinheiro.

• O Conceito de “Teto Financeiro”: Isso aqui é genial. Em vez de buscar crescimento infinito, defina um número exato para cobrir seu estilo de vida e sobrar caixa. Ao atingir esse teto, o objetivo muda: não é ganhar mais, é ganhar a mesma coisa trabalhando menos horas.

• Propaganda Escalável: Foque em conteúdos perenes como YouTube, que continuam gerando visualizações anos depois, ao contrário de Stories que somem em 24h.

Vale muito a pena assistir ao vídeo completo para entender a profundidade disso:

É uma ótima reflexão para quem, assim como eu, valoriza mais a liberdade do que o tamanho do escritório.

That’s all folks!

Sou programador PHP. Em todos os meus projetos, o framework Laravel é a minha zona de conforto. Se eu fosse seguir o caminho natural, meu SaaS nasceria assim, backend com Laravel Framework e o frontend com componentes Blade. Funcionaria super bem.

Mas eu adotei uma filosofia de negócios diferente: eu sou um One-Person Business.

E veja bem, isso não é por falta de opção, é uma escolha estratégica. Decidi construir uma empresa enxuta, de alta margem e sem a complexidade de gerir grandes equipes ou infraestruturas pesadas. O objetivo é manter a operação leve e focar 100% da energia no produto e clientes.

Porém, essa filosofia traz um desafio claro: o tempo.

Como tenho um trabalho principal, dedico apenas 2 horas por dia neste novo projeto.

Para que esse modelo de negócio de certo, eu não posso me dar ao luxo de gastar tempo configurando servidores e programando tudo do zero. Eu preciso de mais agilidade. O backend eu resolvi rápido, o Supabase. Nada de reinventar a roda, vou programar em Javascript nas edge functions e pronto. O Backend está resolvido, mas e o frontend? Qual a melhor forma de desenvolver as telas do meu SaaS tendo apenas 120 minutos por dia?

A resposta óbvia era: Plataforma LowCode.

Mas aqui entra o meu lado chato de desenvolvedor. Na minha opinião, plataforma LowCode cai muito bem quando o backend é separado, mas eu tinha medo de ficar preso em ferramentas limitadas. Eu nunca tinha usado isso para sistemas, só para sites com Elementor Pro.

Então, decidi testar. Fiz minha lição de casa, vi vídeos e cheguei nas três líderes: Bubble, Flutterflow e WeWeb.

Mas eu não ia testar com “Olá Mundo”. Eu precisava de um caso real. Peguei os desenhos do meu SaaS no Figma: tela de login, cadastro, lista de clientes e edição. E estabeleci uma lista de critérios inegociáveis. Para eu usar a ferramenta, ela precisava permitir:

1. Componentização para os templates: Capacidade de injetar conteúdo dinâmico em estruturas fixas. Odeio copiar e colar. Preciso criar um elemento uma vez e reutilizar em várias telas.

2. Tratamento de erros nos fluxos de ações: O famoso Try Catch.

3. Design System: Padronização de tipografia, paleta de cores, espaçamento etc. Precisa ser fácil de manter.

4. Javascript personalizado: Liberdade para criar funções.

5. Exportação de código: Não quero ficar refém da plataforma.

6. Git e APIs: Controle de versão e conexão fácil.

Vamos para a batalha.

Bubble

Primeiro fui no Bubble, o queridinho da comunidade lowCode. Sendo bem honesto? Descartei rapidinho. Ele foi reprovado mais ou menos em 80% dos meus requisitos. Achei muito estranho a forma como as coisas funcionam lá. Muito copia e cola. Não consegui utilizar os componentes de forma correta, tudo parecia meio enjambrado. Dava para fazer? Dava. Mas parecia gambiarra. Depois entendi que o Bubble é feito para outro público. Tchau, Bubble.

Flutterflow

Aí fui testar o Flutterflow. Criei todas as telas de novo. Criei cada componente, entendi o design system, conectei com as APIs. Logo de cara achei interessante. É uma plataforma feita para desenvolvedores. Tem árvore de widgets, uma boa ferramenta de fluxo de lógica, sistema de componentização robusta.

Confesso que apanhei um pouco. Minha base pessoal é Web, e a base do Flutterflow é Mobile. A lógica muda. Também tive dificuldade em ter que ficar esperando para compilar cada alteração visual. Mas, com o tempo, fui me adaptando. A minha dificuldade não era na plataforma em si do Flutterflow, tudo lá é bem organizado, meu problema era na lógica de construir as coisas mesmo. Principalmente quando eu construía elementos responsivos. Também notei que a reatividade dos elementos criados em Dart é diferente dos elementos reativos do Javascript. Isso dificultou algumas coisas. Fiquei empacado em algumas situações simples por conta de alguns problemas da própria tecnologia Flutter / Dart. Percebi que a tecnologia web é melhor nisso, talvez por conta do HTML estar mais integrado com o Javascript através do DOM, sei lá.

Fiquei 6 meses nessa. Criei a primeira versão do meu SaaS, com o primeiro módulo rodando. Cadastro, login, gestão de usuários, tudo funcionando. Ficou bom! Eu estava decidido a seguir com ele, mesmo com algumas ressalvas.

WeWeb

Durante esse processo, eu tinha dado uma olhada no WeWeb. Tinha achado a interface incrível, muito ágil. Alterou, apareceu. Sem compilação. Mas eu tinha esbarrado num problema técnico, eu achava que ele não tinha Slots na estrutura dos componente. Coisa que o Flutterflow fazia com maestria.

Sabe quando você cria um modal e quer que o miolo dele seja dinâmico? Eu não conseguia fazer isso. E isso era o requisito da minha lista. Frustrado, achei que a ferramenta era limitada e abandonei. A componentização é uma das partes mais importantes pra mim.

Mas calma! Era apenas ignorância da minha parte.

Recentemente, pensando em como financiar o crescimento do SaaS, decidi que pegaria alguns trabalhos extras de desenvolvimento. Mas não dava para pegar freelas em PHP, seria muito sofrido e demorado. Pensei, vou aprender LowCode e entregar projetos nesse perfil.

Resolvi dar uma segunda chance ao WeWeb e estudar a fundo. E adivinha? O tal slot existia. Mas lá o nome é DropZone. Que na minha cabeça, dava a impressão de ser uma área de arrastar arquivos, sabe? Quando entendi que DropZone era o Slot que eu tanto procurava, minha cabeça explodiu.

Eu refiz tudo

Decidi refazer tudo o que eu tinha feito no Flutterflow, agora no WeWeb. Entrei de cabeça. Dessa vez, consegui aplicar todas as boas práticas. Refatorei tudo, criei componentes de página com Header, Footer e Sidebar fixos, deixando apenas o slot para o conteúdo. Ficou perfeito.

O resultado me chocou:

• Tempo no Flutterflow: 6 meses.

• Tempo no WeWeb: 40 dias.

Sim, trabalhando as mesmas 2 horas por dia. Eu refiz meio ano de trabalho em pouco mais de um mês. Talvez porque o contexto Web seja mais natural para mim, ou porque a ferramenta roda liso no navegador sem compilar, mas a velocidade foi absurda.

Por que isso valida o One-Person Business?

Eu olhei para os números e a conclusão foi óbvia. Para minha filosofia de One-Person Business, velocidade e eficiência não são luxo, são sobrevivência.

O WeWeb atendeu todos os meus requisitos técnicos, inclusive exportar o código, caso a plataforma seja descontinuada amanhã. É estável, tem bom preço e me dá a liberdade de criar funções Javascript quando preciso.

Foi uma longa jornada de testes, lamúrias e cabeçadas, mas ainda bem que voltei atrás para testar o WeWeb. Hoje tenho uma stack definida e segura para criar minha renda passiva em 2026. E se você não é um programador, mas tem uma boa noção de ferramentas como Excel, Notion, Canva etc, e gostaria de usar lowCode para criar um aplicativo, o WeWeb também cai bem. Vai precisar de alguns meses de aprendizado, mas é muito, mas muito mesmo mais simples que programar. As vezes se tornar um programador é impossível mesmo, mas aprender uma plataforma lowCode, com certeza é possível e viável. É uma boa porta de entrada para a tecnologia. O WeWeb também se encaixa neste perfil.

Estou documentando cada passo do desenvolvimento desse SaaS aqui. Se você gosta desse assunto, construção de negócios, LowCode e vida real de empreendedor, considere assinar minha newsletter.

Dominar essa stack foi o que me permitiu ganhar essa velocidade. Também ofereço uma consultoria completa para quem quer desenvolver seu próprio SaaS ou sistema interno. Posso ajudar desde o planejamento até a entrega, tudo de forma estruturada, usando essa mesma eficiência que aplico no meu negócio.

Conhecer Consultoria

Hoje eu preciso falar sobre a parte “chata” de criar um SaaS. Aquela que ninguém vê, não é bonita, não tem animação, mas que é, sem dúvida nenhuma, o cérebro da coisa toda: o Back-end.

É ali que os dados dos seus usuários moram. É ali que as regras do jogo são definidas. E, na minha opinião, a tecnologia que você escolhe para rodar isso é a decisão mais importante do projeto.

Ultimamente, tenho visto um movimento que me preocupa um pouco. Tem muita gente desenvolvendo SaaS na empolgação, sem bagagem técnica, confiando 100% do backend para as IAs. Sinceramente? Acho um erro gravíssimo.

Veja bem, eu não sou contra IA. O “Vibe Coding” veio para ficar, é divertido e acelera as coisas. Mas entregar o cérebro da sua empresa para uma IA escrever sozinha? Em algum momento vai dar ruim.

Pensa comigo: você coloca o SaaS no ar, as pessoas se cadastram, confiam os dados delas ali. De repente, numa atualização, a IA decide deletar uma coluna vital do banco ou muda uma regra de negócio silenciosa porque “achou melhor”. O sistema quebra. Você não sabe onde quebrou porque não foi você que escreveu. E pior: você pode ter problemas jurídicos sérios com vazamento ou perda de dados.

Vai por mim: o backend precisa de mão humana profissional.

Outra coisa que me dá calafrios é ver gente conectando ferramentas de LowCode diretamente no banco de dados. “Ah, mas é só configurar o RLS (Row Level Security) que tá seguro”.

Olha, na teoria é lindo. Na prática? Um sistema real é muito mais complexo do que “o usuário X só edita o dado Y”.

Imagina que você conecta o seu frontend direto na tabela do Supabase. Se você deletar um usuário direto pela tabela, quem valida se esse usuário podia ser deletado? E se ele era um administrador e o sistema não previu essa trava? E se você manda um dado “sujo” de um formulário e ele grava direto, criando inconsistência?

Quando tudo está amarrado direto no banco, você perde o controle.

Então, qual é o cenário perfeito para mim?

Eu gosto de separar as coisas. Uso o LowCode para o que ele é brilhante: criar telas, o Front-end. Mas o Back-end? Esse precisa ser isolado, blindado e feito por quem entende.

Isso te dá uma liberdade absurda. Se amanhã a ferramenta de LowCode que você usou para fazer as telas falir ou ficar cara demais, paciência. O cérebro do seu negócio, os dados e as regras, está seguro em outro lugar. Você só precisa refazer a “casca”.

E é aqui que entra a minha escolha: o Supabase.

Eu sou desenvolvedor há mais de 15 anos. Já subi muito servidor, configurei Docker, brinquei de DevOps, PHP com Laravel, Node... tudo isso é robusto e funciona. Mas, hoje em dia? Eu quero descomplicar.

Estou numa fase da vida em que quero terceirizar a dor de cabeça. Quero manter minha empresa enxuta. Não quero acordar de madrugada porque o servidor caiu ou porque preciso atualizar uma biblioteca urgente.

Eu quero que meus clientes confiem na minha empresa sabendo que a segurança e a infraestrutura estão nas mãos de gigantes que só fazem isso da vida.

Quando conheci o Supabase, foi amor à primeira vista (e confesso que me empolguei e soltei um “nunca mais vou configurar um servidor na vida” rs). Ele é um BaaS (Backend as a Service). Tudo pronto. Sento na cadeira e codifico o que importa: o negócio.

A parte mais interessante para mim são as Edge Functions.

Ao invés de conectar o frontend no banco, eu crio uma API usando essas funções. É uma arquitetura Serverless. O deploy é ridículo de rápido.

Minha rotina hoje é mais ou menos assim:

1. Começo com um plano detalhado (funcionalidades, campos, regras).

2. Rabisco um protótipo das telas para “ver” o software.

3. Vou pro Supabase e crio a estrutura de dados (tabelas, relacionamentos).

4. Crio as Edge Functions.

Cada funcionalidade tem seu endpoint. Dentro da função, eu coloco toda a regra de negócio, validação, permissão e tratamento de dados. Testo tudo no Postman.

Quando entrego isso para o Frontend, está tudo mastigado, seguro e, principalmente, desacoplado.

Se o front der pau, o back segura. Se o usuário tentar burlar o formulário, a função barra. É assim que se constrói um SaaS que aguenta o tranco e pode escalar sem medo.

Enfim, essa é a minha opinião de quem já bateu muita cabeça configurando servidor na unha. O Supabase me deu a paz que eu precisava para focar no produto.

Se você tem uma ideia incrível mas travou na hora de garantir que o “motor” do seu SaaS seja seguro e profissional, talvez eu possa te ajudar.

Eu ofereço uma consultoria onde posso desenvolver o projeto inteiro ou assumir apenas essa parte crítica do backend, deixando tudo pronto (e documentado) para o seu desenvolvedor frontend apenas conectar os pontos.

Conhecer Consultoria

E se você curte esse tipo de conversa transparente sobre os bastidores de um SaaS, considere assinar a newsletter para acompanhar essa jornada.

Sou desenvolvedor há mais de 15 anos. A minha reação natural, ao ter uma ideia de negócio, sempre foi abrir a IDE e começar a codar. É o que eu faço, é a minha zona de conforto. Mas, para este novo projeto, decidi pensar diferente.

Eu conheço bem os bastidores de uma empresa de software tradicional. Sei o custo real e os problemas que acompanham esse nicho. Quando decidimos criar uma startup onde o produto é o software, acabamos nos tornando reféns da tecnologia se não tomarmos cuidado.

Com o tempo, o cenário comum é precisar gerenciar uma equipe para o front-end, outra para o back-end, alguém responsável pela infraestrutura (DevOps), e por aí vai. Cada tecnologia traz consigo dezenas de bibliotecas, frameworks e a necessidade constante de gerenciamento de versões. Tudo precisa ser compatível com tudo. O resultado? A empresa incha. Você passa a gerenciar pessoas e dependências, e não o produto. OK! Sei que em muitos casos é assim mesmo, mas eu queria algo mais leve.

A busca pela Startup Enxuta

Eu não quero gerenciar essa complexidade toda. Meu objetivo é criar uma operação enxuta, focada em gerar renda passiva e entregar valor rápido.

Se eu fosse pelo caminho tradicional (High Code), teria controle total sobre cada pixel e cada linha de lógica, mas o custo de tempo e gerenciamento seria alto. Foi aí que surgiu a questão: Será que plataformas LowCode conseguem cuidar disso tudo para mim?

Seria confiável? Seria escalável?

Decidi estudar as plataformas disponíveis e testar. Pra isso, defini uma lista rígida de pré-requisitos técnicos.

Para eu aceitar usar ferramentas LowCode, elas precisava me oferecer:

• Back-end isolado: Precisava ser independente do front-end.

• Criar minhas funções: Eu precisava ter liberdade para programar minhas funções no back-end.

• Acesso ao código: Possibilidade de fazer download do código fonte.

• Componentização: Capacidade de criar componentes reutilizáveis para manter o padrão.

• Gerenciamento de Design System: Controle centralizado de paletas de cores, tipografias e temas.

• Templates: Implementação do conceito de templates para acelerar novas páginas.

• Javascript personalizado: Possibilidade de injetar funções JS específicas.

• Integração via API: Conectividade total com serviços externos.

• Controle de Versão: Integração nativa com GIT.

A régua estava alta. Eu precisava que essas ferramentas fizessem tudo isso muito bem.

A Experiência Prática

Eu já tinha uma bagagem com LowCode. Há alguns anos, tive um estúdio que desenvolvia exclusivamente para agências parceiras. Usávamos muito WordPress com Elementor Pro para entregar sites institucionais rapidamente. Agilizava muito a entrega.

Porém, existe um abismo entre desenvolver um site e desenvolver um sistema (SaaS). Sites são estáticos ou pouco dinâmicos; sistemas exigem lógica complexa, segurança e tratamento de dados robusto.

Comecei a testar as plataformas tentando implementar meus requisitos, um a um. Desenhei algumas telas do meu SaaS e comecei a implementação prática. Não fiquei apenas na teoria; tentei aplicar padrões de projetos e simular o crescimento da aplicação para ver se a plataforma aguentava o tranco.

A minha experiência prévia ajudou muito. Eu sabia exatamente o que precisava ser feito, a dúvida era apenas se a ferramenta permitia.

A Conclusão

Após meses de testes e aprendizado, cheguei a uma conclusão: Sim, é possível desenvolver um SaaS robusto com LowCode.

Deixando claro: não testei ferramentas NoCode (sem código), pois elas limitam demais a lógica. O LowCode (pouco código) foi o equilíbrio perfeito.

Como tenho noção exata de quanto tempo leva para codificar uma feature no método tradicional, fiquei impressionado com a velocidade. Coisas que levariam uma semana para estruturar, no LowCode resolvi em um dia.

Além da velocidade de desenvolvimento, eliminei uma carga enorme:

• Não preciso configurar ambiente de desenvolvimento (é logar e fazer).

• Não perco tempo configurando pipelines de deploy complexos.

• Não preciso gerenciar conflitos de versões de bibliotecas.

Decisão tomada: vou desenvolver meu SaaS e montar minha operação aqui em Portugal 100% baseada em LowCode. Descobri um ecossistema maduro e pronto para uso profissional.

Nos próximos artigos, vou começar a contar exatamente quais plataformas LowCode escolhi.

Acompanhe a jornada

Estou documentando todo o processo de criação deste SaaS, do zero ao lançamento (e além). Se você gosta de tecnologia e negócios, assine a newsletter.

Precisa de ajuda no seu projeto?

Se você precisa desenvolver um SaaS, um protótipo ou um sistema interno para sua empresa e quer usar a agilidade do LowCode com a segurança de uma arquitetura profissional, conheça minha consultoria. Posso te ajudar do planejamento ao desenvolvimento completo.

Conhecer Consultoria

Uma das etapas mais difíceis para quem desenvolve software não é escrever o código, mas decidir qual problema resolver.

Eu já havia decidido que iria desenvolver um novo SaaS para gerar renda passiva. A questão técnica, para mim, é tranquila. Mas em qual nicho entrar?

Pensei em várias possibilidades, mas a lógica me inclinou para a área da estética e saúde, focada especificamente no público autônomo. Estou falando daquele profissional que trabalha sozinho ou tem uma equipe muito enxuta.

A escolha não foi baseada em “paixão”, mas por dois motivos.

O buraco no mercado

Primeiro motivo. Ao analisar as ferramentas disponíveis para esteticistas, fisioterapeutas e outros profissionais autônomos, notei um padrão claro:

• De um lado: Sistemas focados puramente em agendamento. São simples, mas não gerenciam o negócio ou o tratamento do paciente.

• Do outro lado: ERPs complexos feitos para grandes clínicas.

Existe um vácuo no meio disso. O profissional autônomo não precisa de um ERP hospitalar, mas precisa de algo mais robusto que uma agenda do Google.

Minha esposa é da área

O segundo motivo é estratégico: minha esposa é da área. Isso facilita absurdamente o desenvolvimento, pois tenho o “cliente final” dentro de casa para validar cada funcionalidade.

Há alguns anos, ela atendia alguns clientes e precisava organizar fichas de anamnese e histórico de tratamentos. Quando fomos procurar um sistema, tudo era caro ou complexo demais.

O que eu fiz? Criei um sistema sob medida para ela. Ela usou por muito tempo e o feedback foi claro: dava um ar muito mais profissional ao atendimento dela do que as fichas de papel. Desde aquela época, conversávamos sobre essa brecha no mercado.

A validação da dor

Um dia, conversei com uma cliente que atua na mesma área da minha esposa. O relato dela confirmou a minha tese sobre a complexidade dos sistemas atuais.

Ela me contou que, para iniciar um simples tratamento no sistema que ela usava, a burocracia era imensa.

Um exemplo: Ela tentava inserir um tratamento e o sistema bloqueava porque o cliente não tinha o CPF cadastrado. Ela precisava fechar a tela do tratamento, ir na busca de clientes, editar o cadastro, inserir o CPF, salvar, voltar para a tela de tratamento e começar tudo de novo. E as vezes o cadastro não tinha todas as informações e por conta disso não era permitido dar sequencia. O usuário só queria anotar uma coisa rápido.

Para um hospital, essa validação rígida faz sentido. Para um pequeno negócio, onde o profissional quer apenas registrar o que foi feito no dia, isso é um entrave. Resultado: ela anotava no papel e só passava para o sistema quando tinha tempo (ou seja, quase nunca).

A maioria dos profissionais com quem conversei acaba usando softwares de agendamento não porque são completos, mas porque são fáceis. A minha hipótese é lógica: se eu criar um produto de gestão que seja tão fácil de usar quanto uma agenda, teremos sucesso.

Mais ainda tinha uma etapa importante

Para esse nicho funcionar, eu precisava de mais uma coisa além de código e de um problema real. Eu precisava de um rosto.

Eu precisava convencer minha esposa a ser a “cara” do projeto. Ela precisa atuar como a influenciadora do software, falando a língua dos profissionais da área, enquanto eu cuido dos bastidores e da tecnologia.

Essa negociação foi rápida rsrsrs. Como já falávamos sobre isso há tempos, ela topou. Validamos as funcionalidades que quero oferecer com outra profissional da área, recebemos feedbacks valiosos e formatamos a ideia.

O Nicho está Definido

Eu tinha um checklist para aprovar esse projeto:

1. Um problema real para resolver (complexidade dos sistemas atuais).

2. Uma ideia clara de solução (foco em usabilidade para pequenos negócios).

3. Uma pessoa especialista para vender (minha esposa).

O resto — o desenvolvimento — eu resolvo.

Portanto, o SaaS será focado em profissionais autônomos e pequenos negócios (Esteticistas, Massoterapeutas, Fisioterapeutas, Psicólogos, Dermatologistas, Dentistas, etc.).

O objetivo é a simplicidade. Estou desenvolvendo tudo com muito cuidado para não cair no erro dos concorrentes.

Vou documentar todo o processo de construção aqui. Se você quer acompanhar os bastidores, assine a newsletter.

O próximo passo lógico é definir qual tecnologia usar. E, como vocês sabem, eu prezo pela eficiência e velocidade. É sobre isso que falaremos no próximo artigo.

Se você tem interesse em desenvolver um SaaS ou precisa de um sistema interno para sua empresa, mas não sabe por onde começar, eu posso ajudar.

Eu ofereço serviços de consultoria que vão desde o planejamento, prototipagem até o desenvolvimento completo (Front-end e Back-end) e a colocação do projeto no ar, sempre focando em soluções ágeis.

Conhecer Consultoria

Estou escrevendo este artigo para compartilhar uma reflexão sobre como o mercado de tecnologia mudou, mas principalmente sobre o momento exato em que minha mentalidade sobre desenvolvimento mudou para sempre.

Há cerca de 15 anos, eu tinha a minha empresa, a Studio Preview. Nós éramos focados em desenvolvimento web personalizado. A entrega era excelente, mas o modelo de negócio era cruel: quanto mais personalizado o projeto, mais caro e trabalhoso ele era. Eu passava os dias tentando otimizar processos, mas na prática, estávamos sempre desenvolvendo tudo do zero para garantir a qualidade.

Eu já tinha construído meu Studio no mesmo terreno da minha casa, buscando aquela qualidade de vida que sempre valorizei. E foi ali, numa conversa com um cliente que virou amigo, que ouvi pela primeira vez sobre vender software por assinatura. Na época, a maioria dos sistemas rodava localmente na máquina do usuário. A ideia de um sistema online com mensalidade me atingiu em cheio. Eu já lia sobre investimentos na época e liguei os pontos: desenvolver um SaaS era a melhor forma de criar renda passiva.

Decidi que precisava criar um software que resolvesse um problema real e que as pessoas me pagassem uma mensalidade por ele.

Eu e meu sócio tínhamos facilidade para criar. Desenvolvíamos o design, o código, os vídeos e o marketing. Então, criamos o Sua Presença na Internet. Era uma plataforma para colocar sites no ar rapidamente, focada em pequenos negócios. O começo foi difícil. O foco no desenvolvimento do produto fez nosso faturamento de serviços cair drasticamente. Para manter o sonho vivo, tivemos até que abrir uma produtora de vídeo paralela, a Studio Cine. Passamos a filmar casamentos e eventos nos finais de semana para financiar o desenvolvimento do software durante a semana.

Foi uma época de muito esforço braçal. A tecnologia era um gargalo. Não existiam plataformas de pagamento simples como hoje. Tive que implementar a baixa de boletos bancários manualmente no código, lidar com gerentes de banco, configurações de servidor complexas... era um caos operacional.

Mas houve um momento específico, no meio desse furacão, que definiu o resto da minha vida.

Foi quando, após muita dor de cabeça para automatizar as cobranças, o sistema finalmente rodou o ciclo completo sozinho.

Eu me lembro claramente da sensação. O cliente pagou o boleto, o meu sistema identificou o pagamento, a assinatura foi renovada e o serviço continuou no ar. Eu não precisei fazer nada. Não precisei enviar e-mail, não precisei apertar um botão, não precisei “entregar” o projeto novamente.

Quando eu vi aquilo tudo funcionando e rodando, eu entendi: “Cara! Isso é fantástico!”. Tudo automatizado.

Naquele instante, a ficha caiu. Eu percebi que vender para 1 ou para 1.000 clientes não multiplicaria meu trabalho por mil. A máquina estava trabalhando por mim. Ver o projeto rodando de forma automática mudou permanentemente a minha forma de pensar sobre negócios. Ali eu entendi, na prática, o que era gerar renda passiva com software.

O projeto acabou sendo descontinuado tempos depois. Fomos engolidos pelo crescimento do WordPress e, ironicamente, pelo sucesso da produtora de vídeo que consumiu nosso tempo. Depois disso, ainda tentei um SaaS para a área escolar em parceria com uma grande escola de música da minha cidade. Isso me levou ao burnout. Descontinuamos o projeto após perceber que precisaria investir muito com novos programadores. Organizei minha vida e voltei para o mercado de serviços desenvolvendo exclusivamente para agências por um bom tempo. Foi um bom período, eles vendiam, e nós desenvolvíamos. O trabalho era 100% remoto. Neste período entregamos mais de 500 projetos utilizando LowCode, foi um sucesso até chegar a pandemia. Passamos pela pandemia com uma boa demanda, suficiente para pagar as contas básicas. Mas decidimos entregar todos os projetos e fechar. Eu ainda tinha na cabeça trabalhar com SaaS.

Aquele “gostinho” da máquina girando sozinha nunca saiu da minha cabeça.

Por que estou contando isso agora? Porque levei 15 anos para me organizar e voltar a esse modelo. Só que hoje, o cenário é outro.

Fechei o Studio novamente e estou 100% focado em SaaS. Estou desenvolvendo uma ferramenta para o setor imobiliário, que já paga a equipe, e outra para a área de Saúde e Bem-estar. A diferença é que a barreira técnica que quase me faliu lá atrás não existe mais.

Hoje utilizo LowCode para criar as telas do meu software, uso plataforma de Backend que funciona como serviço e Inteligência Artificial. Não me preocupo com estrutura de nada, apenas com o meu Software. Com exceção do SaaS na área imobiliária que estou trabalhando, que exige um pouco mais de complexidade, esse é desenvolvido com código tradicional. Mas mesmo assim, os frameworks ajudam muito mais do que naquela época.

Componentes que eu levava uma semana para desenvolver “na unha”, hoje faço em um dia. Não preciso reinventar a roda ou perder noites configurando servidores. Se preciso de uma função complexa em Javascript, peço para a IA, reviso e implemento.

Acredito que este é o melhor momento para desenvolver soluções de software. A tecnologia deixou de ser o gargalo que me impede de ver a “mágica” acontecer. Agora posso focar em fazer a máquina girar.

Vou documentar essa nova jornada, meus acertos e erros aqui no Substack. Se você também busca construir ferramentas que geram renda passiva, assine a newsletter para acompanhar.

E se você gostaria de desenvolver um SaaS ou uma ferramenta para sua empresa, aconselho a começar com planejamento. Eu ofereço uma Consultoria que ajuda você a ter um plano detalhado antes de digitar uma linha de código, evitando as armadilhas que eu enfrentei no passado.

Clique no link abaixo para entender como funciona minha Consultoria.

Espero que tenha gostado da história. Me siga para acompanhar a jornada.

Conhecer Consultoria

Decidi começar este Substack para documentar, de forma transparente, o desenvolvimento dos meus projetos de SaaS e micro-SaaS. O objetivo central é desenvolver ferramentas que geram renda passiva, e vou mostrar o processo aqui, focando bastante em soluções LowCode para provar que é um caminho acessível.

Agora, estou no exato ponto de partida de um novo projeto. E, neste exato momento, o maior desafio não é técnico. Não é sobre qual back-end ou front-end usar.

O maior desafio é validar a premissa.

Antes de escrever a primeira linha de código, eu paro tudo e faço uma espécie de ritual: eu releio um livro chamado “A Arte de Pensar Claramente”, de Rolf Dobelli.

Pode parecer um desvio, mas na minha experiência, o erro técnico se conserta. O erro de premissa – construir a coisa errada por motivos errados – é o que quebra um projeto.

Temos muitas ideias no dia a dia. O difícil é filtrar quais delas são genuinamente boas e quais são apenas armadilhas do nosso próprio pensamento, nossos vieses. E eu digo isso porque já cometi esse erro caro.

A Armadilha do “Sucesso” que me Prendeu

Alguns anos atrás, eu tinha uma produtora de vídeos, a Studio Cine. Eu e meu sócio estávamos estabelecidos, o negócio ia bem. Mas havia um problema fundamental: o modelo de negócio nos prendia geograficamente. E isso batia de frente com nosso objetivo principal de ter liberdade, tanto financeira quanto geográfica.

Era óbvio que algo precisava mudar, mas sair da situação era complexo.

O que nos segurava lá não era a falta de oportunidade, eram os vieses cognitivos.

O primeiro era o Viés de Confirmação. Na época, fomos pioneiros no uso de câmeras HDSLR, que davam uma qualidade cinematográfica aos vídeos. Vimos outras empresas copiarem nosso método. Isso nos dava orgulho, “confirmava” que estávamos na tendência certa.

O segundo era o Viés dos Elogios. Recebíamos feedback positivo constante. Cada elogio reforçava a ideia de que estávamos no caminho certo.

O problema? Essa confirmação externa e os elogios mascaravam a realidade: a cada novo projeto “de sucesso”, nossa agenda lotava e o objetivo real (liberdade geográfica) ficava mais distante. Estávamos otimizando a coisa errada.

Foi preciso um esforço consciente de distanciamento para analisar os fatos. Após um ano de planejamento, fechamos a Studio Cine e abrimos a Studio Preview, focada em desenvolvimento de sites para agências. Um modelo 100% remoto.

A lição foi clara: a clareza de pensamento para identificar o objetivo real, acima do ruído dos vieses, foi o que permitiu a transição.

Identificando Vieses nas Decisões do Dia a Dia

Hoje, ao avaliar uma nova ideia de SaaS, eu levo essa lição muito a sério. Vieses são sutis, vêm da nossa cultura, família, do que consumimos.

Por exemplo, no nosso mercado de “indie hackers” e SaaS, é comum ver o “viés de tendência”. Vemos alguém ter sucesso com um “AI Wrapper” e, de repente, todos querem fazer um. Isso é seguir o fluxo, não necessariamente uma decisão clara.

Eu tento manter uma vigilância constante sobre minhas próprias decisões. “Estou realmente resolvendo um problema validado, ou estou apenas animado com uma tecnologia nova?”

Busco ativamente conversar com pessoas de fora da minha bolha. Reviso decisões passadas e seus resultados: foram baseadas em fatos ou em vieses?

Meu “Checklist” Prático para Clareza Mental

Ao longo dos anos, especialmente após a transição da Studio Cine, desenvolvi um processo prático para filtrar ideias e tomar decisões. Não é nada místico, é apenas um checklist lógico.

• 1. Definir o Objetivo Real: O que eu quero alcançar com este projeto? (Ex: Renda passiva de X, com no máximo Y horas de suporte por semana). Se a ideia ferir o objetivo, é descartada.

• 2. Avaliar Prós e Contras (Baseado em Fatos): Escrevo uma lista. “Acho que os clientes vão gostar” não é um fato. “Falei com 5 clínicas e 4 disseram que pagariam por isso” é um fato. Foco muito nos contras.

• 3. Reconhecer o Conhecido e o Desconhecido: O que eu sei sobre esse mercado? E, mais importante, o que eu não sei? Ser honesto sobre a própria ignorância é crucial.

• 4. Decidir com Base na Realidade Atual: Evito “achismos”. A decisão deve se basear em informações concretas de hoje, não em suposições.

• 5. Assumir Consequências: Eu aceito a responsabilidade pelo resultado. Se falhar, o erro foi meu. Isso me força a ser mais cuidadoso na análise, em vez de culpar “o mercado” ou “a sorte”.

• 6. Ser Flexível para Mudanças: A vida é feita de ciclos. Se os fatos mostrarem que a premissa estava errada, eu preciso estar pronto para mudar o curso (pivotar) sem ego.

O Ponto de Partida

Clareza mental não é sobre ser perfeito, é sobre ser intencional. É um trabalho diário de autoconhecimento e disciplina.

Eu sei que essa fase de “escolher a ideia” e validá-la é onde muitos travam. É um ponto cego comum. Se você está preso aí, sem saber se sua ideia de SaaS é viável ou se é só um viés falando mais alto, talvez uma análise externa ajude.

É parte do que eu ofereço como serviço: consultoria para análise de viabilidade e prototipagem. Às vezes, você só precisa de uma visão experiente para validar (ou invalidar) a premissa antes de investir meses em desenvolvimento. Seja o projeto completo, só o front-end ou o back-end. Se fizer sentido, basta entrar em contato.

Este artigo é o meu ponto de partida para essa jornada pública. Antes de mergulhar nas ferramentas LowCode, nos bancos de dados e nas APIs, eu precisava garantir que o motivo pelo qual estou construindo está claro.

Se você também sente que precisa de um “filtro” melhor para suas decisões, recomendo fortemente a leitura de “A Arte de Pensar Claramente” de Rolf Dobelli.

É um livro direto, com 99 capítulos curtos, cada um sobre um erro de lógica que cometemos. É o tipo de livro que mantenho na mesa para consultas rápidas.

(O link para a Amazon é de afiliado. Se você comprar por ele, eu recebo uma pequena comissão, sem custo adicional para você. É uma forma de apoiar este trabalho.)

Nos próximos artigos, vamos começar a detalhar a primeira ideia de micro-SaaS e o processo de validação na prática.

Até lá.

Comprar na Amazon

Eu estava há algumas semanas no meio de uma daquelas tarefas clássicas de quem vai começar um negócio digital: estruturar o blog.

Meu objetivo é claro: documentar (no formato “Build in Public”) todo o desenvolvimento de um negócio que estou montando aqui em Portugal, na área de tecnologia. Quero compartilhar o processo de criação dos meus SaaS, desde a ideia até as vendas, de forma transparente.

O caminho óbvio? WordPress.

Eu já estava com o plano todo traçado. Teria o blog principal, contando a história do desenvolvimento (o “build in public”). Mas, para “fazer a coisa direito” (segundo o manual do marketing digital), eu também teria que criar um monte de artigos satélites.

Sabe como é: artigos feitos para SEO, com títulos e termos pensando especificamente no robô do Google. Artigos para fazer links internos, para conseguir backlinks, para ranquear para termos específicos e, claro, para tentar vender alguns serviços de desenvolvimento no meio disso tudo.

Como desenvolvedor com 20 anos de experiência, montar essa estrutura não é exatamente um desafio técnico para mim. O problema é o peso que ela traz.

Eu estava olhando para a pilha de coisas que precisaria gerenciar: Hospedagem dedicada, a instalação do WordPress, Elementor para as páginas, plugins de Cache, otimização de Core Web Vitals, plugins de SEO... enfim, um monte de tranqueira que vem junto com essa estrutura.

O resultado? Eu estava me sentindo arrastado. Com preguiça.

Aquele projeto de “Build in Public”, que eu genuinamente queria tanto fazer, estava se tornando um fardo antes mesmo de começar. O foco estava saindo do negócio (o SaaS) e da história (o blog) e indo para a manutenção da ferramenta (o WordPress).

Foi aí que eu parei para olhar o Substack.

Eu já conhecia a plataforma como leitor, mas nunca tinha explorado o lado do criador. E, francamente, me surpreendi.

A ficha caiu de verdade quando percebi: eu não preciso mais escrever para o Google.

Eu posso (e devo) escrever pensando em pessoas.

Isso mudou tudo para mim. De repente, a empolgação voltou. Fui me aprofundando e vi as possibilidades.

Eu não precisava mais me preocupar com a estrutura web. Não precisava me preocupar com plugins, com atualizações de segurança, com performance ou cache. Estava tudo lá: a newsletter integrada (essencial!), um algoritmo de entrega que funciona, área de membros e até a possibilidade de transformar o perfil em um site com meu domínio próprio.

Então, veio o pensamento óbvio: Por que diabos eu vou sofrer com todo o peso de uma estrutura WordPress?

Não faz o menor sentido para o meu objetivo atual.

Na mesma hora, decidi jogar fora todo aquele planejamento de artigos feitos para SEO e backlinks. Resolvi começar do zero, aqui.

Claro, essa decisão trouxe uma segunda pergunta. O Substack resolvia o blog, a newsletter (adeus, Mailchimp!) e a complexidade da área de membros que eu teria com plugins no WordPress. Mas... e as minhas landing pages?

Fazer páginas de captura ou de vendas no Elementor é muito simples. Eu precisava de um substituto que mantivesse a mesma filosofia: LowCode, rápido e direto ao ponto.

• Pensei no WeWeb. É uma ferramenta fantástica, mas completa demais para uma simples landing page.

• Pensei no Framer. Talvez, mas conhecendo meu perfil, achei que ia ficar muito tempo “lambendo o design” e perderia o foco no negócio.

Após mais algumas pesquisas, achei o Carrd.

Perfeito. Simples, bonito e muito barato.

Pronto. A estrutura estava resolvida: Substack para o conteúdo, a comunidade e a newsletter; Carrd para as landing pages de venda dos meus serviços.

Estou genuinamente feliz em começar a escrever sem o peso do SEO, da hospedagem, do WordPress e dos plugins. Meu único foco será contar a história do desenvolvimento do meu negócio.

Essa “limpeza” me fez pensar em quantos projetos (meus e de clientes) ficam travados pelo excesso de ferramentas e pela complexidade desnecessária. Muitas vezes, a gente gasta mais energia na estrutura do que no negócio em si.

O foco principal do meu conteúdo aqui será o uso de soluções LowCode, justamente para mostrar que é possível construir ferramentas incríveis que geram renda passiva sem precisar de um time de 50 desenvolvedores ou de uma infraestrutura de banco.

Claro, o LowCode não resolve tudo, e a experiência em desenvolvimento “tradicional” ajuda a saber onde estão os atalhos e as armadilhas. Se você está com um projeto de software emperrado, seja na fase da ideia, precisando de um protótipo rápido para validar, ou se precisa de ajuda no desenvolvimento (seja front-end, back-end ou o projeto completo), fale comigo. Às vezes, uma consultoria direta ao ponto é o que destrava o processo.

Mas, por ora, é isso.

Meus próximos posts aqui no Substack serão o início oficial do meu “Build in Public”, documentando a jornada do meu novo SaaS aqui em Portugal.

Seja bem-vindo.

Assine agora