Perguntas frequentes

A MS WebX é uma empresa de informática. Construímos sites e plataformas web, aplicações nativas para iOS e Android e integramos IA nelas, a par do trabalho de SEO que torna visível o que construímos. Operamos também produtos próprios na mesma plataforma que usamos com clientes, pelo que a base já corre em produção antes de alguém depender dela.

As duas coisas, de propósito. O que oferecemos corre primeiro nos nossos produtos: o sistema de páginas multilingue, a camada de API, as ferramentas de administração, a analítica. Nenhum projeto de cliente arranca sobre uma base por testar e, se algo no núcleo falha, damos por isso antes do cliente.

De três formas, todas independentes do que aqui escrevemos. A página de informação legal contém os dados oficiais da empresa. Os nossos produtos são públicos e podem ser usados sem nos contactar. E a página de contacto chega às mesmas pessoas que escrevem o código, sem um call center pelo meio.

Descreve o objetivo, não a solução técnica. Fazemos perguntas até o âmbito ficar mesmo claro e pomo-lo por escrito antes de construir seja o que for. Se acharmos que o caminho pedido é o errado, dizemos antes de pagar — essa conversa custa menos do que a refeitura que evita.

Em passos pequenos e visíveis. O trabalho vai para um ambiente de testes que pode abrir no browser quando quiser e só passa para o site ao vivo quando disser. Ninguém vê o produto acabado pela primeira vez no fim do projeto — nessa altura qualquer alteração sai cara.

O que construímos é feito para ser mantido: atualizações de dependências, monitorização e alterações à medida que o negócio muda. Se continuamos nós ou se a sua equipa assume, fica combinado dentro do projeto e não presumido depois. Nada é construído de modo a que só nós lhe possamos tocar.

Lemos primeiro o código existente e depois dizemos com clareza se continuar ou substituir custa menos ao longo da vida do sistema. Acontecem as duas respostas — código herdado costuma estar perfeitamente bem, apenas mal documentado. Não recomendamos refazer por reflexo, porque refazer é a coisa mais cara que lhe podem vender.

PHP no servidor, TypeScript no navegador, Flutter para iOS e Android, MariaDB para os dados, nginx e FrankenPHP para servir. Tecnologia atual e amplamente conhecida de propósito, para que qualquer pessoa a possa manter depois de nós. A qualidade é imposta por máquinas e não por boas intenções: a análise estática corre no nível mais rigoroso sem lista de exceções, além de mais de duzentas regras próprias que rejeitam o código assim que ele desvia.

Uma base de código com um núcleo comum e uma camada fina por marca por cima. Cada marca tem o seu design, os seus conteúdos, a sua base de dados e o seu domínio, enquanto correções de segurança, trabalho de desempenho e novas funcionalidades 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 forma mais estrita do que a frase costuma significar. A API é definida uma vez em PHP e tanto o cliente TypeScript da web como o cliente Dart da aplicação são gerados a partir dessa definição. Nenhum é escrito à mão: o linter recusa um tipo de API escrito manualmente. Assim a aplicação não pode dessincronizar-se em silêncio — uma divergência parte a compilação, não a produção.

Reais. Cada página existe como registo próprio por idioma, com texto e URL próprios — estas perguntas frequentes estão 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 escreve-se como se procura mesmo nesse mercado e corrige-se um sem mexer nos outros dezassete.

É para isso que foi construída. Cada marca tem a sua base de dados, o seu domínio e os seus conteúdos, pelo que uma marca não consegue ler os dados de outra e um erro de conteúdo numa não aparece na outra. O que é partilhado é o motor: o encaminhamento, a camada de API, as ferramentas de administração e o trabalho de segurança.

O Cannabivo está no ar: um motor de busca de clubes sociais, onde os visitantes encontram e comparam clubes por localização e os clubes gerem a sua própria ficha. O Steel é uma referência de equivalências de materiais dirigida à engenharia e às compras; está em desenvolvimento e ainda não é público. Ambos correm na plataforma descrita nesta secção.

Seus. Tratamo-los para operar o serviço que nos encomendou e para mais nada. Não são misturados com os de outro cliente, não são vendidos e não servem para mostrar publicidade aos seus utilizadores. Se a relação terminar, leva os dados consigo.

As ligações usam HTTP/3 e o domínio consta da lista HSTS pré-carregada dos navegadores, pelo que o navegador recusa falar sem cifra logo na primeiríssima visita, antes de qualquer redirecionamento poder ser intercetado. A troca de chaves é pós-quântica: X25519 combinado com ML-KEM-768, escolhida para que tráfego capturado hoje continue a resistir quando um computador quântico o puder atacar.

Nunca no código-fonte — e é a compilação que o impõe, não a disciplina: código com um segredo escrito à mão é recusado antes de poder ser integrado. Os segredos ficam cifrados num arquivo de definições e só são decifrados em execução onde fazem falta, pelo que trocar uma chave é uma alteração num sítio e não uma caça por toda a base de código.

Sim. Eventos da aplicação, erros e ações administrativas são escritos na base de dados e não em ficheiros de texto espalhados por servidores, pelo que se conseguem mesmo pesquisar. As alterações administrativas registam quem agiu, o que mudou e quando. A «quem alterou este preço no mês passado» há resposta, não palpite.

Os cookies não essenciais só são colocados depois de o visitante aceitar, a escolha fica registada e todos os sites que construímos têm uma página onde a pode alterar ou retirar mais tarde. Recusar é um clique e não uma caça num menu de definições — e quem recusa continua a ter um site que funciona.

Um modelo a fazer uma tarefa definida dentro do seu produto, batendo de forma mensurável a alternativa: separar mensagens que chegam, redigir textos que uma pessoa depois aprova, fazer a pesquisa perceber o que alguém queria dizer e não o que escreveu. Não é uma bolha de chat colada num site acabado. A pergunta útil nunca é «podemos acrescentar IA», mas «que tarefa repetida lhe está a custar tempo».

No conteúdo. O nosso material multilingue é produzido e mantido atual com apoio de modelos e depois revisto por idioma antes de sair — nunca publicado diretamente a partir do modelo. É também por isso que falamos de IA com cuidado: sabemos por experiência própria onde o resultado é sólido e onde ainda precisa de uma pessoa.

Antes de se construir seja o que for, indicamos por escrito que fornecedor trata que dados e o que fica guardado. Se essa resposta não lhe servir, a funcionalidade é desenhada de outra forma ou não é feita. Nenhum dado sai do seu sistema de um modo que não tenha aceitado — e «não sabíamos que estava a ser enviado» não é um resultado que estejamos dispostos a produzir.