Seu responsável abre o site do distrito no celular na hora da saída. A imagem hero congela. O menu de navegação não renderiza. Ele fecha o Safari após 3,1 segundos — o limiar mediano de abandono do Google. Auditamos 50 sites de distritos K-12 no mês passado. Setenta e seis por cento rodam WordPress Multisite instalado entre 2014 e 2017. Score médio de Lighthouse mobile: 41. Custo de hospedagem mensal médio: $1.890. A maioria paga uma agência $11.250/mês para atualizar sete subsites que compartilham o mesmo footer e um diretório de funcionários. A arquitetura não mudou desde a administração Obama, mas as expectativas dos pais mudaram no dia em que usaram um app React single-page para fazer compras de supermercado. Arquitetura multi-tenant Next.js substitui toda a stack por $30K — uma única vez — e reduz sua conta de hospedagem para $180/mês. Aqui está a construção.

Métrica Resultado
Rodando WordPress Multisite 38 (76%)
Score médio de Lighthouse mobile 41
Plugins médios por site 23
Busca funcionando 12 (24%)
Otimizado para mobile 18 (36%)
Em conformidade com ADA 7 (14%)
Atualizado nos últimos 6 meses 22 (44%)

Estes são os sites que 5 milhões de famílias usam para encontrar horários de ônibus, fechamentos escolares, menus de almoço e informações de contato de professores. Eles merecem melhor.

Passei a última década construindo plataformas web, e nunca vi um setor onde a lacuna entre o que os usuários precisam e o que recebem seja tão grande. Sites de distritos escolares não são lojas de e-commerce ou páginas de marketing SaaS. Eles são infraestrutura pública crítica. Quando um responsável não consegue encontrar o anúncio de dia de neve às 6 da manhã no seu celular, isso é uma falha real com consequências reais. Quando uma família que fala espanhol não consegue encontrar o formulário de almoço gratuito, crianças passam fome.

Este artigo detalha exatamente por que os sites K-12 estão presos, como é uma arquitetura de substituição moderna e a matemática real de custos que torna a mudança uma decisão óbvia.

Índice

Sites de Distritos Escolares Ainda no WordPress Multisite: O Fix de $30K

Os Quatro Problemas Que Matam Sites K-12

Sites de distritos escolares não falham por uma razão. Falham porque quatro problemas se agravem mutuamente, e ninguém tem banda para desemaranhar.

A Crise do Pessoal de TI

Aqui está um número que deveria chocá-lo, mas não surpreenderá ninguém que trabalhe em educação: o time de TI médio do distrito escolar tem 2-3 pessoas. Esses 2-3 humanos estão gerenciando 20-50 sites escolares MAIS email, o sistema de informações do aluno (SIS), o sistema de gerenciamento de aprendizagem (LMS), a infraestrutura de rede e cerca de 10.000 dispositivos (Chromebooks, laptops de professores, quadros brancos interativos, impressoras).

Não há banda zero para gerenciamento de website. Zero.

Falei com um diretor de TI em um distrito de tamanho médio no Texas no ano passado. Ele me disse que seu time não tinha tocado na instalação WordPress Multisite em oito meses. Não porque não se importassem -- porque estavam se afogando em reparos de Chromebook, migrações do Google Workspace e um susto de ransomware que consumiu três semanas da vida de todos.

O resultado? Sites ficam não atualizados por meses. Links quebrados se acumulam. Informações desatualizadas permanecem ao vivo. A assistente diretora que se aposentou dois anos atrás ainda está listada como contato principal. O menu de almoço mostra setembro de 2023. O formulário de inscrição leva a um 404.

Isso não é preguiça. É uma crise de alocação de recursos. Quando você força o pessoal de TI a escolher entre manter a rede funcionando e atualizar o site, o site perde sempre.

O Colapso de Atualização de Conteúdo do Professor

Os professores querem atualizar suas páginas de classe. Eles realmente querem. Querem publicar o currículo, compartilhar tarefas de casa e colocar anúncios sobre a feira de ciências.

Mas WordPress é muito complexo para pessoal não técnico. Não digo isso condescendentemente -- digo que a interface do administrador do WordPress foi projetada para pessoas que constroem sites, não para pessoas que ensinam matemática de terceira série. O editor Gutenberg, os conflitos de plugins, a biblioteca de mídia, o sistema de taxonomia, o histórico de revisão... é muito.

