Perguntas frequentes

A MS WebX é uma empresa de tecnologia. Construímos sites e plataformas web, aplicativos nativos para iOS e Android e integramos IA a eles, junto com o trabalho de SEO que torna visível o que criamos. Também operamos produtos próprios na mesma plataforma que usamos com clientes, então a base já roda em produção antes de qualquer outra pessoa depender dela.

As duas coisas, de propósito. O que oferecemos roda primeiro nos nossos produtos: o sistema de páginas multilíngue, a camada de API, as ferramentas de administração, a analítica. Nenhum projeto de cliente começa sobre uma base não testada e, se algo no núcleo quebra, percebemos antes do cliente.

De três formas, todas independentes do que escrevemos aqui. A página de informações legais traz os dados oficiais da empresa. Nossos produtos são públicos e podem ser usados sem falar com a gente. E a página de contato chega às mesmas pessoas que escrevem o código, sem call center no meio.

Você descreve o objetivo, não a solução técnica. Perguntamos até o escopo ficar realmente claro e colocamos por escrito antes de construir qualquer coisa. Se acharmos que o caminho pedido é o errado, falamos antes de você pagar — essa conversa custa menos que o retrabalho que ela evita.

Em passos pequenos e visíveis. O trabalho vai para um ambiente de homologação que você pode abrir no navegador quando quiser e só vai para o ar quando você autorizar. Ninguém vê o produto pronto pela primeira vez no fim do projeto — aí qualquer mudança já sai cara.

O que construímos é feito para ser mantido: atualização de dependências, monitoramento e mudanças conforme o negócio muda. Se quem cuida disso somos nós ou o seu time fica combinado dentro do projeto, não presumido depois. Nada é construído de um jeito em que só nós conseguimos mexer.

Primeiro lemos o código existente e depois falamos com clareza se continuar ou substituir custa menos ao longo da vida do sistema. As duas respostas acontecem — código herdado costuma estar bem, só mal documentado. Não recomendamos refazer por reflexo, porque refazer é a coisa mais cara que alguém pode te vender.

PHP no servidor, TypeScript no navegador, Flutter para iOS e Android, MariaDB para os dados, nginx e FrankenPHP para servir. Tecnologia atual e bem conhecida de propósito, para que qualquer um consiga manter depois de nós. A qualidade é garantida por máquinas, não por boa vontade: a análise estática roda no nível mais rígido sem lista de exceções, com mais de duzentas regras próprias que barram o código assim que ele sai da linha.

Uma base de código com um núcleo comum e uma camada fina por marca em cima. Cada marca tem o próprio design, o próprio conteúdo, o próprio banco de dados e o próprio domínio, enquanto correções de segurança, trabalho de desempenho e novos recursos do núcleo chegam a todas ao mesmo tempo, sem cópia manual site a site. Acrescentar uma marca é configuração e conteúdo, não um fork.

Sim, e de um jeito mais rígido do que essa frase costuma indicar. A API é definida uma vez em PHP, e tanto o cliente TypeScript da web quanto o cliente Dart do app são gerados a partir dessa definição. Nenhum dos dois é escrito à mão: o linter recusa um tipo de API escrito manualmente. Assim o app não sai de sincronia no silêncio — a divergência quebra o build, não a produção.

De verdade. Cada página existe como registro próprio por idioma, com texto e URL próprios — este FAQ fica em /frequently-asked-questions em inglês e em /de/haeufig-gestellte-fragen em alemão, não atrás de um parâmetro de tradução. Assim cada idioma é escrito do jeito que as pessoas realmente buscam naquele mercado, e dá para corrigir um sem mexer nos outros dezessete.

É para isso que ela foi feita. Cada marca tem o próprio banco de dados, o próprio domínio e o próprio conteúdo, então uma marca não consegue ler os dados da outra e um erro de conteúdo em uma não aparece na outra. O que é compartilhado é o motor: roteamento, camada de API, ferramentas de administração e o trabalho de segurança.

O Cannabivo está no ar: um buscador de clubes sociais, em que os visitantes encontram e comparam clubes por localização e os clubes cuidam do próprio cadastro. O Steel é uma referência de equivalências de materiais voltada a engenharia e compras; está em desenvolvimento e ainda não é público. Os dois rodam na plataforma descrita nesta seção.

Seus. Tratamos os dados para operar o serviço contratado e nada além disso. Eles não são misturados com os de outro cliente, não são vendidos e não são usados para anunciar aos seus usuários. Se a relação acabar, os dados vão com você.

As conexões usam HTTP/3 e o domínio está na lista HSTS pré-carregada dos navegadores, então o navegador se recusa a falar sem criptografia já na primeiríssima visita, antes que qualquer redirecionamento pudesse ser interceptado. A troca de chaves é pós-quântica: X25519 combinado com ML-KEM-768, escolhida para que o tráfego capturado hoje continue resistindo quando um computador quântico puder atacá-lo.

Nunca no código-fonte — e quem impõe isso é o build, não a disciplina: código com segredo escrito à mão é recusado antes de entrar. Os segredos ficam criptografados num repositório de configurações e só são decifrados em tempo de execução onde realmente fazem falta, então trocar uma chave é uma mudança em um lugar, não uma caçada pela base de código inteira.

Dá. Eventos da aplicação, erros e ações administrativas vão para o banco de dados, e não para arquivos de texto espalhados por servidores, então dá para pesquisar de verdade. As alterações administrativas registram quem agiu, o que mudou e quando. Para "quem mexeu nesse preço mês passado" existe resposta, não palpite.

Cookies não essenciais só entram depois que o visitante aceita, a escolha fica registrada e todo site que construímos tem uma página para mudar ou revogar isso depois. Recusar é um clique, não uma caçada dentro de um menu de configurações — e quem recusa continua com um site que funciona.

Um modelo fazendo uma tarefa definida dentro do seu produto e ganhando de forma mensurável da alternativa: separar mensagens que chegam, redigir textos que uma pessoa depois aprova, fazer a busca entender o que a pessoa quis dizer e não o que digitou. Não é uma bolha de chat colada num site pronto. A pergunta útil nunca é "dá para colocar IA", e sim "qual tarefa repetida está te custando tempo".

No conteúdo. Nosso material multilíngue é produzido e mantido em dia com apoio de modelos e depois revisado por idioma antes de ir ao ar — nunca publicado direto da saída do modelo. É também por isso que falamos de IA com cuidado: sabemos por experiência própria onde o resultado é bom e onde ainda precisa de uma pessoa.

Antes de construir qualquer coisa, deixamos por escrito qual fornecedor trata quais dados e o que fica retido. Se essa resposta não servir para você, o recurso é desenhado de outro jeito ou simplesmente não é feito. Nenhum dado sai do seu sistema de um jeito que você não aceitou — e "não sabíamos que estava sendo enviado" não é um resultado que aceitamos entregar.