Preguntas frecuentes

MS WebX es una empresa de tecnología. Desarrollamos sitios y plataformas web, aplicaciones nativas para iOS y Android, e integramos IA en ellas, junto con el trabajo de SEO que hace visible lo que construimos. Además operamos productos propios sobre la misma plataforma que usamos con clientes, de modo que la base ya funciona en producción antes de que alguien más dependa de ella.

Las dos cosas, y a propósito. Lo que ofrecemos ya está funcionando antes en nuestros propios productos: el sistema de páginas multilingüe, la capa de API, las herramientas de administración, la analítica. Ningún proyecto de cliente arranca sobre una base sin probar, y si algo del núcleo falla lo notamos nosotros antes que el cliente.

De tres maneras, todas independientes de lo que digamos aquí. La página de aviso legal recoge los datos legales de la empresa. Nuestros productos son públicos y se pueden usar sin contactarnos. Y la página de contacto llega a las mismas personas que escriben el código, sin un centro de llamadas por delante.

Describe el objetivo, no la solución técnica. Preguntamos hasta que el alcance esté realmente claro y lo dejamos por escrito antes de construir nada. Si creemos que lo que pides no es el mejor camino hacia tu objetivo, lo decimos antes de que pagues: esa conversación cuesta menos que la reconstrucción que evita.

En pasos pequeños y visibles. El trabajo va a un entorno de pruebas que puedes abrir en el navegador cuando quieras, y solo pasa a producción cuando tú lo apruebas. Nadie ve el producto terminado por primera vez al final del proyecto: en ese momento cualquier cambio ya sale caro.

Lo que construimos está pensado para mantenerse: actualizaciones de dependencias, monitorización y cambios a medida que cambia tu negocio. Si seguimos nosotros o lo asume tu propio equipo se acuerda dentro del proyecto, no se da por hecho después. Nada se construye de forma que solo nosotros podamos tocarlo.

Primero leemos el código existente y luego decimos con claridad si continuarlo o sustituirlo sale más barato a lo largo de la vida del sistema. Se dan las dos respuestas: un código heredado suele estar perfectamente bien y solo mal documentado. No recomendamos rehacer por reflejo, porque rehacer es lo más caro que alguien puede venderte.

PHP en el servidor, TypeScript en el navegador, Flutter para iOS y Android, MariaDB para los datos, nginx y FrankenPHP para servir. Tecnología actual y muy conocida a propósito, para que cualquiera pueda mantenerla después de nosotros. La calidad la garantizan las máquinas y no las buenas intenciones: el análisis estático corre en su nivel más estricto sin lista de excepciones, más de doscientas reglas propias rechazan el código en cuanto se desvía.

Una base de código con un núcleo común y una capa fina por marca encima. Cada marca tiene su diseño, su contenido, su base de datos y su dominio, mientras que las correcciones de seguridad, el trabajo de rendimiento y las nuevas funciones del núcleo llegan a todas a la vez en lugar de copiarse a mano en cada sitio. Añadir una marca es configuración y contenido, no un fork.

Sí, y de forma más estricta de lo que suele significar esa frase. La API se define una vez en PHP, y tanto el cliente TypeScript de la web como el cliente Dart de la app se generan a partir de esa definición. Ninguno se escribe a mano: el linter rechaza un tipo de API escrito manualmente. Así la app no puede desincronizarse en silencio; un desajuste rompe la compilación en lugar de la producción.

Reales. Cada página existe como registro propio por idioma, con su texto y su URL — estas preguntas frecuentes están en /frequently-asked-questions en inglés y en /de/haeufig-gestellte-fragen en alemán, no tras un parámetro de traducción. Así cada idioma se escribe como la gente busca de verdad en ese mercado, y se puede corregir uno sin tocar los otros diecisiete.

Para eso está hecha. Cada marca tiene su base de datos, su dominio y su contenido, de modo que una marca no puede leer los datos de otra y un error de contenido en una no aparece en la otra. Lo que comparten es el motor: el enrutado, la capa de API, las herramientas de administración y el trabajo de seguridad.

Cannabivo está en marcha: un buscador de clubes sociales donde los visitantes encuentran y comparan clubes por ubicación y los clubes gestionan su propia ficha. Steel es una referencia de equivalencias de materiales pensada para ingeniería y compras; está en desarrollo y todavía no es pública. Ambos funcionan sobre la plataforma descrita en esta sección.

Tuyos. Los tratamos para operar el servicio que nos has encargado y para nada más. No se mezclan con los datos de otro cliente, no se venden y no se usan para mostrar publicidad a tus usuarios. Si la relación termina, los datos te los llevas tú.

Las conexiones van por HTTP/3 y el dominio está en la lista HSTS precargada de los navegadores, de modo que el navegador se niega a hablar sin cifrado ya en la primera visita, antes de que ninguna redirección pueda interceptarse. El intercambio de claves es poscuántico: X25519 combinado con ML-KEM-768, elegido para que el tráfico capturado hoy siga resistiendo cuando un ordenador cuántico pueda atacarlo.

Nunca en el código fuente, y eso lo impone la compilación, no la disciplina: el código con un secreto escrito a fuego se rechaza antes de poder integrarse. Los secretos viven cifrados en un almacén de configuración y se descifran en ejecución solo donde hacen falta, de modo que rotar una clave es un cambio en un sitio y no una búsqueda por toda la base de código.

Sí. Los eventos de la aplicación, los errores y las acciones administrativas se escriben en la base de datos y no en ficheros de texto repartidos por los servidores, así que se pueden buscar de verdad. Los cambios administrativos registran quién actuó, qué se cambió y cuándo. A «quién cambió este precio el mes pasado» hay respuesta, no conjetura.

Las cookies no esenciales solo se activan cuando el visitante acepta, la decisión queda registrada y cada sitio que construimos tiene una página donde cambiarla o retirarla después. Rechazar es un clic y no una búsqueda por un menú de ajustes, y quien rechaza sigue teniendo un sitio que funciona.

Un modelo haciendo un trabajo concreto dentro de tu producto, donde supere de forma medible a la alternativa: clasificar mensajes entrantes, redactar textos que después aprueba una persona, hacer que el buscador entienda lo que alguien quería decir y no lo que tecleó. No es una burbuja de chat pegada sobre una web terminada. La pregunta útil nunca es «¿podemos añadir IA?», sino «¿qué tarea repetida te está costando tiempo?».

En el contenido. Nuestro material multilingüe se produce y se mantiene al día con ayuda de modelos y luego se revisa por idioma antes de publicarse; nunca sale directo del modelo. Por eso mismo somos prudentes al hablar de IA: sabemos por experiencia propia dónde el resultado es sólido y dónde todavía necesita a una persona.

Antes de construir nada dejamos por escrito qué proveedor trata qué datos y qué se conserva. Si esa respuesta no te resulta aceptable, la función se diseña de otra manera o no se hace. Ningún dato sale de tu sistema de una forma que no hayas aceptado, y «no sabíamos que se estaba enviando» no es un resultado que estemos dispuestos a producir.