Glossário sem jargão.

Prática de fazer o produto funcionar para todas as pessoas, inclusive com deficiência, seguindo as diretrizes WCAG do W3C.

Contraste de cor, navegação por teclado, textos alternativos em imagens e campos com rótulo são a base. Isso amplia seu público, reduz risco jurídico e melhora o SEO, porque buscadores e IAs leem a página como um leitor de tela lê. Fica mais barato prever desde o design do que corrigir depois.

Programa que usa um modelo de linguagem para executar tarefas sozinho, em etapas, usando ferramentas e dados do seu sistema.

Um chatbot responde perguntas. Um agente age: lê dados, roda verificações, abre tarefas, escreve relatórios. Para um founder, o ganho está em rotinas repetitivas que hoje dependem de alguém lembrar de fazer. O ponto de atenção é limitar o que ele pode acessar e conferir o que ele entrega.

Conjunto de regras que permite dois sistemas trocarem dados entre si, sem uma pessoa no meio.

É por API que seu sistema recebe pagamentos, emite nota fiscal, manda mensagem no WhatsApp ou conversa com um modelo de IA. Uma API bem documentada reduz o custo de cada integração nova. Antes de escolher um fornecedor, confira se a API dele cobre o que você precisa e quanto custa por chamada.

A parte do sistema que roda no servidor: regras de negócio, banco de dados, autenticação e integrações.

O usuário não vê o back-end, mas é nele que moram os dados e as regras que fazem o produto funcionar. Problemas de segurança, lentidão e dados inconsistentes quase sempre nascem aqui. Num resgate de projeto, é a primeira parte que auditamos.

Percentual de clientes que cancelam ou param de usar o produto num período, normalmente medido por mês.

Num SaaS, churn alto apaga o efeito de qualquer campanha de aquisição. As causas mais comuns são onboarding confuso, falhas recorrentes e falta de evolução no produto. Medir o churn por motivo de cancelamento mostra onde investir primeiro.

Ferramenta da Anthropic em que o modelo Claude lê, escreve e testa código direto no projeto, a partir de instruções em texto.

Acelera muito o build quando quem usa sabe revisar o que a IA escreve. Sem revisão, vira vibe coding e acumula dívida técnica. No Studio usamos Claude Code junto com Figma no design e no build, sempre com revisão humana.

Código antigo que continua em uso, mas é difícil de entender, testar ou mudar, muitas vezes sem documentação nem o autor original.

Todo produto que dá certo acaba com algum código legado. O problema começa quando cada mudança pequena leva semanas ou quebra outra parte. A saída raramente é reescrever tudo de uma vez: é mapear, estabilizar e trocar por partes.

Quando o visitante faz a ação que você quer: preencher um formulário, assinar, comprar. A taxa de conversão é essa ação dividida pelas visitas.

Dobrar a conversão costuma custar menos que dobrar o tráfego. Clareza da oferta, velocidade da página e um formulário curto pesam mais que cor de botão. Defina uma conversão principal por página e meça só ela no começo.

Três métricas do Google que medem a experiência de carregar e usar uma página: LCP (carregamento), INP (resposta) e CLS (estabilidade).

Entram como sinal de ranqueamento no Google e afetam direto a conversão: página lenta perde visitante antes de mostrar a oferta. Você confere as suas no PageSpeed Insights ou no Search Console. Nos sites que publicamos, essas métricas são parte da entrega.

Código padronizado, em geral JSON-LD, que diz a buscadores e IAs o que é cada coisa na página: empresa, artigo, produto, pergunta.

Ajuda o Google a mostrar resultados ricos, como perguntas frequentes e avaliações, e ajuda IAs a citar sua empresa com os dados certos. O visitante não vê, mas a máquina lê. É uma das primeiras coisas que configuramos num projeto de SEO e GEO.

O ato de enviar uma versão nova do código para o servidor onde o sistema roda, deixando a mudança disponível.

Em times maduros, deploy é rotina de minutos e acontece várias vezes por semana. Se cada deploy é um evento tenso, manual e demorado, isso é sinal de processo frágil. Peça para ver como o time publica antes de contratar.

Conjunto de componentes, regras visuais e tokens (cores, tipos, espaços) que todo o produto usa, no design e no código.

Com design system, uma tela nova sai mais rápido e fica igual às outras. Sem ele, cada pessoa inventa um botão diferente e o produto fica com cara de remendo. Não precisa nascer grande: começa com os 10 a 20 componentes que você mais usa.

Etapa inicial em que entendemos o problema, o produto e o negócio antes de definir escopo, preço e prazo.

Sem diagnóstico, qualquer orçamento é chute. É nele que separamos o que precisa ir para o ar agora do que pode esperar. No Studio, o preço fechado e o prazo só saem depois do diagnóstico, e o prazo fica escrito no contrato.

Fase de pesquisa e definição em que o time descobre o que construir: problema, usuários, hipóteses e prioridades.

Discovery evita gastar meses construindo algo que ninguém usa. Pode incluir entrevistas, análise de concorrentes, protótipos e testes rápidos. O risco é virar uma fase sem fim: ela precisa terminar com decisões e um escopo.