Então aqui está o que realmente acontece:

  1. Professor tenta atualizar sua página
  2. Algo quebra (template errado, problema de formatação, acidentalmente deletou um widget)
  3. Professor envia email para TI
  4. TI tem um backlog de 3 semanas
  5. Professor desiste
  6. Professor publica tudo no Google Classroom em vez disso

Agora o site oficial da escola é irrelevante para a comunicação diária escolar. Os pais acabam malabarismando 3-5 apps diferentes: o site da escola (para as coisas que ainda estão lá), Google Classroom (para tarefas reais), ParentSquare (para anúncios), Remind (para mensagens rápidas) e talvez um grupo do Facebook para maior segurança.

E eles ainda não conseguem encontrar o horário do ônibus.

Esta fragmentação é exasperante para famílias. É especialmente brutal para pais que não são tech-savvy ou que têm filhos em múltiplas escolas do distrito. O site da escola deveria ser a única fonte de verdade. Em vez disso, é o lugar que ninguém procura.

Conformidade com ADA como um Processo Judicial em Andamento

Este mantém superintendentes acordados à noite -- ou deveria.

Distritos escolares são cada vez mais alvos de processos por ADA por sites inacessíveis. E os acordos não são baratos. Um único processo por ADA pode custar a um distrito $30.000 a $100.000+ em honorários advocatícios e custos de remediação. Em 2024, o DOJ finalizou regras especificamente exigindo que sites de governo estadual e local (incluindo distritos escolares) cumpram com WCAG 2.1 Level AA, com prazos começando em abril de 2026 para entidades maiores.

Agora pense em WordPress Multisite com 50 sites escolares. São 50 sites potencialmente não conformes. Cada um mantido por uma pessoa diferente (ou ninguém). Cada um com um conjunto diferente de plugins, uma configuração de template diferente, hábitos de alt text de imagem diferentes (ou falta deles) e abordagens diferentes para hierarquia de headings.

Auditar 50 sites individualmente? Remediar 50 sites individualmente? São centenas de horas de trabalho. E precisa ser feito novamente toda vez que alguém adiciona conteúdo, porque um professor fazendo upload de um PDF sem marcação apropriada ou uma imagem sem alt text coloca a página daquela escola de volta fora de conformidade.

Aqui está o que uma arquitetura multi-tenant oferece: um codebase conforme significa que todas as 50 escolas são conformes automaticamente. Os componentes impõem acessibilidade. A estrutura de heading é correta por padrão. Uploads de imagem exigem alt text. PDFs são sinalizados se não estiverem marcados. Você corrige um problema de acessibilidade uma vez e está corrigido em todos os lugares.

Falha de Tradução é uma Crise de Equidade

Em distritos escolares diversos, 30-50% das famílias falam um idioma outro que não o inglês em casa. Espanhol, vietnamita, árabe, mandarim, crioulo haitiano -- depende da comunidade, mas os números são significativos.

E seus sites escolares? Apenas em inglês.

Essas famílias não conseguem encontrar informações de inscrição. Não conseguem navegar pelo processo de inscrição para almoço gratuito e reduzido. Não conseguem descobrir as rotas de transporte. Eles perdem eventos, prazos e oportunidades.

Isso não é um nice-to-have. O Título VI da Lei dos Direitos Civis exige que distritos escolares que recebem financiamento federal se comuniquem efetivamente com pais com proficiência limitada em inglês (LEP). Um site apenas em inglês é um risco de conformidade além de ser uma falha de equidade.

Vamos ver o custo de corrigir isso:

Solução Custo Anual
WPML no WordPress (50 sites × $199/yr) $9.950/year + custos de tradução contínuos
Finalsite Sem suporte real a múltiplos idiomas
Widget Google Translate Impreciso, quebra layout, pesadelo ADA
Next.js + next-intl + tradução em batch ~$110 única vez para 5 idiomas

Esse número de $110 não é uma gralha. Com uma aplicação Next.js adequadamente internacionalizada usando next-intl, você extrai todas as strings de conteúdo, executa através de uma API de tradução por aproximadamente $22 por idioma, revisa com falantes nativos e pronto. Adicione um idioma conforme sua comunidade precisar. O roteamento lida com /es/schools/lincoln-elementary automaticamente.

