O site de uma instituição de pagamento publica mais do que marca e produto. Cinco conjuntos de informação têm norma própria, lugar certo e data de vigência, e o erro mais caro é fechar o design e descobrir na última semana que faltam ouvidoria, prospecto e tarifas.

A Resolução BCB nº 80 pede a condição de instituição de pagamento de forma clara nos canais e as modalidades divulgadas no site. A Resolução BCB nº 28 pede o telefone gratuito da ouvidoria acessível pela página inicial, não só na de contato, e a divulgação semestral das atividades, o que cria uma página que cresce duas vezes por ano. A Resolução BCB nº 96 cria a peça que quase nenhum site tem: o prospecto de informações essenciais, antes de contratar a conta, com as características, as medidas de segurança e a forma de consultar as tarifas. E o Manual de Uso da Marca Pix manda a marca aparecer nas peças que promovem o Pix, nunca só com o logotipo e em igualdade com as outras bandeiras.

A publicação semestral é onde o CMS decide o projeto: uma coleção de relatórios deixa a tarefa com quem responde por ela, usando o editor de conteúdo do CMS que publica sem mexer no design. No artigo, cada norma vira uma linha de tabela com o que exige, onde mora e desde quando, como complemento de as páginas que um site de fintech precisa ter. Também entra o que não é obrigação da fintech que opera sobre licença de parceira.

Leia completo no blog da Wama:

A Resolução BCB 587 saiu em 18 de setembro e muita fintech leu como assunto para fevereiro de 2027. Uma parte dela já vale desde a publicação.

A marcação de fundada suspeita de fraude entrou em vigor no mesmo dia. Marcado o CPF ou CNPJ, a instituição rejeita todo Pix daquele usuário, como pagador e como recebedor, e também registro e portabilidade de chave. O cliente pode pedir revisão, e a decisão sai em até sete dias, com os fundamentos registrados. Ou seja: o back-office de revisão já devia estar de pé.

Fevereiro concentra o resto: aviso da marcação ao cliente, cobrança híbrida com boleto e Pix Cobrança na mesma fatura, e novos deveres de comunicação. Em março chega a mensagem de recusa por suspeita de fraude da versão 7.4 do manual de experiência, que é outra peça e não substitui o aviso. Em julho, a conta-salário ganha Pix Automático.

No artigo, lemos a norma pelo lado de quem constrói o produto, como continuação de o que o Banco Central já exige de quem constrói o app: o que vira tela, rotina ou regra de cobrança, com um calendário por data e o que entra em o contrato com quem desenvolve.

Leia completo no blog da Wama:

No Framer, pôr o app numa subpasta do site em vez de num subdomínio custa US$ 200 por mês sobre o plano Pro. Antes de assinar, vale saber o que o Google diz sobre a diferença.

O Multi Site junta vários projetos e sites externos sob um único domínio, por regras de rewrite: o endereço que o visitante digitou fica, e o conteúdo vem de outro lugar. Segundo a ajuda do Framer sobre Multi Site, atualizada em 15 de setembro de 2026, as regras agora ficam em Site Settings, Hosting, Multi Site, e só valem depois de publicar o projeto.

O recurso vem no Advanced Hosting. A página de preços do Framer mostra o add-on com no máximo seis rewrites. Com subdomínio, basta apontar o DNS.

E o SEO? Em maio de 2018, John Mueller, analista do Google, afirmou que subdomínio e subdiretório são vistos igual, segundo o Search Engine Journal. O critério é de conteúdo: blog e central de ajuda são o mesmo site e apontam para a subpasta. O painel logado ninguém procura no Google.

No artigo estão o que quebra quando o app vai para a subpasta (caminho base, cookies, senha, medição), a migração página por página com uma única regra curinga e as quatro situações para decidir entre subdomínio, Multi Site e um projeto só.

Trocar de plano em um SaaS que cobra por Pix Automático pode exigir que o cliente autorize tudo de novo no banco.

A autorização nasce de valor fixo ou de valor variável. No fixo, o banco do cliente rejeita qualquer instrução com valor diferente do autorizado. E o FAQ do Banco Central sobre o Pix Automático é direto: a recorrência não se altera. Em troca de plano ou reajuste anual, a empresa cancela e cria outra, que o cliente confirma de novo.

No variável, o risco muda de lugar. O guia de implementação do Pix Automático informa que o valor máximo fica guardado só na instituição do pagador. O produto não enxerga o teto, e cobrança acima dele não é agendada. Antes de escolher, vale entender o que cada modelo de preço obriga o produto a construir.