Custo futuro gerado por atalhos no código: cada solução rápida de hoje cobra juros em forma de lentidão e bugs amanhã.

Um pouco de dívida é normal e até saudável para ir ao ar rápido. O problema é quando ninguém registra nem paga. Sinais claros: tudo demora mais do que antes, o mesmo bug volta e o time tem medo de mexer em certas partes.

A lista do que será entregue num projeto: funcionalidades, telas, integrações e o que fica de fora.

Escopo vago é a causa mais comum de atraso e briga entre cliente e fornecedor. Um bom escopo diz o que entra e, com a mesma clareza, o que não entra. Se não está escrito, conte que não está incluído.

Modelo de contrato em que escopo, preço e prazo são definidos antes de começar e não mudam sem acordo.

Dá previsibilidade de custo para quem contrata. Só funciona bem quando o escopo foi bem definido antes, por isso depende de um diagnóstico sério. Mudanças no meio do caminho entram como aditivo, com preço e prazo próprios.

Trabalho recorrente para melhorar o produto depois que ele vai ao ar: correções, novas funcionalidades e ajustes a partir do uso real.

Produto no ar é o começo, não o fim. Os dados de uso mostram o que precisa mudar, e um time fixo responde mais rápido do que um projeto novo a cada pedido. É um dos serviços do Studio para quem já tem produto rodando.

A parte do sistema que roda no navegador ou no app: as telas, os botões e tudo com que o usuário interage.

Um bom front-end é rápido, fiel ao design e funciona em qualquer tamanho de tela. Ele depende do back-end para buscar e salvar dados. Quando o design é bonito no Figma e estranho no navegador, o problema costuma estar no handoff ou no front-end.

Generative Engine Optimization: otimizar seu conteúdo para ser encontrado e citado por IAs generativas como ChatGPT, Claude, Perplexity e Gemini.

Cada vez mais gente pergunta para uma IA em vez de buscar no Google. Para ser citado, seu site precisa de respostas claras, dados estruturados, autoria visível e conteúdo que a IA consiga ler. GEO não substitui o SEO: os dois andam juntos, e o Studio trabalha os dois no mesmo serviço.

A passagem do design para o desenvolvimento: arquivos, especificações e comportamentos que o time de código precisa para construir.

Handoff ruim gera retrabalho e telas diferentes do que foi aprovado. Ajuda ter design system, protótipo navegável e estados documentados (erro, vazio, carregando). Quando design e código ficam no mesmo time, essa passagem quase some.

Conexão entre o seu sistema e outro serviço, como pagamento, ERP, CRM ou WhatsApp, para trocarem dados automaticamente.

Integrações costumam ser a parte mais imprevisível de um projeto, porque dependem de documentação e limites de terceiros. Liste todas logo no diagnóstico. Cada uma precisa de tratamento de erro: o que acontece quando o outro sistema sai do ar?

Página com um único objetivo, como captar um contato ou vender um produto, sem distrações que tirem o visitante desse caminho.

Funciona melhor quando fala com um público e tem uma oferta só. Velocidade, clareza no primeiro bloco e prova (números, cases) pesam mais que efeitos visuais. É a peça mais usada para testar uma ideia antes de construir o produto.

Lei Geral de Proteção de Dados (Lei nº 13.709/2018), que regula como empresas coletam, usam e guardam dados pessoais no Brasil.

Vale para qualquer sistema que guarde nome, e-mail ou CPF de alguém. Na prática: coletar só o necessário, ter base legal para cada uso, proteger os dados e atender pedidos dos titulares. É mais barato prever isso na arquitetura do que adaptar depois.

Large Language Model: modelo de IA treinado com grandes volumes de texto para entender e gerar linguagem, como Claude, GPT e Gemini.

É o motor por trás de chatbots, agentes e ferramentas de código com IA. Cada LLM tem custo, velocidade e qualidade diferentes, e a escolha muda conforme a tarefa. O que mais pesa no resultado costuma ser o contexto e os dados que você entrega para ele.

Arquivo de texto na raiz do site que resume, em Markdown, o que a empresa faz e quais páginas importam, para IAs lerem com facilidade.

É uma proposta de padrão, ainda não adotada oficialmente por todas as IAs, mas barata de publicar. Funciona como um mapa curto do site para modelos de linguagem. Entra no pacote de GEO junto com dados estruturados e conteúdo em formato de resposta.

Plataformas que montam sistemas com blocos visuais e permitem escrever código em partes específicas.

Acelera sistemas internos e fluxos simples. Fica caro ou limitado quando o produto cresce, precisa de regras próprias ou de muita escala. Antes de escolher, verifique se dá para exportar seus dados e o que acontece se a plataforma mudar de preço.

Minimum Viable Product: a menor versão do produto que resolve o problema principal e pode ser colocada no ar para usuários reais.

O objetivo do MVP é aprender com uso real, gastando pouco. Mínimo não quer dizer malfeito: o que entra precisa funcionar bem. O erro mais comum é tratar o MVP como versão completa e passar meses sem publicar nada.

Contratar um time de desenvolvimento em país próximo, com fuso horário parecido, em vez de um time local ou muito distante.