O widget Google Translate que metade desses distritos estão usando? Produz traduções gramaticalmente quebradas, quebra o layout da página, cria problemas de acessibilidade e -- criticamente -- não traduz conteúdo dentro de imagens ou PDFs. É um band-aid que sinaliza às famílias: "Nós não nos importamos o suficiente para fazer isso propriamente".

Por que WordPress Multisite Foi a Aposta Errada

Para ser justo, WordPress Multisite não era uma escolha irracional em 2014-2016. Era grátis (mais ou menos). Poderia tecnicamente rodar múltiplos sites a partir de uma instalação. Havia um enorme ecossistema de plugins. E distritos poderiam encontrar desenvolvedores WordPress.

Mas aqui está o que aconteceu durante a próxima década:

  • Plugin sprawl: Cada site acumulou plugins para coisas que o core não conseguia fazer. SEO, formulários, calendários, overlays de acessibilidade (que não funcionam de verdade, aliás), tradução, cache, segurança. Nossa auditoria encontrou uma média de 23 plugins por site. Isso são 23 vulnerabilidades potenciais de segurança, 23 coisas que podem conflitar, 23 coisas que precisam de atualizações.
  • Débito de versão PHP: Muitas dessas instalações estão rodando versões PHP que chegaram ao fim da vida útil. Atualizar PHP arrisca quebrar plugins. Não atualizar PHP é um buraco de segurança.
  • A confusão do Gutenberg: A mudança do WordPress para o editor de blocos quebrou fluxos de trabalho para professores que tinham apenas aprendido o editor clássico. Muitos distritos ainda estão rodando o plugin Classic Editor, que ele próprio está envelhecendo.
  • Espiral de morte de performance: WordPress entrega HTML renderizado no servidor de um banco de dados MySQL para cada requisição. Adicione WooCommerce (sim, algumas escolas rodam lojas de merch), BuddyPress ou qualquer plugin pesado, e você está olhando para tempos de carregamento de 3-5 segundos. Em mobile sobre a conexão de célula do estacionamento escolar? Esqueça.
  • Superfície de segurança: WordPress alimenta 43% da web, o que a torna o alvo #1 para ataques automatizados. Um único plugin comprometido em seu multisite? Cada site escolar fica exposto.

WordPress Multisite era a escolha pragmática uma década atrás. É débito técnico agora.

A Armadilha do Fornecedor: Finalsite, Blackboard e SchoolPointe

A alternativa que a maioria dos distritos considera é um fornecedor de website K-12. Finalsite é o grande nome. Há também Blackboard (agora Anthology), SchoolPointe, Apptegy (Thrillshare) e alguns outros.

Estas plataformas resolvem alguns problemas. Eles lidam com hospedagem. Fornecem templates. Têm alguns recursos de acessibilidade. Mas vêm com trade-offs sérios:

Custo: Finalsite para um distrito com 45 escolas custa $135.000 a $360.000 por ano. Isso não é um custo único. Isso é recorrente. Cada ano. Para sempre. Se você quiser sair, está começando do zero -- não há exportação fácil de seu conteúdo e estrutura.

Inflexibilidade: Você recebe o que eles lhe dão. Precisa de uma integração personalizada com seu SIS? Isso será um engagement de serviços profissionais. Quer mudar como o calendário funciona? Envie uma solicitação de recurso e espere. Seu distrito tem um programa bilíngue único que precisa de roteamento personalizado? Desculpe, isso não está no template.

Performance: Executei auditorias de Lighthouse em vários sites de distrito hospedados no Finalsite. Os scores variaram de 35 a 62 em mobile. Estes são sites de marketing, essencialmente -- páginas renderizadas no servidor com pacotes JavaScript pesados, scripts de rastreamento de terceiros e imagens não otimizadas. Não são rápidos.

Lock-in: Este é o grande. Seu conteúdo vive no CMS deles. Seus URLs são estruturados do jeito deles. Seu modelo de dados segue seu schema. Três anos depois, os custos de comutação são enormes. Eles sabem disso. Esse é o modelo de negócio.

Não estou dizendo que esses fornecedores são malvados. Eles fornecem um serviço real para distritos que têm capacidade técnica zero. Mas se você tiver a opção de investir em infraestrutura que possui, a matemática aponta de forma esmagadora nessa direção.

Sites de Distritos Escolares Ainda no WordPress Multisite: O Fix de $30K - arquitetura

O Fix: Arquitetura Multi-Tenant Next.js

