Você pode trabalhar com o nosso WordPress site existente?

Sim, como um trabalho claramente separado. Nós por padrão construímos em nossa própria pilha porque é isso que podemos apoiar, mas muitas empresas têm um WordPress site que na maioria das vezes funciona e precisa ser resgatado em vez de substituído. Nós o auditaremos e lhe diremos honestamente se consertar ou substituir é o melhor investimento.

Você hospeda o site?

Por padrão, no mesmo Kubernetes cluster que executa nossa própria plataforma — e é por isso que podemos ser específicos sobre o tempo de atividade em vez de vagos. Você não está preso.O site é um repositório e uma imagem de contêiner; ele pode ser implantado em qualquer lugar que execute qualquer um, e a documentação de entrega diz como.

Funcionará com KamoCRM?

Formulários no CRM, rastreamento que sobrevive à visita, chat ao vivo, reservas, um portal de clientes — tudo isso é construído em vez de ser aparafusado, porque escrevemos as duas extremidades. Se você não é um cliente KamoCRM, não faz diferença para o site que construímos para você.

Quanto tempo demora um site?

Um site de marketing focado geralmente leva de seis a dez semanas a partir do primeiro workshop, e a maior variável é o conteúdo, não o código. Um site com uma aplicação por trás dele, ou um que envia em vários idiomas, dura mais tempo.

Nós fazemos, quando a alternativa é um site que nunca é lançado porque ninguém escreveu a página quatro. Nós preferimos trabalhar com o seu material e moldá-lo do que inventar uma voz para o seu negócio. Portanto, o arranjo usual é que você fornece a substância e nós fazemos a estrutura e as palavras.

Um site é um software. O nosso é construído como ele.

A maioria dos sites são montados a partir de um tema e uma lista de plugins, e depois degradam-se silenciosamente.Nós projetamos e desenvolvemos sites da maneira que construímos os nossos próprios - com um orçamento de acessibilidade, um orçamento de desempenho e uma compilação que falha quando alguém quebra qualquer um.

A razão pela qual tantos sites de negócios são lentos, inacessíveis e impossíveis de mudar não é que os designers são descuidados. É que o site foi montado em vez de construído. Um tema, um construtor de páginas, onze plugins e uma camada de cache para esconder o que os outros treze estão fazendo.

Tratamos um site como um software com um público, o que significa controle de versão, uma compilação real, verificações automatizadas que falham em vez de avisar, e orçamentos de desempenho e acessibilidade que a compilação impõe. Este site é o exemplo: sua compilação se recusa a ser concluída se uma página estiver faltando no sitemap, se uma chave de tradução não for resolvida, se um preço não puder ser verificado contra o catálogo ao vivo ou se uma animação de entrada for lenta o suficiente para ser lida como uma página estagnada.

Design e engenharia não são compras separadas aqui. Uma página bonita que leva quatro segundos para se tornar interativa em um telefone não é uma página bonita – é uma foto de uma.O trabalho é fazer algo que seja genuinamente bonito e genuinamente rápido ao mesmo tempo, no dispositivo que seus clientes realmente têm.

O que geralmente acontece e o que fazemos em vez disso.
O arranjo usual	Como trabalhamos
Baseia-se em um tema e uma pilha de plugins	Construído em um framework, com cada dependência escolhida deliberadamente
Verifica se o site parece certo em um navegador de desktop	Impõe orçamentos de desempenho e acessibilidade no próprio build
Trata a acessibilidade como um widget de sobreposição de conformidade	Compilações para WCAG com testes reais de teclado e leitor de tela
Entrega um login e um retentor de manutenção que você não pode deixar	Entrega um repositório que qualquer pessoa competente pode pegar
Reconstruído do zero a cada três anos	Constrói algo que pode ser mudado em vez de substituído

O que você realmente obtém

Design feito contra o conteúdo real, não preenchimento — o conteúdo é parte do trabalho
Uma biblioteca de componentes, para que o site possa crescer sem um redesign
Acessibilidade para WCAG 2.2 AA, testado com um teclado e um leitor de tela, não apenas um scanner
Core Web Vitals medidos em dispositivos reais e mantidos dentro de um orçamento imposto pela compilação
Dados estruturados, regras canônicas e sitemaps corretos no dia do lançamento
O repositório, o pipeline de implantação e a documentação são seus