Empresas dos Estados Unidos e da Europa contratam times da América Latina pelo fuso compatível e pelo custo. Para você, o ponto é avaliar comunicação, idioma e horários de reunião antes do preço. O Studio, de Fortaleza, atende clientes no Brasil e em outros países.

Ferramentas que criam sites, apps e automações sem escrever código, só com interface visual.

Ótimo para validar uma ideia ou automatizar tarefas internas. Os limites aparecem com regras de negócio complexas, volume de usuários e necessidade de integrações próprias. Migrar depois custa caro, então vale pensar no próximo passo antes de começar.

A instrução em texto que você dá a um modelo de IA, com o pedido, o contexto e o formato de resposta esperado.

Prompt claro, com exemplos e restrições, gera resultado mais previsível. Em produto, prompts viram parte do sistema e precisam ser versionados e testados como código. Prompt sozinho não resolve falta de dados ou de regra de negócio.

Versão navegável das telas, feita antes do código, para testar o fluxo e validar a ideia com usuários e sócios.

Mudar um protótipo leva minutos; mudar um sistema pronto leva semanas. Um bom protótipo mostra o caminho principal do usuário com conteúdo real. Ele também serve de referência clara para quem vai construir.

Colocar o produto ou uma nova versão no ar para os usuários, incluindo domínio, servidor, lojas de app e monitoramento.

Deploy é o passo técnico; publicação é tudo que precisa estar pronto para o usuário chegar. Em apps, inclui a revisão da App Store e da Google Play, que tem prazo e regras próprias. Planeje a publicação desde o início, não na última semana.

Assumir um sistema parado, atrasado ou com problemas graves, deixado por outro time, e colocá-lo no ar ou de volta nos trilhos.

O resgate começa por uma auditoria: o que existe, o que funciona e o que precisa ser refeito. Nem sempre vale aproveitar tudo, e a decisão deve ser feita com números. É um dos serviços do Studio para founders que já gastaram e ainda não têm produto no ar.

Plano que mostra o que o produto vai ganhar e em que ordem, ligado aos objetivos do negócio.

Um roadmap útil prioriza problemas a resolver, não uma lista de funcionalidades com datas fixas. Ele muda conforme o uso real mostra o que importa. Revise com frequência e diga com clareza o que ficou para depois.

Software as a Service: sistema acessado pela internet com cobrança recorrente, como assinatura mensal ou anual.

O modelo depende de receita recorrente, por isso churn e onboarding pesam tanto quanto as funcionalidades. Um SaaS precisa de cobrança, planos, permissões e, quase sempre, várias empresas usando o mesmo sistema. Esses pontos entram no escopo desde o primeiro dia.

Search Engine Optimization: ajustes de conteúdo e técnica para seu site aparecer melhor nos resultados de buscadores como o Google.

Inclui velocidade, estrutura das páginas, títulos, links internos e conteúdo que responde ao que as pessoas buscam. O resultado vem em meses, não em dias, mas gera visitas sem pagar por clique. Hoje o trabalho de SEO anda junto com o de GEO.

Empresa que desenvolve software sob encomenda para outras empresas, normalmente com times de desenvolvimento por projeto.

Costuma ser forte em código e mais fraca em produto e design, mas isso varia muito. Antes de contratar, pergunte quem decide o que será construído, como o prazo é definido e o que acontece quando ele estoura. Comparamos os modelos numa página própria.

Ciclo curto de trabalho, em geral de 1 a 2 semanas, com um conjunto definido de tarefas e uma entrega no final.

Sprints dão ritmo e permitem ajustar a rota com frequência. Para você, o que importa é ver algo funcionando ao fim de cada ciclo, não um relatório de horas. Se várias sprints passam sem nada no ar, algo está errado no escopo ou no time.

User Interface: a parte visual do produto, como telas, cores, tipografia, ícones e componentes.

Uma boa UI deixa claro o que é clicável, o que é importante e o que acabou de acontecer. Ela depende de uma boa UX: tela bonita com fluxo confuso continua confusa. Design system mantém a UI consistente conforme o produto cresce.

User Experience: como a pessoa vive o uso do produto, se consegue fazer o que precisa, com quanto esforço e quanta confiança.

UX passa por fluxo, textos, tempo de resposta, mensagens de erro e até suporte. Melhorar a UX costuma reduzir churn e chamados de suporte. Começa entendendo a tarefa do usuário, não escolhendo cores.

Construir software pedindo para a IA gerar o código, aceitando o resultado sem ler nem revisar a fundo.

Funciona para protótipos e testes rápidos. Em produção, costuma gerar falhas de segurança, código duplicado e dívida técnica que ninguém entende. Usar IA no build é ótimo; o que muda o resultado é ter alguém que revisa e responde pelo código.

Esboço simples de uma tela, sem cores nem acabamento, que mostra a estrutura e a hierarquia do conteúdo.

Serve para discutir o que vai em cada tela antes de gastar tempo com visual. É rápido de fazer e de jogar fora. Com design system pronto, muitos times pulam o wireframe e vão direto para um protótipo com os componentes reais.