Reescrevemos o site para quem compra resultado, não detalhes de implementação.

A primeira versão do site estava certa demais para ser boa.

Ela explicava o fluxo, as restrições, o jeito como eu trabalho com IA e engenharia. Tudo verdadeiro. Mas, relendo com olho de cliente, percebi o erro: eu estava pedindo para o comprador entender a máquina antes de entender a promessa.

Quem chega com uma fila parada não quer decifrar um modelo operacional. Quer saber se pode mandar uma tarefa e confiar que ela vai sair.

Esse foi o incômodo que abriu a reescrita.

No primeiro texto, contei como transformei meu jeito de trabalhar com engenharia e IA em um serviço. Era a história mais fácil de contar porque era a história que eu estava vivendo por dentro: restrições, subagentes, ambientes isolados, verificação, revisão de código, toda a engrenagem por trás da entrega.

O site carregava um pouco desse vício. Ele respondia como isso é feito antes de responder por que eu deveria confiar minhas tarefas paradas a você.

Não cheguei nisso sozinho. Mandei a página para alguns pares, pedi para eles me dizerem o que ficava claro e onde a oferta embaçava, e fiz aquela parte menos glamourosa do trabalho: ler páginas de serviços parecidos, agências produtizadas, ferramentas para desenvolvedores e notas de fundadores vendendo execução em vez de licença de software.

O padrão apareceu rápido. As páginas mais fortes colocavam o comprador dentro de uma cena reconhecível. As mais fracas, incluindo a minha, faziam o leitor montar a promessa a partir da máquina.

O comprador não começa pela engrenagem

Esse é um erro sutil de muito fundador técnico. A gente descreve o funcionamento porque tem orgulho do funcionamento.

Só que quem compra está tentando responder perguntas mais práticas: o que vocês fazem, isso serve para alguém como eu, o que muda se eu contratar, o que preciso trazer e o que não devo esperar?

Nada na primeira versão era falso. A Ondemandly realmente se apoia em um processo disciplinado com IA. Tem critério sênior, escopo estreito, entrega assíncrona e uma tarefa ativa por vez.

Mas verdade não basta quando a pessoa precisa traduzir tudo sozinha para entender valor.

"Camada humana de execução" é uma descrição precisa. Você traz a sua lista. A gente entrega o software. é mais fácil de comprar. A primeira frase explica a categoria que existia na minha cabeça. A segunda dá ao leitor um trabalho que ele reconhece.

A sala do cliente vem antes da stack

Um fundador com a fila crescendo não costuma acordar pensando "preciso de execução de engenharia assistida por IA dentro de um conjunto controlado de Next.js e Postgres".

Ele está olhando para uma lista de coisas que continua sem sair do lugar.

Um bug pequeno que ninguém pegou. Uma área admin que ficou para depois. Um fluxo com IA que já foi discutido três vezes e nunca virou produto. Um formulário que deveria falar com Stripe, CRM, e-mail, banco de dados, analytics. Tudo claro o suficiente para virar ticket. Nada prioritário o suficiente para roubar o time principal.

O novo texto começa por aí. Pedido claro entra. Código pronto sai. Sem reunião. Uma tarefa por vez. Pausa quando a lista esfriar.

Essas frases não são menos técnicas porque o serviço ficou menos técnico. Elas são menos técnicas porque a primeira função da página é orientar. As tecnologias ainda importam. As restrições também. Mas elas funcionam melhor depois que a promessa já ficou clara.

O que mudou no site

A reescrita puxou o site para frases mais curtas, substantivos mais concretos e uma noção mais clara de antes e depois. Menos "este é nosso modelo operacional". Mais "este é o trabalho que você pode colocar na nossa mão".

A chamada principal virou uma promessa direta: Você traz a sua lista. A gente entrega o software. O apoio ainda fala de engenheiros experientes e velocidade com IA, mas não obriga a pessoa a deduzir o serviço a partir das ferramentas.