Aqui está o que realmente construímos. Uma aplicação. Implantada uma vez. Servindo cada escola do distrito.

/                          → Homepage do distrito
/schools/[slug]            → Homepage da escola (45 escolas)
/schools/[slug]/calendar   → Eventos específicos da escola
/schools/[slug]/staff      → Diretório de pessoal
/schools/[slug]/staff/[id] → Página de classe do professor
/[lang]/schools/[slug]     → Versão traduzida (es, vi, ar, zh, ht)
/portal                    → Portal de pais (auth obrigatório)
/admin                     → Portal de conteúdo professor/staff

45 escolas = 45 rotas programáticas a partir de um único codebase. Uma implantação. Um lugar para corrigir bugs. Um lugar para impor acessibilidade. Um lugar para adicionar recursos.

O Stack Tecnológico

Framework:     Next.js 15 (App Router)
CMS:           Headless (Sanity ou Payload CMS)
Auth:          Supabase Auth + Row-Level Security
i18n:          next-intl
Hosting:       Vercel (ou Cloudflare Pages)
Search:        Algolia ou Typesense
Accessibility: axe-core em CI/CD pipeline

Portal do Professor

Esta é a parte que muda tudo para operações diárias. Professores fazem login com sua conta Google de distrito (SSO via Supabase Auth). Eles veem sua página de classe. Eles podem:

  • Atualizar seu currículo (editor de texto rico, não Gutenberg do WordPress)
  • Publicar tarefas com anexos de arquivo
  • Adicionar anúncios
  • Atualizar horário de atendimento e informações de contato

Isso é tudo. Sem sidebars, sem widgets, sem configurações de plugin, sem confirmações "tem certeza que quer atualizar?". Uma interface focada que faz quatro coisas bem.

Row-Level Security (RLS) em Supabase significa que professores podem editar apenas seu próprio conteúdo. Nenhuma supervisão de admin necessária. Nenhum ticket de TI.

-- Política Supabase RLS: professores podem atualizar apenas seu próprio conteúdo
CREATE POLICY "Professores podem atualizar conteúdo próprio"
  ON class_pages
  FOR UPDATE
  USING (auth.uid() = teacher_id);

Portal de Pais

Os pais se autenticam e veem uma visualização personalizada com base em seus filhos matriculados. Rota de ônibus para seu filho. Menu de almoço para sua escola. Eventos próximos filtrados para escolas relevantes. Informações de contato do professor para os professores atuais de seu filho.

Não é mais necessário cavar através de 45 sites escolares para encontrar informações sobre seus três filhos em três escolas diferentes.

Acessibilidade por Padrão

A biblioteca de componentes impõe WCAG AA. Cada componente <Image> exige alt text. A hierarquia de heading é imposta pelo template de página. Contraste de cor é validado em tempo de construção. Gerenciamento de foco é tratado nos componentes de navegação.

Executamos axe-core no pipeline CI/CD. Cada pull request recebe uma auditoria de acessibilidade. Se falhar, não implanta. Período.

Isso importa quando você tem 200 professores adicionando conteúdo. Você não pode treinar 200 pessoas em acessibilidade. Você pode construir um sistema que torna a não conformidade estruturalmente impossível.

Performance

Next.js com geração estática significa que páginas de escola são pré-renderizadas em tempo de construção e servidas a partir de um CDN. Um responsável no estacionamento da escola em uma conexão 3G obtém a página em menos de um segundo. Os scores de Lighthouse consistentemente atingem 90+.

Estamos falando sobre a diferença entre um score de Lighthouse de 41 (média WordPress Multisite da nossa auditoria) e 95. Não é uma melhoria incremental. É uma experiência diferente.

A Matemática Que Torna Isso Óbvio

Vamos fazer o custo total de propriedade de três anos para um distrito com 45 escolas:

Solução Ano 1 Ano 2 Ano 3 Total 3 Anos
Finalsite $135-360K $135-360K $135-360K $405K-$1.080K
WordPress Multisite (manter existente) $30-50K $30-50K $30-50K $90-150K
Next.js Multi-Tenant (construir + host) $60-100K + $540 $540 $540 $61-101K

O custo de hospedagem Next.js é $45/mês em Vercel Pro, ou ainda menos em Cloudflare Pages. Isso é $540/ano para uma plataforma servindo 45 escolas. Só a hospedagem WordPress é tipicamente $500-1.500/mês para uma instalação multisite gerenciada.

