Três stacks que arrancámos em 2026: Webflow, Sanity, AWS
O que partiu, o que poupámos, o que faríamos outra vez. Três walkthroughs honestos de migração com horas e faturas anexas.
Cada estúdio tem um cemitério de fornecedores. O nosso encheu mais depressa do que a maioria porque aceitávamos projetos com qualquer stack que viesse com eles — e depois víamos a fatura no ano dois. Em 2026 limpámos três: Webflow num site de cliente, Sanity no nosso próprio CMS de produto, AWS em duas workloads de produção. Eis o que cada um custou e onde aterrámos.
1. Webflow → PHP custom
O site tinha três anos. Seis idiomas, um CMS que a equipa de marketing realmente usava, uma camada de interações custom soldada por cima. O Webflow cobrava €312/mês pelo workspace, a subir à medida que se adicionavam idiomas. Experiência de editor: boa. Experiência de developer: um trabalho de sábado.
O ponto de rutura não foi preço. Foi o export. O export HTML do Webflow servia para sites estáticos em 2017; em 2026 engasgava-se com CMS bindings e embeds dinâmicos. O cliente queria empurrar submissões de formulário para o HubSpot. Essa única integração obrigaria a sair do form handler do Webflow na mesma.
O que fizemos: Levantámos o design system tal e qual para um stack PHP simples. Cockpit CMS para editorial. Cloudflare para o CDN. Sem Next.js, sem React, sem build pipeline. Total de linhas do nosso código: abaixo de 2000.
Horas: 84 (um sénior + um mid, sprint de duas semanas).
Custo de switching poupado no ano dois: ~€3.700.
O que nos surpreendeu: A velocidade de edição da equipa de marketing subiu. O modelo i18n do Cockpit deixa-os duplicar um campo entre idiomas num clique; o CMS do Webflow obrigava-os a editar cada idioma à parte.
2. Sanity → Cockpit
Esta doeu mais, porque tínhamos escrito os schemas do Sanity. Gostávamos do Sanity. A edição colaborativa é genuinamente boa. O GROQ é genuinamente bom. O preço de 2026 genuinamente não é, se fores um produto B2B com milhares de seats de editor no horizonte.
O tier gratuito do Sanity é generoso para estúdios. O tier pago tem preço para media companies com VC. Não cabíamos em nenhuma das caixas.
O que fizemos: Migrámos para Cockpit v2 self-hosted numa VM pequena. Escrevemos um script one-shot que batia no endpoint de export do Sanity, mapeava o block content para o modelo do Cockpit, e fazia POST pelo REST do Cockpit. Tempo total incluindo QA: 11 horas.
Mudança de custo: €0/mês vs ~€240/mês projetado para o nosso número de seats.
O que perdemos: Edição colaborativa em tempo real. A equipa sentiu durante duas semanas. Depois disso, ninguém voltou a falar nisso. Trocámos a ansiedade social do "está mais alguém neste doc?" por um padrão simples de lock-on-open.
3. AWS → OVH
Não o stack inteiro. Duas workloads: um site de marketing por trás de CloudFront, e uma API Node pequena por trás de ALB + EC2. As duas juntas a faturar ~€180/mês. As duas em AWS porque alguém há três anos escreveu cdk deploy e não pensou mais nisso.
A AWS não é cara quando se usa bem. É cara quando se usa por defeito. CloudFront para um site estático com 40k visitas/mês é exagero a preço enterprise. EC2 para uma API Node que processa 200 pedidos/dia é desperdício de arredondamento — mas continua a ser desperdício.
O que fizemos: Site de marketing para shared hosting OVH + Cloudflare free tier. API Node reescrita em 90 linhas de PHP no mesmo plano OVH.
Fatura antes: €178/mês. Depois: €11/mês.
O que nos surpreendeu: A API Node tinha três dependências em chamadas do AWS SDK. As três foram substituídas por PHP nativo, um cron do OVH e um ficheiro de config. A reescrita foi mais rápida do que a auditoria de migração.
O que voltaríamos a fazer
- Começa pelo export. Antes de te comprometeres com um fornecedor, escreve o script que tira os teus dados de lá. Se não consegues escrevê-lo num dia, assinaste um acordo de refém.
- Olha para o ano dois. O ano um de qualquer SaaS tem preço para te apanhar. O ano dois tem preço para te manter. Faz essa conta à assinatura.
- "Shared hosting" não é "vergonha". Os custos de cloud em 2026 são 4–8× o equivalente em shared hosting. Para 80% dos sites de marketing, shared hosting não é só adequado — é o correto.
O que não migraríamos
Para equilibrar: não migrámos as nossas analytics do PostHog, nem migrámos os preview deployments do Vercel. O ponto não é que tudo é mais barato noutro lado. O ponto é que assumir por defeito uma cloud tier-1 para tudo porque foi isso que disseram nas conferências é como os estúdios acabam a pagar €18.000/ano em infra que poderiam substituir por €600.
Audita o teu stack uma vez por ano. Migra o que dói mais. Repete.