Brightfield Solar: página de cidade para instaladora solar, com simulador

Projeto conceitual desenvolvido pela ALB Seven. A Brightfield Solar não é um cliente real: a instaladora, as equipes, os depoimentos e os números de confiança exibidos na página (avaliação, casas instaladas, prazo de licença) são fictícios, e o rodapé do próprio site diz isso. O que existe de concreto é a página em si, escrita em inglês para o mercado americano e publicada em brightfield.albseven.com com noindex, para não concorrer com nenhum site real.

O problema do setor

Instaladora de energia solar vende por cidade: a conta de luz, a tarifa da concessionária, as horas de sol e o prazo da licença municipal mudam de um lugar para outro, e o cliente pesquisa "quantos painéis preciso em Phoenix", não "energia solar" em geral. A resposta comum são páginas genéricas com um número de economia tirado do ar e um formulário no fim. Aqui o exercício foi outro: uma única página de cidade, com um modelo e um arquivo de dados por cidade, que mostra a conta inteira em vez de pedir confiança.

As decisões de projeto

• Uma função de cálculo para a página inteira. Painéis, preço após o crédito federal, economia mensal e prazo de retorno saem de uma função pura, usada pelo simulador, pelo FAQ, pelos metadados e pela tabela de preços por tamanho de sistema. As respostas do FAQ usam variáveis no lugar de números fixos, então nada na página pode discordar do simulador.
• Conteúdo por arquivo de dados. Tarifa, horas de sol, bairros, equipes, depoimentos e perguntas ficam em data/cities/phoenix-az.json, validado com Zod. Trocar o arquivo troca a página; um campo inválido derruba o build e aponta o arquivo e o campo.
• Tudo que é citável está no HTML do servidor. Hero, etapas, equipes, depoimentos, FAQ em details e até o resultado padrão do simulador, escrito como frase. A interatividade entra por cima, com controles deslizantes e perfis de casa que reiniciam a cobertura em 80%.
• O simulador mostra a conta. Além dos quatro números, a página desenha o telhado com um retângulo por painel, as linhas de preço, a barra da conta de luz e cada passo da matemática, do consumo em kWh ao prazo de retorno.
• Funil que termina em pedido, sem backend. A rota /schedule traz um formulário curto (nome, telefone, bairro, horário) validado no servidor com Zod, com erro por campo e foco no primeiro erro. A simulação e a atribuição de campanha (UTM, gclid, fbclid, primeiro toque) seguem junto no pedido, gravado no log do servidor. Sem banco e sem e-mail, por escolha do brief.
• Design refeito depois de uma primeira versão genérica. Ilustração em SVG, três cards iguais por seção e caixas de números deram lugar a fotografia em tela cheia, linhas com régua, um só acento de cor sobre neutros, uma família tipográfica com algarismos tabulares e um único raio de borda. Todas as animações desligam com "reduzir movimento".

Stack

Next.js (App Router), React, TypeScript, SCSS com CSS Modules e tokens em _tokens.scss, Motion, Phosphor Icons, Zod e Vitest. Sitemap, robots, imagem Open Graph e dados estruturados são gerados por rota; o JSON-LD não traz aggregateRating porque os dados não têm contagem de avaliações, e inventar uma seria afirmação falsa.

O que isso demonstra

Que uma landing page de conversão pode ser honesta com a conta e, ainda assim, ter hero, estrutura de prova social e chamada para ação no lugar certo. A empresa e os números são fictícios; o modelo de página por cidade, a função de cálculo e o fluxo de pedido, não.