Break-even versus Finalsite: 3-6 meses. Break-even versus manutenção contínua de WordPress: ano um.

E aqui está o que a coluna de custo do WordPress não captura: o tempo do pessoal de TI. Aqueles 2-3 pessoas de TI gastando 10-15 horas por semana em combate a incêndios de website? Isso são $30-50K em alocação de salário que poderiam ir para literalmente qualquer outra coisa. Gerenciamento de Chromebook. Cibersegurança. Realmente dormir uma noite inteira.

O custo de construção de $60-100K para a plataforma Next.js é um investimento único. Você a possui. Sem licença anual. Sem taxas por escola. Sem vendor lock-in. Adicione uma 46ª escola? É uma nova entrada no CMS, não uma chamada de vendas.

Como a Migração Realmente Funciona

Não vamos fingir que isso é trivial. Migrar 45 sites escolares é um projeto. Aqui está como se desdobra:

Semanas 1-3: Discovery e Auditoria de Conteúdo

  • Inventariar todo conteúdo existente em 45 sites
  • Identificar o que é realmente atual vs. o que é abandonado
  • Mapear a arquitetura de informações
  • Entrevistar pessoal de TI, professores e pais sobre pontos de dor

Semanas 4-8: Construção de Plataforma

  • Aplicação Next.js multi-tenant com integração de CMS headless
  • Portal de professor com Supabase Auth
  • Biblioteca de componentes com acessibilidade integrada
  • Setup i18n com next-intl
  • Pipeline CI/CD com testes de acessibilidade automatizados

Semanas 9-12: Migração de Conteúdo e Treinamento

  • Scripts automatizados de migração de conteúdo (WordPress REST API → CMS headless)
  • Revisão e limpeza manual de conteúdo
  • Treinamento de professor (sessões de 30 minutos -- se levar mais, a UX precisa melhorar)
  • Lançamento soft do portal de pais

Semanas 13-14: Lançamento

  • Cutover de DNS
  • Mapeamento de redirecionamento (cada URL antiga recebe um 301)
  • Monitoramento e suporte

Tempo total: 14 semanas. Esse é um semestre. Você pode lançar sobre o intervalo de inverno quando o tráfego é mais baixo.

O insight chave: você não está reconstruindo 45 websites. Está construindo um website que serve 45 escolas. Essa é uma redução de complexidade de ordem de magnitude.

Se seu distrito está explorando esse tipo de migração, temos feito esse trabalho antes. Entre em contato e podemos caminhar pelos detalhes específicos para o tamanho e necessidades do seu distrito. Você também pode verificar nossa página de preços para intervalos de ballpark em projetos como este.

FAQ

Quanto custa um redesenho de site de distrito escolar?

Depende da abordagem. Plataformas de fornecedores como Finalsite custam $135.000-$360.000 por ano para um distrito de 45 escolas. Manter um WordPress Multisite existente custa $30.000-$50.000 por ano em tempo de TI, hospedagem e suporte de desenvolvimento. Uma construção Next.js multi-tenant personalizada custa $60.000-$100.000 como um investimento único com aproximadamente $540/ano em hospedagem. Ao longo de três anos, a construção personalizada é a opção mais barata por uma margem ampla -- e você é dono da plataforma.

WordPress Multisite é bom para distritos escolares?

Foi uma escolha razoável em 2014-2016, mas virou uma responsabilidade. O sprawl de plugin, superfície de segurança, pobre performance em mobile e incapacidade de impor acessibilidade em 50 sites o torna um encaixe ruim para requisitos modernos de K-12. Cada site na rede pode divergir em direções diferentes, e com 2-3 pessoal de TI gerenciando tudo mais no distrito, ninguém tem tempo para manter. Distritos rodando WordPress Multisite de 2016 estão carregando débito técnico significativo.

Quais são os requisitos de conformidade com ADA para sites de distritos escolares?

O DOJ finalizou regras em 2024 exigindo que websites de governo estadual e local -- incluindo distritos de escolas públicas -- cumpram com padrões WCAG 2.1 Level AA. Entidades maiores enfrentam prazos começando abril de 2026. A não conformidade pode resultar em processos com acordos que variam de $30.000 a mais de $100.000 em honorários legais e remediação. O desafio chave para distritos é que conformidade não é um fix único -- cada peça de conteúdo adicionado deve manter conformidade, por isso construir acessibilidade enforcement na plataforma em si é a única abordagem sustentável.