A falha também tem regra. Pela Instrução Normativa BCB nº 513, o banco tenta debitar entre 0h e 8h e de novo entre 18h e 21h. Bloquear o acesso na manhã do vencimento é erro.

E só cobra quem tem CNPJ ativo há pelo menos seis meses. Startup aberta no mês passado lança com outro meio de pagamento.

No artigo estão as quatro jornadas de autorização, o calendário de 2 a 10 dias antes do débito, o que muda quando o cliente é uma empresa e a diferença entre cancelar a autorização e cancelar o plano.

Uma regra "bloquear todo mundo fora do Brasil" no novo firewall do Framer pode tirar o seu site do Google.

O recurso saiu em 1º de outubro e redireciona ou bloqueia visitantes por país, por caminho ou pelos dois. Segundo a central de ajuda do Framer sobre o firewall, o Googlebot recebe a mesma regra que um visitante do país do IP. E os endereços padrão dele aparecem como dos Estados Unidos.

Com os agentes de IA acontece o contrário: a regra de país não se aplica a eles. Uma página bloqueada continua legível para quem quer aparecer nas respostas de assistentes de IA, e continua visível para quem achou que o bloqueio escondia o conteúdo.

O firewall só vem com o Advanced Hosting, de US$ 200 por mês sobre o Pro, conforme a página de preços do Framer. A segurança básica (TLS, DDoS, firewall global, antispam) já vem em todo site. O add-on resolve distribuição, não proteção.

No artigo estão os quatro casos em que a conta fecha, o que fazer quando o problema é identidade e não geografia, e as quatro perguntas para decidir antes de qualquer cartão entrar na conta.

Quem constrói app de fintech sobre a licença de um banco parceiro ganhou requisito novo de produto, e ele aparece na tela.

A Resolução Conjunta nº 16 põe na instituição autorizada a responsabilidade pelo serviço, mesmo quando a interface é da empresa parceira. Na prática, a marca da fintech continua, mas a instituição não pode sumir: o nome dela precisa aparecer de forma visível no app, no site, no comprovante, no extrato, no cartão e no boleto. Isso se soma às telas que o Banco Central já padronizou para o Pix.

O sistema também passa a prestar contas à parceira: disponibilidade que ela consiga consultar, trilhas de auditoria, indicadores que podem suspender o contrato e um inventário de fornecedores. Por isso vale decidir em nome de quem ficam as contas de nuvem no primeiro dia.

E o nome entrou na regra. A Resolução Conjunta nº 17 inclui marca e domínio, então banco ou bank no nome vira problema antes do design.

Hoje, 1º de outubro, começa a valer o registro das tomadoras pela Instrução Normativa BCB nº 776, e os contratos anteriores têm até 31 de dezembro de 2026 para se adequar. No artigo estão o calendário completo, os erros comuns e o checklist para escolher quem vai construir.

Um prompt vale para uma tarefa. Uma skill vale para todas as tarefas daquele tipo, e essa diferença aparece na segunda semana de uso do agente.

As Skills do Framer, lançadas em 22 de setembro de 2026, são instruções salvas dentro do projeto: sistema de design, voz da marca, jeito de preencher o CMS e o que conferir antes de publicar. Sem skill, cada pessoa da equipe descreve o site do seu jeito e o agente interpreta cada pedido do zero. Com skill, o pedido curto basta.

Dois detalhes mudam a entrega de um site. A skill mora no projeto, e não na conta de quem a escreveu, então vai junto quando o projeto passa para o cliente. E ela cita páginas, componentes e estilos do próprio site com @pages, @components e @styles, como mostra o registro de novidades do Framer.

O guia de boas práticas da Framer Academy sugere três palavras para o grau de obrigação: must, prefer e can. O valor, porém, está em escrever o que o canvas não mostra, as decisões que raramente ficam visíveis no arquivo final.

No artigo estão as quatro skills que cobrem quase todo site institucional, quem deve escrever cada uma e como testar antes de confiar no agente.

Os tutoriais de CMS ensinam a montar coleções para quem constrói o site. A pergunta que pesa depois da entrega é outra: quem vai editar, e com qual acesso.

A resposta começa na modelagem. Conteúdo escrito direto no canvas só muda com acesso de design. Conteúdo que virou campo de coleção muda pelo CMS, sem abrir o Framer. Por isso o briefing define as coleções quando lista o que a empresa vai publicar com frequência.