A seção "pra quem isso funciona" também ficou mais afiada. "Fundador olhando para uma lista enorme do que precisa construir" não é linguagem elegante de consultoria.

Ótimo.

É a sala onde o cliente certo está sentado. Se a frase faz a pessoa certa se reconhecer, ela trabalha mais do que uma abstração bonita.

O mesmo vale para escopo. Em vez de esconder os limites atrás de um posicionamento polido, a página diz o que a Ondemandly não pega: resgate de legado, descoberta aberta, plantão, design sob medida do zero, tecnologias fora da lista, trabalho cheio de reunião.

Tom amigável não significa promessa maior. Significa promessa certa, mais fácil de entender.

O feedback puxou o texto para o chão

O feedback mais útil não foi simplesmente "deixa mais curto", embora encurtar tenha ajudado. Foi perceber que algumas partes ainda soavam como se eu estivesse tentando convencer outro engenheiro de que o processo era legítimo.

Esse é outro trabalho.

A página precisava ajudar um fundador a decidir se podia me mandar uma tarefa.

Quando eu perguntava onde as pessoas travavam, as respostas voltavam para o chão: por onde eu começo, que tipo de tarefa encaixa, quanto preciso pensar antes de mandar algo, o que acontece se minha fila esfriar, como eu sei que isso não vai virar mais uma relação solta de freelancer?

A pesquisa de mercado apontou para o mesmo lugar. As páginas em que eu mais confiava deixavam o formato muito claro, quase sem espaço para adivinhação: entrada, saída, cadência, limites, preço e próximo passo.

Eu não precisava copiar a voz delas. Precisava respeitar a ordem em que uma pessoa entende risco.

Mais amigável não quer dizer menos sério

Eu não quero que a Ondemandly soe como uma consultoria grande. Também não quero que pareça um brinquedo.

O serviço vive em um meio-termo delicado: rápido por causa da IA, responsável porque um engenheiro humano assina a entrega, estreito porque esse recorte protege a qualidade.

A reescrita precisava manter essas três verdades visíveis.

Se o texto fala só "velocidade de IA", parece arriscado. Se fala só "engenheiros sênior", parece contratação comum. Se esconde o escopo, atrai o tipo errado de trabalho.

O tom melhor é mais amigável, mas também mais firme.

A regra editorial virou esta: deixar a página mais fácil de ler sem fazer a oferta parecer maior do que é.

O que eu copiaria dessa reescrita

Se você está transformando um jeito técnico de trabalhar em serviço produtizado, eu revisaria seu texto nessa ordem:

1. Comece pela sala do cliente. O que está na mesa, no calendário, no quadro ou na fila antes de ele chegar até você?
2. Diga o resultado antes de explicar o funcionamento. Deixe a pessoa entender a promessa antes de pedir atenção para o sistema.
3. Guarde a precisão técnica para as seções de prova. Use detalhe onde ele aumenta confiança, não onde ele atrasa compreensão.
4. Deixe os limites visíveis. Um bom "não" torna o "sim" mais crível.
5. Pergunte onde a pessoa travou. Não pergunte só se o texto soa bom. Pergunte o que ela acredita que pode comprar de você depois de ler.

Esse último ponto importou mais do que eu esperava. O feedback me ajudou a separar frases de que eu gostava das frases que tornavam a oferta mais fácil de comprar. Nem sempre elas são as mesmas.

O tom certo

O tom que eu quero é simples: calmo, concreto e direto o bastante para que uma pessoa não técnica consiga decidir se a Ondemandly cabe na rotina dela.

Não é anti-técnico. Não é simplificado demais.

Só está na ordem certa: resultado primeiro, funcionamento depois, restrições sempre visíveis.

Essa é a próxima camada do serviço depois do processo. Tornar o trabalho compreensível o suficiente para que o cliente certo diga sim pelo motivo certo.