Construyo productos digitales.Construyoproductos digitales.De la idea al sistema completo.

Vender productos digitales parece sencillo mientras los clientes son diez. Después cada compra es un pago que verificar, un material que entregar, una persona a la que hacer seguimiento y un contenido que mantener al día. Hecho a mano, todo eso deja de escalar mucho antes de lo que uno cree, y cada paso manual es un error esperando su momento.

Construir un negocio que funcione también cuando nadie lo está mirando. La parte pública tiene que convencer y explicarse sola; la compra, la entrega y el registro del cliente tienen que ocurrir sin que una persona tenga que intervenir.

Tres piezas con fronteras nítidas. La parte pública es deliberadamente ligera y estática: tiene que abrirse rápido también desde el móvil y con poca cobertura. Detrás, un servicio de aplicación se ocupa de lo que no puede estar en el navegador: pagos, verificación, entrega de los materiales, comunicación con los servicios externos. Al lado, en su propio dominio y tras autenticación, MBBET OS: un sistema construido a medida, no un programa de gestión comprado y adaptado. Ningún secreto vive en el código que llega al visitante.

• Una compra ya no necesita ningún paso manual: pago, verificación y entrega ocurren solos.
• El merchandising existe sin almacén y sin logística.
• Los contenidos son una estructura navegable, no una colección de páginas.

En la mayoría de las pequeñas empresas el software ya existe. El problema es que las piezas no se hablan: los datos se copian a mano de una herramienta a otra, la misma información vive en tres sitios distintos y cada proceso tiene un paso que funciona solo porque hay una persona que se acuerda. Los asistentes de IA genéricos no resuelven nada, porque no saben nada de esa empresa.

Un agente que trabaje DENTRO de los datos de la empresa, no al lado. Que sepa leer el sistema de gestión, preparar un presupuesto, actualizar una pipeline, y que se detenga a pedir confirmación cuando la acción tiene consecuencias. La IA que prepara, la persona que decide.

Aplicación con renderizado híbrido sobre plataforma serverless, base de datos relacional con aislamiento por tenant aplicado por la propia base de datos —no por la interfaz— y una capa de orquestación entre el modelo de lenguaje y los datos de la empresa. El agente no tiene acceso directo a la base de datos: pasa por herramientas declaradas, y cada herramienta sabe si puede ejecutar o solo proponer.

• El aislamiento de datos entre empresas lo aplica la base de datos, no el código de la interfaz.
• El flujo de pago está verificado de extremo a extremo, incluida la autenticación reforzada.
• El agente distingue siempre entre lo que ha leído, lo que sugiere y lo que ha ejecutado, y muestra las fuentes.

Quien no es del oficio posee un objeto complejo sin tener las herramientas para entenderlo. La información existe, pero está escrita para quien ya sabe: manuales técnicos, códigos, foros. El resultado es que las decisiones sobre el coche se toman por confianza o por miedo, nunca por comprensión.

Dar la vuelta al punto de partida. No un catálogo que hay que buscar, sino un recorrido que parte de cómo la persona usa el coche y de qué le pasa de verdad, y que por el camino le explica lo que está eligiendo.

Las páginas nunca hablan directamente con la base de datos: pasan por una frontera que expone el catálogo y que tiene dos implementaciones intercambiables, una local y otra remota. Hay una suite de paridad que compara los dos orígenes y que se autocomprueba inyectando fallos conocidos, y un test que inspecciona el paquete producido por la compilación y falla si encuentra un secreto dentro.

• La navegación parte del problema de la persona, no de la estructura del catálogo.
• El origen de los datos es sustituible sin modificar una sola página.
• La imagen principal está anclada a la geometría de la fotografía y no provoca saltos de maquetación.

Una empresa de carpintería vive de presupuestos. Delante hay un cliente que tiene que entender qué puede pedir; detrás está quien tiene que calcularlo, y cada tipología —mosquiteras, persianas y las demás del catálogo— tiene medidas, variantes y reglas propias. La web y el presupuesto parecen dos mundos separados, pero son el mismo trabajo: uno lo genera, el otro lo resuelve.

Tratar las dos mitades como un solo sistema. La web no tiene solo que existir: tiene que traer solicitudes que ya sirvan. La herramienta interna no tiene solo que calcular: tiene que partir de esas solicitudes. En medio, las reglas que hoy viven en la cabeza de quien presupuesta hay que escribirlas una sola vez.

La web pública está optimizada para ser encontrada y para convertir una visita en una solicitud. La herramienta operativa es una aplicación web con una parte de servidor que se ocupa del acceso y la persistencia, y código organizado por categoría de producto: añadir una tipología significa añadir su módulo de reglas, no modificar el resto. Es la decisión que hace la herramienta reutilizable en vez de reescribible.

• La presencia pública y la herramienta interna son dos partes del mismo recorrido, no dos proyectos desconectados.
• Las reglas de cálculo viven en un solo sitio, en vez de en la memoria de quien presupuesta.
• Añadir una tipología de producto no obliga a volver sobre las que ya existen.

Las hipotecas, los préstamos y la financiación son un ámbito al que la gente llega desconfiada y con pocas palabras para describir lo que busca. Una web que enumera servicios no resuelve nada: quien lee no sabe en qué apartado entra su caso, y si no lo sabe no rellena ningún formulario.

Construir la página alrededor de la pregunta real de quien la abre —«¿mi caso entra?»— en vez de alrededor de la lista de la oferta. Primero hacer entender, después pedir el contacto: en ese orden, y nunca al revés.

Sitio estático: ninguna base de datos que mantener, ninguna superficie que actualizar, tiempos de apertura brevísimos también en red móvil. La recogida de las solicitudes pasa por un servicio externo dedicado, así el formulario funciona sin que haya un servidor que vigilar. Es la decisión correcta cuando la tarea de la web es convencer y recoger, no procesar.

• El servicio se entiende antes de pedirlo: la explicación precede al formulario, no lo sigue.
• Quien llega desde el móvil encuentra la misma experiencia que quien llega desde el ordenador.

Casi cincuenta años dentro de la producción no caben en un folleto. Quien busca esta consultoría llega desde países e idiomas distintos, a menudo con un problema concreto —una planta que arrancar, una producción que no aguanta— y tiene que entender en pocos segundos si tiene delante a la persona adecuada. Un sitio en un solo idioma, con una lista de servicios, no lo dice.

Una sola experiencia, adaptada a tres mercados en vez de traducida tres veces. Primero el método y la persona, después los servicios: quien lee tiene que reconocer su caso antes de encontrar un formulario. Y el contacto tiene que seguir al alcance desde cualquier punto, porque quien decide lo hace mientras lee, no al final.

Next.js con el segmento de idioma en la ruta y los textos en archivos tipados, uno por idioma: una sola estructura, tres contenidos, ninguna página duplicada que mantener alineada. Las rutas viven en un registro que declara estado, indexabilidad y slug por idioma; de ahí descienden sitemap, canonical y hreflang, así que una página nueva no puede nacer fuera del mapa del sitio. Páginas estáticas en red distribuida; el formulario es lo único que corre en el servidor.

• Cinco direcciones indexables, todas con canonical hacia sí mismas y hreflang recíprocos entre los tres idiomas.
• Sitemap generada desde el registro de rutas y aceptada por Search Console, sin páginas de prueba ni borradores.
• Los eventos de contacto verificados sobre las llamadas realmente salidas, no solo en la cola del navegador: ninguno contiene datos personales.
• La etiqueta de medición se carga al final, después del contenido: adelantarla costaba, medido en red lenta, más de dos segundos de LCP sobre la fotografía de apertura.