1. The real decision axis: not "better", but "who owns the logic"
It's tempting to frame Framer vs. hand-written code as a maturity ladder — as if Framer is "for beginners" and code is "for professionals." That framing is wrong and leads to bad decisions in both directions. The actual axis that matters is: where does the logic of the product live, and how often does it change in ways a visual tool can't express?
A marketing site has almost no logic — it has content, layout, and motion. A SaaS dashboard has a lot of logic — permissions, data mutations, edge cases, integrations with other systems. The tool that fits a project is a function of how much of that second category it has, not how "advanced" the team building it is.
2. When Framer wins
- The page is mostly presentation. Landing pages, portfolios, product marketing pages, waitlists, event pages — content and visual polish are the actual product, not a wrapper around business logic.
- Iteration speed matters more than architectural control. A marketing or design team needs to ship copy changes, A/B test a hero section, or adjust a pricing table without opening a pull request.
- One person needs to own design and shipping. No design-to-dev handoff queue, no waiting on engineering bandwidth for a headline change.
- The animation is the point. Scroll-triggered reveals, spring physics, layout transitions — recreating this by hand in CSS/JS is real engineering work that Framer gives you through property panels.
3. When traditional code wins
- There's real backend logic. Authentication, permissions, payments, anything that reads/writes a database with business rules attached — a visual builder either can't express this or forces you into its own constrained backend, which becomes its own lock-in.
- The product needs to integrate deeply with existing systems. Internal APIs, a specific CI/CD pipeline, a monorepo shared with other services — code lives in the same version control and review process as the rest of the company's engineering.
- Performance or bundle size is a hard constraint. Hand-written code lets you control exactly what ships; visual builders trade some of that control for their editing model.
- The team is already a code-first engineering org. If every other part of the stack is a Next.js app in a shared repo, adding one page built in a completely separate tool creates a second system to maintain, deploy, and reason about.
4. The hidden costs people forget on both sides
| Choosing Framer | Choosing code |
|---|
| Migrating out later is real work — you're re-implementing a visually-built site as code from scratch, not exporting clean source. | Every future copy tweak, layout change, or animation adjustment needs a developer and a deploy, even for trivial content changes. |
| Hosting/CMS pricing scales with traffic — a viral marketing page can get expensive in ways a static export wouldn't. | Design fidelity depends entirely on how carefully the team reimplements it — "close enough" often ships instead of pixel-perfect. |
| You inherit the platform's release cycle and outages, same as any hosted SaaS dependency. | The design-to-code handoff step (see Lesson 18) is itself a source of drift and delay if not managed well. |
5. The hybrid pattern most real teams actually use
In practice, this is rarely a company-wide, one-time decision. The most common real-world setup: the marketing site (home page, pricing, blog, landing pages for campaigns) lives in a tool like Framer or Webflow, built and iterated on by design/marketing without engineering in the loop for every change — while the actual product (the logged-in application) is a separate codebase, usually a framework like Next.js, owned by engineering.
The two systems talk to each other at specific boundaries: a "Sign up" or "Log in" button on the Framer-built marketing site links out to the real application's domain. Shared visual identity (colors, type, logo) is kept in sync manually or via shared design tokens, but the two are otherwise independent deploys with independent release cycles.
Why this works well: the two halves of a typical product have genuinely different rates of change and genuinely different owners. Marketing pages change weekly and are owned by non-engineers; the product changes with every sprint and is owned by engineers. Matching the tool to the owner and the change cadence, instead of forcing one tool to do both jobs, is usually the actual optimization — not a compromise.
6. What happens when you outgrow Framer
The most common trigger for migrating off a visual builder isn't "the tool got worse" — it's that a page that started as pure marketing content grows real logic over time: a pricing page needs to check the visitor's existing plan, a waitlist form needs custom validation and a real database instead of a simple integration, a landing page needs to render different content per logged-in user. At that point the page has crossed from "presentation" into "product," and the rebuild-in-code conversation becomes worth having.
When that migration happens, budget for it as a real rebuild, not a port: content and visual direction transfer conceptually, but the implementation is written from scratch in the target framework, same as if you were redesigning a legacy PHP site into React — Lesson 18's handoff practices (naming tokens consistently, documenting interaction states) make this meaningfully faster, but they don't eliminate the work.
7. A practical example: same project, two paths
Take a generic scenario: an early-stage product needs (a) a public marketing site to convert visitors into signups, and (b) the actual logged-in app behind that signup. A reasonable default split: build (a) in Framer — fast iteration, no engineering bottleneck, good enough performance for a mostly-static page — and build (b) in a framework like Next.js, because it needs auth, a database, and per-user logic from day one. As the company grows, the marketing site might later need a blog with dynamic SEO routing that outgrows Framer's CMS, at which point it's reasonable to migrate just that piece to the same codebase as the product — while the rest of the marketing pages might stay put, because they still don't need it.
8. A decision checklist
Lean Framer if: the page's content changes more often than its logic, a non-engineer needs to ship most changes, and there's no meaningful backend behavior beyond form submissions or simple integrations.
Lean code if: the page needs authentication, a real database with business rules, deep integration with an existing codebase, or precise control over performance and bundle size.
Lean hybrid if: you're building a typical product company — the answer is almost always "both," split along the marketing-site/product-app boundary described above, not a single tool for everything.
The mistake to avoid is treating this as a one-time, company-wide, ideological choice ("we're a code shop" or "we're no-code"). The right unit of decision is the individual page or feature, evaluated against how much real logic it carries — not the company's engineering culture as a whole.
1. O eixo real da decisão: não "melhor", mas "quem é dono da lógica"
É tentador enquadrar Framer vs. código escrito à mão como uma escada de maturidade — como se o Framer fosse "pra iniciantes" e código fosse "pra profissionais". Esse enquadramento está errado e leva a decisões ruins nos dois sentidos. O eixo que realmente importa é: onde vive a lógica do produto, e com que frequência ela muda de um jeito que uma ferramenta visual não consegue expressar?
Um site institucional quase não tem lógica — tem conteúdo, layout e movimento. Um dashboard de SaaS tem muita lógica — permissões, mutação de dados, casos de borda, integrações com outros sistemas. A ferramenta que se encaixa num projeto é função de quanto ele tem dessa segunda categoria, não de quão "avançado" é o time que constrói.
2. Quando o Framer vence
- A página é majoritariamente apresentação. Landing pages, portfólios, páginas de marketing de produto, listas de espera, páginas de evento — conteúdo e acabamento visual são o produto de fato, não uma casca em volta de lógica de negócio.
- Velocidade de iteração importa mais que controle arquitetural. Um time de marketing ou design precisa publicar mudanças de texto, testar A/B numa seção de hero, ou ajustar uma tabela de preços sem abrir um pull request.
- Uma pessoa só precisa ser dona do design e da publicação. Sem fila de handoff design-pra-dev, sem esperar disponibilidade de engenharia pra mudar um título.
- A animação é o ponto central. Revelações disparadas por scroll, física de spring, transições de layout — recriar isso à mão em CSS/JS é trabalho de engenharia real que o Framer entrega por painéis de propriedade.
3. Quando o código tradicional vence
- Existe lógica de backend de verdade. Autenticação, permissões, pagamentos, qualquer coisa que lê/escreve num banco com regra de negócio anexada — uma ferramenta visual ou não consegue expressar isso, ou te empurra pro backend limitado dela mesma, que se torna seu próprio lock-in.
- O produto precisa se integrar a fundo com sistemas existentes. APIs internas, um pipeline de CI/CD específico, um monorepo compartilhado com outros serviços — código vive no mesmo controle de versão e processo de review do resto da engenharia da empresa.
- Performance ou tamanho de bundle é uma restrição rígida. Código escrito à mão te dá controle exato do que é enviado; ferramentas visuais trocam parte desse controle pelo modelo de edição delas.
- O time já é uma organização code-first. Se todo o resto do stack é uma aplicação Next.js num repositório compartilhado, adicionar uma página construída numa ferramenta totalmente separada cria um segundo sistema pra manter, publicar e entender.
4. Os custos ocultos que ninguém lembra, dos dois lados
| Escolhendo o Framer | Escolhendo código |
|---|
| Migrar pra fora depois é trabalho real — você reimplementa do zero um site construído visualmente como código, não exporta uma fonte limpa. | Toda mudança futura de texto, layout ou animação precisa de um desenvolvedor e um deploy, mesmo pra mudanças triviais de conteúdo. |
| Preço de hospedagem/CMS escala com tráfego — uma página de marketing que viraliza pode ficar cara de um jeito que uma exportação estática não ficaria. | A fidelidade do design depende inteiramente de quão cuidadoso o time é ao reimplementar — "bom o suficiente" frequentemente vai pro ar em vez de pixel-perfect. |
| Você herda o ciclo de release e as instabilidades da plataforma, igual qualquer dependência de SaaS hospedado. | O passo de handoff design-pra-código (ver Lição 18) é ele mesmo uma fonte de divergência e atraso se não for bem gerenciado. |
5. O padrão híbrido que a maioria dos times de verdade usa
Na prática, raramente essa é uma decisão única e da empresa inteira. A configuração mais comum no mundo real: o site institucional/marketing (home, preços, blog, landing pages de campanha) vive numa ferramenta como Framer ou Webflow, construído e iterado por design/marketing sem engenharia no meio de cada mudança — enquanto o produto de fato (a aplicação logada) é uma base de código separada, geralmente um framework como Next.js, de propriedade da engenharia.
Os dois sistemas conversam em pontos específicos: um botão de "Cadastre-se" ou "Entrar" no site de marketing construído em Framer aponta pro domínio da aplicação real. Identidade visual compartilhada (cores, tipografia, logo) é mantida em sincronia manualmente ou via design tokens compartilhados, mas os dois são, no resto, deploys independentes com ciclos de release independentes.
Por que isso funciona bem: as duas metades de um produto típico têm ritmos de mudança genuinamente diferentes e donos genuinamente diferentes. Páginas de marketing mudam semanalmente e são de não-engenheiros; o produto muda a cada sprint e é de engenheiros. Combinar a ferramenta com o dono e o ritmo de mudança, em vez de forçar uma ferramenta só a fazer os dois trabalhos, geralmente é a otimização real — não um meio-termo.
6. O que acontece quando você cresce além do Framer
O gatilho mais comum pra migrar de uma ferramenta visual não é "a ferramenta piorou" — é que uma página que começou como conteúdo puro de marketing ganha lógica real com o tempo: uma página de preços precisa checar o plano atual do visitante, um formulário de lista de espera precisa de validação customizada e um banco de dados real em vez de uma integração simples, uma landing page precisa renderizar conteúdo diferente por usuário logado. Nesse ponto a página cruzou de "apresentação" pra "produto", e a conversa sobre reconstruir em código passa a valer a pena.
Quando essa migração acontece, planeje como uma reconstrução real, não uma portabilidade: conteúdo e direção visual transferem conceitualmente, mas a implementação é escrita do zero no framework de destino, igual seria se você estivesse redesenhando um site PHP legado pra React — as práticas de handoff da Lição 18 (nomear tokens de forma consistente, documentar estados de interação) tornam isso bem mais rápido, mas não eliminam o trabalho.
7. Um exemplo prático: o mesmo projeto, dois caminhos
Um cenário genérico: um produto em estágio inicial precisa (a) de um site público de marketing pra converter visitantes em cadastros, e (b) da aplicação logada de fato por trás desse cadastro. Uma divisão padrão razoável: construir (a) em Framer — iteração rápida, sem gargalo de engenharia, performance boa o suficiente pra uma página majoritariamente estática — e construir (b) num framework como Next.js, porque precisa de autenticação, banco de dados e lógica por usuário desde o primeiro dia. Conforme a empresa cresce, o site de marketing pode depois precisar de um blog com roteamento de SEO dinâmico que ultrapassa o CMS do Framer, e nesse ponto é razoável migrar só essa peça pra mesma base de código do produto — enquanto o resto das páginas de marketing pode continuar onde está, porque ainda não precisa disso.
8. Um checklist de decisão
Prefira Framer se: o conteúdo da página muda com mais frequência que a lógica dela, um não-engenheiro precisa publicar a maioria das mudanças, e não há comportamento de backend significativo além de envio de formulário ou integrações simples.
Prefira código se: a página precisa de autenticação, um banco de dados real com regras de negócio, integração profunda com uma base de código existente, ou controle preciso de performance e tamanho de bundle.
Prefira híbrido se: você está construindo uma empresa de produto típica — a resposta é quase sempre "os dois", divididos na fronteira site-de-marketing/aplicação-de-produto descrita acima, não uma ferramenta só pra tudo.
O erro a evitar é tratar isso como uma escolha única, da empresa inteira e ideológica ("somos uma empresa de código" ou "somos no-code"). A unidade certa de decisão é a página ou funcionalidade individual, avaliada pela quantidade de lógica real que ela carrega — não a cultura de engenharia da empresa como um todo.