Em setembro de 2026 chegou o campo List, anunciado no registro de novidades do Framer. Perguntas frequentes, passos e resultados de um case viram linhas que a equipe acrescenta e reordena, em vez de Título 1, Título 2, Título 3 travando a quantidade.

Os papéis também contam no orçamento. Segundo a página de preços do Framer, o Content Editor custa US$ 10 ao mês e cuida de CMS e edição na página, e o Viewer só lê e comenta, de graça. Com a chave Deploy, uma única pessoa decide o que vai ao ar.

No artigo estão os limites do CMS por plano, como funciona a edição direto no site publicado e os sete pontos para conferir com o estúdio antes de receber o projeto.

Um site é entregue e encerrado. Um SaaS continua rodando, guardando dado de gente e cobrando cartão todo mês. É por isso que o contrato com uma agência de desenvolvimento de SaaS precisa de perguntas que quase nenhuma proposta responde.

A primeira: em nome de quem ficam a conta de nuvem, o domínio e o repositório. Conta no nome da agência, com você como convidado, é o arranjo que trava a saída. Fica de fora a propriedade do código, que é outra discussão, mas também precisa estar no contrato.

A segunda é sobre o dado. Pela Lei 13.709, de 2018, a empresa dona do produto é a controladora e a agência é a operadora. Contratar não transfere a responsabilidade. O guia orientativo da ANPD sobre agentes de tratamento usa exatamente esse caso como exemplo.

A terceira muda mais proposta do que qualquer outra: quanto custa manter o produto no ar por mês, separado do custo de construir. Misturar os dois esconde a conta que chega depois da entrega.

No artigo estão a tabela do que o contrato precisa escrever, a lista completa do que exigir antes de assinar e o que acontece quando você troca de fornecedor.

Contratar agência de UI UX olhando só o portfólio é comprar a tela mais bonita de cada projeto. O produto vive nas outras cem.

Antes de assinar, vale exigir três coisas por escrito: a lista do que chega nas suas mãos, o nível de acessibilidade que o design vai cumprir e o que acontece com os arquivos no fim do contrato.

A acessibilidade deixou de ser gentileza. O artigo 63 da Lei Brasileira de Inclusão já pedia sites acessíveis, e em março de 2025 a ABNT lançou a NBR 17225, alinhada à WCAG 2.2. Contraste, ordem de navegação por teclado, rótulos de formulário e área de toque são decisões de interface: se a agência não desenha com isso na mesa, o desenvolvimento herda o problema.

O último item parece burocracia e é o que mais dói quando falta. A lógica é a mesma de quem fica com o código no fim do contrato: o que não está escrito fica com quem guarda o arquivo.

No artigo estão a lista completa de entregáveis, os três modelos de cobrança, o roteiro para pedir proposta e os sinais de alerta que aparecem antes de qualquer tela.

No Brasil, parte da tela de uma fintech já chega decidida antes da primeira reunião de design. O Banco Central publica os Requisitos Mínimos para a Experiência do Usuário do Pix, e o documento faz parte do regulamento.

Lá estão os nomes fixos ("Chave Pix", "Pix Copia e Cola", "Pix Automático"), o conteúdo mínimo das mensagens de erro e sucesso, o atalho obrigatório para o canal de reclamação e um detalhe que é design a serviço da segurança: o campo Descrição aparece literalmente, sem link clicável.

E vem mais. A versão 7.4 dos requisitos de experiência do Pix, válida a partir de 1º de março de 2027, proíbe propaganda e hiperlink no comprovante, manda o app alertar quando a identificação de um contato favorito mudar e padroniza o extrato. Quem refaz um app agora deveria desenhar pela versão nova.

A norma define o piso. Confiança, estados de espera e mensagens de erro com motivo continuam sendo trabalho de design, e é aí que o artigo entra, junto com o que o Banco Central exige de quem constrói o app.

Um app de fintech passa por três aprovações antes de chegar ao cliente: a da loja, a do Banco Central e a do próprio usuário, que precisa ser identificado antes de movimentar dinheiro.

A primeira surpreende muita gente. As diretrizes de revisão da App Store determinam que apps de serviços financeiros sejam submetidos pela empresa que presta o serviço, não por quem desenvolveu. No Android, a política de serviços financeiros do Google Play pede a declaração de recursos financeiros no Play Console. Ou seja, a conta nas lojas nasce no nome da fintech, e o estúdio entra como convidado.