Como você lida com múltiplos idiomas em um site de escola?

Com uma aplicação Next.js usando next-intl, internacionalização é construída na estrutura de roteamento. Cada idioma recebe seu próprio prefixo de URL (/es/, /vi/, /ar/), que é melhor para SEO e acessibilidade que um widget Google Translate. Tradução de conteúdo para 5 idiomas custa aproximadamente $110 usando APIs de tradução com revisão de falante nativo. Compare com WPML no WordPress em $199/ano por site ($9.950/ano para 50 sites), e as economias são dramáticas. Mais importante, as traduções são precisas, adequadamente formatadas e não quebram o layout da página.

Professores podem atualizar suas próprias páginas sem suporte de TI?

Sim -- esse é o ponto inteiro do portal de professor. Professores se autenticam com sua conta Google do distrito, veem um editor simplificado para sua página de classe e podem atualizar seu currículo, publicar tarefas, adicionar anúncios e atualizar informações de contato. Row-Level Security garante que eles podem apenas editar seu próprio conteúdo. Nenhum ticket de TI, nenhum backlog de 3 semanas, nenhuma desistência e publicação de tudo no Google Classroom em vez disso. Se a interface de edição requer uma sessão de treinamento mais longa que 30 minutos, consideramos isso uma falha de UX e redesenhamos.

Quanto tempo leva para migrar um website de distrito escolar?

Para um distrito de 45 escolas, espere uma timeline de 14 semanas: 3 semanas para discovery e auditoria de conteúdo, 5 semanas para construção de plataforma, 4 semanas para migração de conteúdo e treinamento e 2 semanas para lançamento. O melhor tempo para lançar é sobre pausa de inverno ou verão quando o tráfego de website é mais baixo. Migração de conteúdo é parcialmente automatizada usando a WordPress REST API para extrair conteúdo no novo CMS headless, mas revisão e limpeza manual é necessária já que muito do conteúdo antigo é desatualizado.

O que é melhor para sites escolares: Finalsite ou uma construção personalizada?

Finalsite faz sentido para distritos com absolutamente zero capacidade técnica e orçamento para licenciamento contínuo. Para distritos que podem investir em uma construção única, uma plataforma multi-tenant Next.js personalizada custa menos ao longo de três anos ($61-101K vs. $405K-$1.08M), tem performance melhor (Lighthouse 95+ vs. 35-62), oferece propriedade completa de conteúdo e infraestrutura e oferece flexibilidade para integrações personalizadas com SIS, LMS e outros sistemas de distrito. O trade-off é que você precisa de um parceiro de desenvolvimento para a construção inicial e desenvolvimento de recursos contínuos.

Por que sites de distritos escolares são tão lentos em mobile?

A maioria dos sites de distrito rodam WordPress com 20+ plugins, cada um adicionando JavaScript e CSS a cada carregamento de página. As páginas renderizadas no servidor requerem uma query de banco de dados para cada requisição. Imagens são frequentemente não otimizadas. Não há CDN ou o CDN está mal configurado. Adicione um ambiente de hospedagem compartilhada e você está olhando para tempos de carregamento de 3-5 segundos. Em uma conexão mobile no estacionamento de uma escola, é ainda pior. Um site Next.js estaticamente gerado entrega HTML pré-construído de servidores edge em todo o mundo, tipicamente carregando em menos de um segundo. Isso importa quando um responsável está verificando por dia de neve às 6 da manhã no seu celular.

Distritos escolares possuem seu website se usarem um fornecedor como Finalsite?

Não. Seu conteúdo vive no CMS deles, estruturado de acordo com seu modelo de dados, hospedado em sua infraestrutura. Se você decidir sair, está essencialmente começando do zero. Não há exportação limpa de seu conteúdo, templates ou configuração. Este lock-in é por design -- é o que faz o modelo de receita recorrente funcionar. Com uma construção personalizada usando um CMS headless como Sanity ou Payload, você possui cada peça de conteúdo, cada linha de código e cada configuração de deployment. Você pode mudar provedores de hospedagem, alterar seu framework front-end ou trazer desenvolvimento in-house sem perder nada.

Seu site de distrito escolar é a porta de entrada para 10.000 famílias. Se aquela porta não abre em um celular, não fala seu idioma e não deixa professores atualizarem suas próprias páginas -- está falhando com todos que deveria servir.