O que o nosso desenvolvimento de sites inclui
O desenvolvimento pode seguir o web design da própria Dardo ou partir de layouts fornecidos pela sua equipe ou por outro estúdio. Em ambos os casos, a proposta lista os templates, estados e integrações que serão construídos, quem fornece cada insumo e como cada parte é aprovada.
- Implementação de frontend responsivo de todos os templates e estados combinados
- Modelo de conteúdo, configuração do CMS e fluxo de publicação
- Formulários e integrações combinadas, testados com envios reais
- Metadados, dados estruturados e estrutura de páginas rastreável
- Verificações de acessibilidade e desempenho em páginas representativas
- Verificações de lançamento, deploy e documentação de entrega
Quando o desenvolvimento web é o melhor ponto de partida
Comece por aqui quando o design já está aprovado, ou quase, e o risco está na construção: conteúdo que sua equipe precisa publicar, dados vindos de outro sistema, um formulário que precisa chegar à pessoa certa ou o desempenho em celulares reais. Traga os layouts, um inventário de páginas e uma lista de integrações. Um site institucional, um painel com login e um sistema de transações têm critérios de aceite diferentes, por isso os definimos antes de estimar.
Se você ainda não tem layouts, comece pelo web design personalizado, que cobre as duas etapas. Se o briefing é guiado por animação, WebGL ou 3D, o desenvolvimento criativo é mais indicado. E se o escopo principal for um produto complexo com login ou um longo programa de integração corporativa, uma equipe maior de aplicações pode atender melhor; avisaremos logo no início.
A stack com a qual desenvolvemos
Escolhemos a stack em cada projeto e explicamos a escolha na proposta. Nossos trabalhos publicados usam Astro e Next.js com TypeScript, com deploy em Cloudflare Workers ou Vercel. Para sites institucionais focados em conteúdo, o Astro é uma ótima opção: as páginas são geradas em HTML com antecedência e o JavaScript é enviado apenas para os componentes que precisam, o que deixa as páginas leves e fáceis de ler pelos buscadores. O Next.js é mais adequado para interfaces que se comportam como um aplicativo.
Quando um site precisa de lógica de servidor, como pagamentos, contas ou dados de outro serviço, nós a adicionamos onde é necessária, em vez de transformar cada página em um app. O Superame, um ranking público de projetos feito com Astro, guarda sua classificação em um banco de dados Neon e envia os compradores para um checkout hospedado; o servidor verifica cada callback de pagamento assinado antes de adicionar crédito. Se sua equipe precisa continuar em um CMS ou plataforma específica, informe no briefing e confirmaremos, antes de orçar, se somos a equipe certa para isso.
Um CMS que sua equipe realmente consegue usar
Um sistema de gerenciamento de conteúdo só ajuda se seus campos refletirem a forma como sua equipe publica. Antes de construir, mapeamos cada tipo de conteúdo, quem edita cada campo, o que precisa de aprovação e quais páginas têm layout fixo e quais são entradas reutilizáveis. No A medio tono, programas e professores são entradas editáveis, e não páginas feitas à mão, e o link de um curso abre um diretório de professores já filtrado por aquele instrumento.
O site da própria Dardo funciona da mesma forma: as páginas são um build estático em Astro servido pela Cloudflare, os artigos são escritos em um CMS headless separado e a publicação de um artigo dispara um novo build. O resultado estático mantém a hospedagem simples e as páginas rápidas, e os editores nunca precisam mexer no código.
Integrações, formulários e desempenho
A construção começa com um inventário de rotas e um mapa de integrações: o que cada formulário ou API deve fazer, quais contas de terceiros precisam estar em seu nome e o que o visitante vê quando um serviço está lento ou falha. Um frontend bem acabado pode esconder um fluxo de solicitações indefinido, por isso, antes do lançamento, enviamos testes reais e confirmamos que chegam ao destino certo.
O desempenho faz parte do aceite, não é um detalhe de última hora. Combinamos os templates e dispositivos a testar e verificamos o comportamento de carregamento e o peso das páginas antes da publicação. O A medio tono usa Vercel Analytics e Speed Insights em produção, e a implementação do Janus Observatory inclui limites de bundle e QA em navegadores, com um fluxo de release que verifica o build e regressões visuais.
Sites para várias unidades e franquias
Empresas com vários escritórios, clínicas, lojas ou franqueados precisam de um único sistema de marca e de um único modelo de conteúdo, com uma página de verdade para cada unidade: endereço, horários, equipe, serviços, fotos e a forma de falar diretamente com aquele local. A matriz controla as páginas compartilhadas e a marca; cada unidade edita apenas as próprias informações, com perfis de acesso que mantêm as duas coisas separadas.
O Google pede um Perfil da Empresa por unidade e uma página do site que represente essa unidade, e recomenda marcar cada unidade separadamente, com seu próprio URL. É assim que construímos as páginas de unidades e os dados estruturados. Não clonamos páginas de cidades onde você não tem escritório, porque páginas que só trocam o nome do lugar são tratadas como doorway pages.
Como testamos antes do lançamento
Uma página representativa é construída e testada nos tamanhos de tela combinados antes de concluir os demais templates, para que os problemas apareçam enquanto ainda são baratos de corrigir. O aceite inclui:
- Uso do teclado e foco visível
- Conteúdo longo, curto e ausente sem quebrar o layout
- Estados de carregamento, vazio e erro, e movimento reduzido onde há animação
- Entrega dos formulários ao destino real, com mensagem de confirmação
- URLs canônicos, redirecionamentos, metadados e dados estruturados
- Eventos de analytics, comportamento de consentimento e integrações em produção
Quem é o dono do código e o que você recebe na entrega
A entrega nomeia o repositório, a hospedagem, os domínios, o CMS, as credenciais, a documentação e o responsável pela manutenção, para que o site continue operável após o lançamento. Preferimos hospedagem e contas sob controle do cliente sempre que a plataforma permitir, e a proposta define a titularidade do código, dos ativos de design e de quaisquer dependências licenciadas antes do início do trabalho.
Uma equipe nearshore no seu fuso horário
A Dardo é uma equipe de três pessoas em Bogotá, liderada pelo fundador Nicolás Cerón, então você fala diretamente com quem escreve o seu código. Bogotá está em UTC−5 o ano todo, o que coincide com o horário Central dos EUA durante o horário de verão e com o horário do Leste dos EUA no resto do ano, deixando reuniões, revisões e dias de lançamento dentro do seu expediente normal. As faixas de orçamento do formulário de contato vão de menos de USD 5.000 a mais de 60.000, para você nos mostrar onde o seu projeto se encaixa.
Dúvidas antes de escolher
Quanto custa o desenvolvimento de um site?
Depende do trabalho: número de templates e estados, migração de conteúdo, requisitos de CMS, integrações, idiomas, acessibilidade, animação, testes e entrega. Precificamos o escopo documentado depois de analisar essas dependências, em vez de usar um valor universal por página, e a proposta separa os custos únicos de desenvolvimento das taxas recorrentes de hospedagem e software.
Qual é a diferença entre web design e desenvolvimento web?
O web design decide o que o site diz, como ele se organiza e qual é sua aparência e comportamento. O desenvolvimento web transforma essas decisões em código funcional: templates, gerenciamento de conteúdo, formulários, integrações, desempenho e deploy. Muitos problemas ficam entre os dois, como um layout que quebra com conteúdo real ou um formulário sem estado de erro, e por isso a Dardo mantém os dois na mesma equipe ou revisa designs externos antes de desenvolver.
Vocês desenvolvem a partir de layouts que já temos?
Sim. Primeiro revisamos os layouts quanto a estados responsivos, extremos de conteúdo, interações e comportamentos de carregamento ou erro que estejam faltando, e então combinamos o aceite da implementação com o responsável pelo design. As lacunas são listadas antes da estimativa, para que ninguém descubra no meio do projeto que um estado nunca foi desenhado. Se os layouts precisarem de um trabalho significativo, definimos esse escopo à parte em vez de improvisar no código.
Qual CMS vocês usam?
Depende de quem publica, com que frequência e que tipo de conteúdo. Para sites focados em conteúdo, um build estático em Astro combinado com um CMS headless funciona bem: os editores escrevem em uma interface editorial e a publicação dispara uma nova compilação. Quando o site se aproxima de uma aplicação, o conteúdo pode ficar no próprio banco de dados do app. A proposta indica o CMS, explica por que ele se encaixa e lista qualquer custo de licença ou assinatura.
Quando vocês usam Astro em vez de Next.js?
Usamos Astro quando a maioria das páginas é conteúdo que pode ser renderizado com antecedência, como sites institucionais, publicações e páginas de serviços, porque ele envia pouco ou nenhum JavaScript por padrão. O Next.js é indicado quando boa parte da interface se comporta como uma aplicação. Os dois aparecem em nossos trabalhos publicados: o site da própria Dardo e o Superame rodam em Astro, enquanto A medio tono e Janus Observatory usam Next.js.
De quem é o código quando o projeto termina?
A proposta define a titularidade do código, dos ativos de design, das contas e das dependências licenciadas antes do início do trabalho. Preferimos que hospedagem, domínios e repositório fiquem sob o seu controle desde o começo, com acessos documentados, para que outra equipe possa continuar sem reconstruir nada. Fontes, serviços ou plugins de terceiros permanecem sob suas próprias licenças, que listamos para que nada o surpreenda após o lançamento.
Vocês fazem a manutenção dos sites após o lançamento?
Pode ser incluída. Se a Dardo continuar dando suporte ao site, a proposta define o que a manutenção cobre, como atualizações, correções e pequenas alterações, e como as solicitações são tratadas. Se não, você recebe o repositório, a documentação e as contas de que sua equipe ou outro desenvolvedor precisa para assumir. De qualquer forma, a titularidade é resolvida antes do lançamento, não negociada depois.
Quanto tempo leva o desenvolvimento de um site?
Depende do número de templates e estados, das integrações, da migração de conteúdo e da rapidez com que layouts e conteúdo são aprovados; por isso definimos o cronograma na proposta em vez de citar um prazo padrão. Desenvolver e testar primeiro uma página representativa dá às duas partes uma leitura concreta e antecipada do ritmo e da qualidade antes de construir os demais templates.
Vocês podem trabalhar junto com a nossa equipe interna?
Sim, com um escopo definido. Podemos desenvolver um site completo, implementar layouts dos seus próprios designers ou entregar layouts para os seus desenvolvedores construírem, com a divisão de responsabilidades registrada na proposta. Antes de começar, combinamos o repositório, o processo de revisão, os horários de reunião e quem aprova cada entrega, e trabalhamos em inglês ou espanhol em um fuso UTC−5 que se sobrepõe ao expediente dos EUA.
Fontes e leituras adicionais
Fontes desta página, com mais detalhes dos publicadores originais.
- Diretrizes do Perfil da Empresa no Googlesupport.google.com
- Google Search Central: dados estruturados de empresas locaisdevelopers.google.com
- Google Search Central: políticas de spam (abuso de páginas de entrada)developers.google.com