A segunda mudou em dezembro de 2025. A Resolução BCB nº 538 reescreveu a política de segurança cibernética das instituições de pagamento e mandou a instituição verificar os sistemas feitos por terceiros. Quem escreve o app passa a ser algo que a fintech precisa conferir e documentar, com trilha de auditoria, teste de intrusão anual e controle a cada versão nova.

No artigo estão os trechos da norma que entram no cronograma, a ordem certa entre compliance e design no cadastro e a tabela do que exigir por escrito, junto com quem fica com o código e as contas do app.

Quem é instituição de pagamento autorizada tem uma obrigação no próprio site. A Resolução BCB nº 80, de 25 de março de 2021, no artigo 5º, manda declarar de forma clara essa condição nos canais de comunicação e divulgar no site as modalidades de serviço de pagamento que a empresa presta. As instituições já autorizadas tiveram até 31 de dezembro de 2022 para se adequar.

As modalidades vêm da Lei nº 12.865, de 2013, que lista oito atividades, da gestão de conta de pagamento à emissão de cartão e ao credenciamento de maquininha. O erro mais comum é colar o texto da norma num parágrafo que ninguém lê. Traduzir para a linguagem do cliente é trabalho de conteúdo.

E nem toda fintech carrega essa obrigação. Muitas operam sob a licença de um parceiro, e aí o site precisa nomear qual instituição autorizada responde pela conta. Quem só vende software financeiro, sem custódia, precisa dizer que não guarda dinheiro de ninguém. É aqui que o site vira o ponto em que a operação passa a depender do que está no ar.

No artigo estão os três arranjos regulatórios, as oito páginas que um site de fintech precisa ter e como tudo isso entra no briefing que pergunta as coisas certas antes do design.

A nota do PageSpeed é teste de laboratório: o Lighthouse carrega a página num celular simulado e devolve um número. Para a busca, o Google usa as Core Web Vitals medidas em visitantes reais, e a documentação do PageSpeed Insights escreve que dado bom de laboratório não significa, necessariamente, experiência real boa.

A distância entre os dois aparece no dado. Em agosto de 2026, três construtores hospedados tinham nota mediana de laboratório entre 61 e 62 no celular, e a aprovação com visitantes no Brasil ia de 23,4% a 79,7%, segundo o relatório de Core Web Vitals por tecnologia do HTTP Archive. Número parecido no teste, experiência oposta no celular de quem visita.

O país passa em 33,9% no celular, contra 53,0% no mundo. Sites em Framer ficam em 58,3% por aqui, e o ponto fraco deles não é o carregamento: é o INP, a resposta ao toque, custo que cresce a cada script de terceiro instalado, como mostra o guia para otimizar o INP.

Quando alguém promete nota 90 garantida, dá para conferir em poucos minutos, com a mesma ferramenta citada. A ajuda do Framer sobre o PageSpeed Insights já registra variação de até 15 pontos entre testes da mesma página. No artigo estão o passo a passo da conferência e o que escrever na proposta no lugar da nota.

A licença da fonte que o seu site serve é da empresa dona do site, não de quem desenhou a página. Fonte instalada no computador não vale para a web: publicar exige licença de webfont, vendida à parte e dimensionada por visitas ou por domínio.

A ajuda oficial do Framer sobre licença de fonte é direta nesse ponto, e ainda recomenda subir os arquivos em WOFF ou WOFF2. O formato entregue costuma denunciar a licença: quem manda um TTF de desktop para colocar no site provavelmente não comprou licença de web.

Catálogo aberto resolve o problema antes de ele existir. Pela própria SIL, a licença que cobre a maior parte do Google Fonts permite uso em site, inclusive comercial, sem exigência de crédito.

Com imagem existe uma camada que a licença do banco não cobre sozinha: a pessoa retratada. A Súmula 403 do Superior Tribunal de Justiça dispensa prova de prejuízo na indenização por publicação não autorizada de imagem com fim econômico ou comercial.

A conta chega anos depois, quando um rastreador identifica a fonte servida, e aí não é mais o preço da licença que você deixou de comprar. No artigo estão as três linhas para escrever na proposta e o inventário para pedir na entrega.

O site de um SaaS e a aplicação que o cliente abre depois de assinar são dois projetos com objetivos opostos. O site é público e existe para convencer quem ainda não conhece o produto. A aplicação é privada, acessada por quem já pagou, e precisa desaparecer de tanto funcionar.

Confundir os dois sai caro: empresa que contrata design de produto e recebe uma home bonita, ou que pede um site e descobre tarde que o problema estava dentro da ferramenta. Se a dificuldade é gente que não conhece o produto, o trabalho é o site que vende o produto. Se é gente que assinou e sumiu, o trabalho é a interface.

A diferença está no tempo de exposição. Alguém visita um site por alguns minutos e decide. A mesma pessoa abre o painel do SaaS que assinou várias vezes por semana, durante anos. Atrito em tela de uso diário é cobrado todo mês, na renovação.

O artigo separa os quatro momentos que concentram o efeito sobre ativação e permanência. O último costuma ser tratado como sobra e não é: as três funções da tela vazia transformam a primeira tela sem dado nenhum em onboarding acontecendo no lugar certo.

Tem ainda os sete padrões catalogados em telas de produtos em operação, o que medir antes de redesenhar e o que pedir no escopo, com a fronteira do que já é a construção do produto em si.

Em software sob medida, a Lei do Software põe os direitos sobre o programa com a empresa que contratou. Só que a mesma frase abre com “salvo estipulação em contrário”, e é aí que mora o risco: quem decide, na prática, é o contrato.

Um contrato pode fazer duas coisas bem diferentes com o mesmo código. Na cessão, a empresa pode alterar, vender e contratar outro time. Na licença, ela paga para usar, e o titular segue sendo o fornecedor. O problema é pagar preço de projeto exclusivo e receber termo de ferramenta pronta.

O segundo ponto cego são as bibliotecas que o fornecedor já tinha. Sem licença perpétua para essas peças, o código cedido pode não rodar sem o que não foi cedido.

E o código escrito com IA? A Lei de Direitos Autorais define autor como pessoa física, então a autoria se apoia em quem revisou, decidiu e integrou o resultado.

Em site, a Wama resolve a titularidade de outro jeito: o projeto em Framer é transferido para a conta do cliente, e quem quiser trocar de fornecedor leva site, domínio e conta.

No artigo estão as sete cláusulas que o contrato precisa escrever, o que pedir na entrega e quando vale registrar o software no INPI.

Desde o lançamento do Framer 3.0, os Agents do Framer AI editam o projeto de produção: páginas, componentes, estilos, CMS e SEO. Os tutoriais ensinam a gerar página com prompt e param aí. Numa empresa com site no ar, a pergunta é outra: quem pode pedir, onde a mudança é testada e quem aprova antes de publicar.

A primeira resposta está nas branches. Pela ajuda do Framer sobre branches, a branch é uma cópia isolada do projeto inteiro, com URL de pré-visualização e comparativo das mudanças. O detalhe que mais confunde: aplicar a branch não coloca nada no ar. O site só muda quando a main é publicada.

A segunda está nas permissões. Pela página de papéis e permissões do Framer, em planos com permissões avançadas o acesso se divide em Design, Content e Deploy, e com staging ligado só quem tem Deploy promove a mudança para o site no ar. O marketing publica conteúdo, e ninguém fora do núcleo mexe em layout.

A Wama usa os Agents no próprio fluxo de produção e transfere cada site para a conta do cliente operar, com perfil de editor de conteúdo e treinamento do time no CMS.

No artigo estão a tabela do que delegar ao agente e do que manter com uma pessoa, como a cota de créditos se comporta numa equipe e os erros mais comuns ao liberar a IA para todo mundo.

Criar SaaS com IA resolve bem a validação: em poucos dias, uma ferramenta de prompt entrega login, banco de dados e telas que funcionam. O que ela não garante é quem enxerga o dado de quem.

Os levantamentos de 2026 mostram onde isso pega. Uma varredura em 1.072 apps feitos em plataformas de vibe coding com banco no Supabase concluiu que 98% tinham ao menos uma falha, e em 172 deles qualquer pessoa conseguia apagar registros do banco sem fazer login. No relatório da Veracode sobre segurança de código gerado por IA, os modelos passam nos testes de segurança em 56% das tarefas: ficaram melhores em programar, não em proteger.

A primeira das falhas que se repetem nem aparece num teste de clique. Tabela sem RLS, a regra que decide quem lê cada linha, pode ser lida e alterada enquanto a tela funciona perfeitamente, como avisa a documentação do Supabase sobre RLS.

A Wama criou o ManyFeed, SaaS próprio de prova social, com IA no processo, e todo código gerado passa por revisão humana sobre código escrito por IA antes de chegar ao cliente.

No artigo estão o teste de uma tarde que o fundador roda no próprio app sem saber programar, o prazo de três dias úteis que a LGPD cobra quando o dado vaza, e a tabela para decidir entre continuar no construtor, reforçar ou reconstruir.