Desde 2019

Nuestra experiencia en acción

Cada proyecto es una huella de lo que construimos junto a quienes confían en nosotros. Baja y recórrelos uno a uno: el reto, la solución y la arquitectura que hay detrás.

01 / 12Producto propio · Plataforma de operación multi-sucursal

CheckBiz360

El reto

Una empresa con varias sucursales sabe lo que factura cada una, pero no cómo trabaja: quién cumple, qué se ejecutó de verdad, qué documentación está firmada y cuánto cuesta realmente cada sede. Esa información existe repartida en sistemas que no se hablan, y para cuando llega a dirección ya es historia.

La solución

Plataforma sobre dos pilares. Cumplimiento: registro de jornada con sello de tiempo, inmutabilidad y trazabilidad, documentación laboral con acuse de recibo y tareas con evidencia. Inteligencia: índices de fiabilidad y eficiencia, patrón de comportamiento por empleado, coste real por sucursal y detección de anomalías.

FlutterRiverpodFirebaseNode.js · TypeScriptNext.jsMulti-entidadStripe
CheckBiz360: el panel de análisis en un monitor de escritorio y la app de fichaje en el móvil
Lugh: la web de búsqueda de servicios en un monitor de escritorio y la app de reserva en el móvil
02 / 12Marketplace de servicios · De cero a lanzamiento

Lugh

El reto

Contratar un servicio para casa sigue siendo un intercambio de mensajes a ciegas: se pregunta por WhatsApp, se espera, y el precio y el horario no aparecen hasta el final. Quien busca no puede comparar y quien ofrece pierde horas cerrando citas.

La solución

Marketplace que pone precio, duración y horario por delante: se compara y se reserva desde la app, sin negociación previa. Definimos flujos, sistema de diseño y arquitectura de contenidos, con una landing que se renderiza en tiempo de build: HTML plano, sin coste de hidratación y con el SEO listo desde el primer día.

ViteRender en buildGSAPSistema de diseñoSEO técnico
03 / 12Back office interno · Analítica de flota

Entregalia

El reto

Gestionar una flota de repartidores significa depender de los datos que devuelve cada plataforma de reparto, en formatos distintos y con cortes distintos. Sin una vista común no se sabe qué ciudad rinde, qué contrato se cumple ni dónde se está perdiendo dinero.

La solución

Plataforma de analítica que sincroniza y normaliza los datos de cada repartidor y los consolida por día, semana, ciudad y empresa. Cada sincronización queda registrada con su resultado, de modo que un número siempre se puede rastrear hasta la ejecución que lo produjo.

Node.jsMongoDBSincronización programadaMétricas agregadas
Entregalia: el panel de flota en escritorio y la app de reparto en el móvil
SilverBack Training
04 / 12App de entrenamiento · iOS y Android

SilverBack Training

El reto

Un método de entrenamiento con seguidores repartido entre hojas de cálculo, WhatsApp y vídeos sueltos. El entrenador era el cuello de botella: crecer significaba más horas suyas, no más alumnos.

La solución

App propia en iOS y Android con programas secuenciales por niveles, biblioteca de vídeo con la técnica de cada ejercicio, seguimiento del progreso y suscripción recurrente. El método se entrega solo y el entrenador deja de ser el intermediario.

iOSAndroidFirebaseSuscripcionesVídeoBack office
05 / 12Salud · Área de paciente

Clínica Baviera

El reto

En una red de clínicas grande, el paciente llama para todo: confirmar una cita, pedir un informe, recuperar un consentimiento. Cada llamada es tiempo de personal sanitario haciendo de intermediario con un sistema que el paciente no puede consultar.

La solución

Área de paciente en web y app: citas, documentación clínica descargable y acceso protegido con biometría. La documentación se abre dentro de la propia aplicación, sin salir a un visor externo, y el despliegue va por tres entornos con integración continua.

FlutterReactAzure Static Web AppsBiometríaPDFCI/CD
Clínica Baviera
FGCSIC
06 / 12Ciencia e innovación · Portal institucional

FGCSIC

El reto

Una fundación que opera tres líneas muy distintas —talento científico, innovación e inversión— con más de una docena de programas propios debajo, cada uno con su convocatoria, su plazo y su público. Contarlo todo en un mismo sitio sin que el visitante se pierda, y en dos idiomas.

La solución

Portal institucional bilingüe con tema propio: cada línea con su entrada, los programas como fichas de una misma familia, un tipo de contenido específico para convocatorias y eventos con sus plazos, y las obligaciones de transparencia y canal de denuncias integradas en la navegación, no colgadas del pie.

WordPressTema a medidaWPML · ES/ENConvocatoriasSEO técnico
07 / 12Certificación · Campus y app

GROUND

El reto

Un método de movimiento que forma instructores por todo el mundo y que se apoyaba en herramientas sueltas: el curso por un lado, los alumnos por otro, los eventos en la web y ninguna forma de que alguien en otra ciudad encontrara a un instructor certificado.

La solución

Ecosistema completo: campus online para la certificación, gestión de ediciones y alumnos por grupos, agenda de eventos y workshops, directorio de dónde entrenar filtrable por país y ciudad, y app de entrenamiento propia con tres entornos separados.

FlutterFirebaseLMSMulti-entornoDirectorio geográfico
GROUND
Moana Deals
08 / 12Inmobiliario · Plataforma de operaciones

Moana Deals

El reto

En la compraventa de activos inmobiliarios la información no fluye: el vendedor no llega a los inversores adecuados, el inversor no encuentra oportunidades ordenadas y la documentación de cada operación circula por correo, sin control de quién ve qué.

La solución

Plataforma que reúne las tres partes —quien vende, quien invierte y quien colabora— en un mismo circuito: publicación de activos, preparación de la documentación, sala de datos virtual y acceso diferenciado por perfil, con un modelo de precios ligado al cierre.

WordPressPerfiles y permisosListadosSala de datos
09 / 12Industria · Campus de formación

Molecor

El reto

Una tecnología industrial propia, fábricas y distribuidores en varios países, y la formación técnica dependiendo de que alguien viajara a darla. El conocimiento estaba en las personas, no en un sitio al que se pudiera acceder.

La solución

Campus de formación propio en español, inglés y turco, con cursos estructurados, alta masiva de alumnos y organización por grupos para separar equipos, filiales y distribuidores. La formación deja de depender de la agenda de nadie.

LMSMulti-idioma ES · EN · TRGestión de gruposAlta masivaCloud
Molecor
JabSolutions: la web de la empresa en escritorio y en el móvil
10 / 12Marca · De cero a presencia digital

JAB Solutions

El reto

Una empresa de excavaciones y maquinaria pesada que abría una segunda línea de negocio, la distribución de lubricantes, sin nada digital detrás: ni web, ni ficha en Google, ni catálogo consultable. Y con un nombre —Excavaciones JAB— que ya no contaba lo que hacía.

La solución

Diagnóstico y construcción de marca desde cero: plataforma de marca con las dos líneas bajo una matriz, sistema visual e identidad cromática, mensajes que posicionan el servicio de distribución por encima del producto que se distribuye, y los activos digitales mínimos para ser encontrables, fiables y contactables.

Estudio de marcaIdentidad visualWeb MVPCatálogoGoogle Business ProfileMedición UTM
11 / 12Plataforma de reservas · Pago online

ITV A-42

El reto

Una estación de ITV vive de la cita previa, y darla por teléfono cuesta personal, llena huecos mal y no cobra por adelantado. Cada llamada ocupa a alguien de la estación y cada hueco vacío es capacidad de línea que se pierde.

La solución

Plataforma completa de reserva y pago: el cliente elige tipo de inspección, ve el precio, reserva su hueco y paga online; puede anular sin llamar. Detrás, un back office donde la estación gestiona precios, reservas, usuarios, plantillas de correo y contactos.

Next.js 15React 19MongoDBRedsysStripeNextAuthSocket.IOBack office
ITV A-42: la reserva de cita en escritorio y en el móvil
JCHammer: el catálogo técnico en escritorio y en el móvil
12 / 12Industria · Catálogo y distribuidores

JCHammer

El reto

Un fabricante de herramienta profesional que no vende al público sino a través de distribuidores autorizados. Su web tenía que convencer al profesional de que quiere la herramienta y, acto seguido, llevarlo al distribuidor correcto, sin carrito de por medio.

La solución

Web de catálogo técnico con tema propio: cada herramienta con sus especificaciones y sus opciones, la historia de marca que sostiene el argumento de ingeniería, y la red de distribuidores como destino final de toda la navegación.

WordPressTema a medidaCatálogo técnicoRed de distribuidores
Siguiente huella

¿Construimos el tuyo?

Cuéntanos dónde estás y hasta dónde quieres llegar. Respondemos en menos de 24 horas.

hola@encodebiz.com · +34 623 519 591
01 / 12Producto propio · Plataforma de operación multi-sucursal

CheckBiz360

CheckBiz360 es nuestro producto propio: una plataforma de operación para empresas multi-sucursal, construida sobre dos pilares. Cumplimiento, para que lo que exige la ley esté cubierto y sea defendible. Inteligencia, para que esa misma operación diaria se convierta en criterio de dirección.

El punto de partida

El registro de jornada es la puerta de entrada, no el producto. Es lo que obliga a una empresa a instalar algo, y por eso el mercado está lleno de herramientas que registran horas y se detienen ahí. El problema que nos interesaba estaba justo después.

Una organización con varias sucursales sabe lo que factura cada una y no sabe cómo trabaja. Los dolores que encontramos, repetidos en todos los clientes con los que hablamos:

  • Registros difíciles de defender: fichajes sin validar y correcciones manuales frecuentes, que ante una inspección obligan a reconstruir a mano.
  • Documentación laboral —nóminas, contratos— enviada por correo, sin acuse de recibo ni forma de demostrar que llegó.
  • Tareas operativas que se dan por hechas porque alguien lo dice, sin evidencia de que se ejecutaron.
  • Sucursales imposibles de comparar: cada una «parece» funcionar bien porque no hay métricas homogéneas ni coste real por sede.
  • Decisiones sobre personas —promociones, refuerzos, ajustes de turno— tomadas por impresión, sin un patrón medido detrás.
  • Anomalías que se detectan cuando ya están en el resultado del mes.

El objetivo

Que la operación diaria se registre una sola vez y sirva para las dos cosas: cumplir y decidir. Presencia, ejecución y documentación entran por la app del empleado como parte de su día; salen por el panel convertidas en índices comparables entre sucursales.

El módulo de inteligencia operativa es el que cierra el círculo, y el que hace que el producto no sea un control horario. Levanta un índice de fiabilidad y un índice de eficiencia operativa —coste real frente al histórico—, construye el patrón de comportamiento de cada empleado, que es lo que supera al informe puntual, y sobre él da una evaluación operativa con diagnóstico y señal de candidato a promoción. La detección de anomalías avisa mientras se puede corregir.

La restricción de diseño era que nada de eso podía pedir esfuerzo extra a quien trabaja. El fichaje tenía que seguir siendo un gesto de dos segundos.

Qué hace la plataforma

El alcance funcional se reparte en módulos que comparten la misma estructura de entidad y sucursales:

  • Control horario: tres capas de validación —geocerca, horario y dispositivo—, fichaje desde la app, en remoto con su zona horaria o por QR con token y validación de supervisor; pausas con descuento automático, jornada manual y flujo de revisión y aprobación.
  • Tareas: creación con campos propios, asignación individual o múltiple, evidencia en foto y vídeo, prioridades y fechas límite, validación con aceptación o rechazo motivado, y una escala de puntuación que repercute en el índice de eficiencia del trabajador.
  • Gestión documental: nóminas y contratos con su ciclo mensual y su retención legal, documentos privados con visibilidad por rol, acuse de recibo y aviso push que lleva directo al documento.
  • Inteligencia operativa: panel de operación con los índices de fiabilidad y eficiencia, patrón de comportamiento, análisis de coste con tarifa por sucursal y detección de anomalías.
  • Entidad y sucursales: datos fiscales y zona horaria en la entidad, con propagación a las sedes; geocerca, pausas, tolerancia y tarifa por sucursal; y una vista global que compara todas.
  • Empleados y seguridad: cuatro roles —worker, supervisor, manager y owner— con matriz de permisos, doble factor, biometría, dispositivos de confianza y acceso multi-entidad con selector.
  • Cumplimiento: registro de jornada según el RDL 8/2019 con sello de tiempo, inmutabilidad y trazabilidad; tratamiento de datos conforme a RGPD; e informes preparados para presentar en una inspección.

Los desafíos

El primero fue la confianza del dato. Un marcaje sirve de prueba solo si se puede reconstruir: dónde se hizo, con qué dispositivo, a qué hora real y qué se tocó después. De ahí las tres capas de validación y un historial inmutable en el que cada cambio deja rastro, de modo que una jornada concreta se demuestra en segundos.

El segundo fue el análisis. Comparar no es poner números uno al lado del otro: hay que normalizar realidades distintas —turnos, calendarios, tamaños de equipo, tarifas por sede— antes de que la comparación signifique algo. Y las señales interesantes no están en un día suelto sino en el cambio sostenido, así que el motor trabaja sobre patrón y no sobre incidencias aisladas.

El tercero fue la estructura organizativa. Multi-entidad y multi-sucursal a la vez obliga a decidir qué se configura arriba y se propaga, qué se ajusta por sede y qué pasa con los registros históricos cuando una sucursal se desactiva. Esa decisión condiciona el modelo de datos entero.

El cuarto fue de arquitectura. Un producto que es a la vez app de campo, gestor documental, panel de dirección y plataforma de suscripción no cabe en un solo servicio sin volverse frágil.

Cómo está construido

La app móvil es Flutter con Riverpod para estado e inyección, GoRouter para navegación declarativa y Freezed para modelos inmutables. Apoya en Firebase para autenticación, Firestore, almacenamiento, notificaciones y Crashlytics, y en Geolocator y Google Maps para la validación por ubicación.

Detrás hay un monorepo de microservicios en Node y TypeScript, con los dominios separados en servicios propios —fichaje, sincronización, analítica, informes, tareas, documentos y ventas— sobre un paquete compartido común. Así la capa de inteligencia puede evolucionar y desplegarse sin tocar la que registra, que es la que no se puede permitir un fallo.

El panel de gestión y la capa SaaS son Next.js con React 19, con Firebase Admin en servidor y Stripe para la suscripción.

02 / 12Marketplace de servicios · De cero a lanzamiento

Lugh

Lugh conecta a quien busca un servicio para su día a día con profesionales preparados para ofrecerlo, con 18 categorías activas en Madrid. El proyecto fue de concepto a producción con nosotros.

El punto de partida

La idea existía y tenía personalidad, pero no tenía traducción digital. Antes de escalar nada había que convertirla en un producto que se entendiera a la primera, porque en un marketplace de servicios la fricción de la primera visita es el negocio entero.

El dolor del sector es conocido: el precio es opaco hasta que alguien contesta, la disponibilidad no se ve, y las dos partes acaban gestionando por mensajería. Nadie puede comparar y todos pierden tiempo.

El objetivo

Que la decisión se pudiera tomar antes de hablar con nadie. Precio, duración y horarios visibles por delante, comparables entre profesionales, y reserva directa desde la app. Todo lo demás del producto se organizó alrededor de esa regla.

En paralelo, la captación tenía que funcionar desde el día uno: un marketplace vive de búsquedas con intención local, y eso obliga a que la landing sea rápida y legible para un rastreador.

Los desafíos

Definir el modelo de contenidos de forma que 18 categorías con realidades muy distintas cupieran en la misma ficha sin que ninguna quedara forzada, y que añadir la número 19 no obligara a rehacer nada.

El otro desafío fue de rendimiento. Una landing con animación y personalidad suele pagarse en JavaScript en cliente, y eso penaliza justo donde más duele: la primera carga desde un resultado de búsqueda.

Cómo está construido

La landing se escribe componentizada, por módulos de sección, pero se renderiza a HTML en tiempo de build. Lo que se sirve es un documento plano con todo el contenido dentro antes de que se ejecute una sola línea de JavaScript: sin coste de hidratación y con el SEO intacto.

Todo el contenido editorial vive separado del marcado, en su propia capa de datos, así que el equipo cambia textos, categorías o zonas sin tocar componentes. Encima, un sistema de tokens de marca —tipografía, color, espaciado— mantiene la coherencia cuando el producto crece.

El comportamiento en cliente es deliberadamente pequeño: navegación, acordeón accesible de preguntas frecuentes, animaciones con GSAP y la simulación de búsqueda del móvil de la portada.

ViteRender en buildGSAPSistema de diseñoSEO técnico
03 / 12Back office interno · Analítica de flota

Entregalia

Entregalia es la capa de analítica de una operación de reparto: toma los datos de actividad de cada repartidor, los normaliza y los convierte en métricas comparables por ciudad, empresa y periodo.

El punto de partida

Una flota de reparto trabaja para varias plataformas a la vez, y cada una entrega su información a su manera. El equipo de operaciones acababa reconstruyendo a mano, en hojas de cálculo, algo que debería ser una consulta.

El coste de eso no es solo el tiempo: es que las decisiones —dónde reforzar, qué contrato revisar, qué ciudad no cuadra— se tomaban tarde y sobre datos que nadie podía verificar.

El objetivo

Una única fuente de verdad sobre la actividad de la flota, actualizada sola, en la que cada cifra fuera trazable. No un cuadro de mando bonito sobre datos dudosos, sino lo contrario: primero la fiabilidad del dato, después la lectura.

Los desafíos

La sincronización con fuentes externas es la parte frágil de un sistema así: fallan, devuelven parciales, repiten registros o cambian de formato sin avisar. Un proceso que se limite a escribir lo que recibe acaba corrompiendo el histórico en silencio.

El segundo desafío fue la identidad. Un mismo repartidor aparece con claves distintas según la fuente, y consolidar métricas sobre identidades mal resueltas produce números que parecen correctos y no lo son.

El tercero, la forma de las consultas. Las preguntas reales de operaciones cruzan repartidor, ciudad, empresa y periodo en combinaciones que cambian cada semana.

Cómo está construido

El núcleo es un servicio en Node sobre MongoDB con tres piezas: el censo de repartidores, las métricas consolidadas y el histórico de sincronizaciones. Esa tercera pieza es la que sostiene la confianza del sistema: cada ejecución deja constancia de cuándo corrió y cómo terminó, así que ante un número raro se puede ir hasta su origen en lugar de discutirlo.

La identidad del repartidor se resuelve con una clave única propia, independiente de la que use cada fuente, y el censo guarda su estado de sincronización para aislar los casos que necesitan intervención manual.

Las métricas se almacenan ya agregadas por repartidor y día, con la semana y el código de ciudad materializados junto al registro. Los índices están construidos para las combinaciones que operaciones consulta de verdad, de forma que las preguntas habituales se responden sin recorrer la colección entera.

Node.jsMongoDBSincronización programadaMétricas agregadas
04 / 12App de entrenamiento · iOS y Android

SilverBack Training

SilverBack Training (SBT) es la plataforma de entrenamiento de Samuel Torres: hasta diez programas completos y secuenciales, con planificación diaria y vídeos explicativos de la técnica, más un nivel premium con contenido en vídeo propio.

El punto de partida

El método funcionaba y tenía audiencia, pero se entregaba a mano. Las rutinas vivían en hojas de cálculo, las dudas en mensajería y los vídeos en enlaces sueltos que había que volver a mandar a cada alumno nuevo.

Ese modelo tiene un techo muy claro: cada alumno adicional cuesta horas del entrenador. Y además hace frágil el propio método, porque la progresión —qué viene después de qué— vive en la cabeza de una persona en lugar de en el producto.

El objetivo

Convertir el método en producto. Que la progresión estuviera codificada en la app, que el alumno supiera qué toca hoy sin preguntar, y que el ingreso dejara de ser por sesión para pasar a ser recurrente.

Con una condición: que la técnica no se perdiera por el camino. En este tipo de entrenamiento hacer mal un movimiento es peor que no hacerlo, así que el vídeo explicativo no podía ser un extra, tenía que ir pegado a cada ejercicio.

Los desafíos

Modelar la progresión fue lo primero. Programas secuenciales, con niveles, que se pueden combinar entre sí: el modelo de datos tenía que permitir que un alumno esté en puntos distintos de varios programas a la vez sin que el seguimiento se enrede.

El segundo desafío fue el vídeo. Una biblioteca que crece constantemente tiene que servirse rápido en móvil y con datos limitados, y el coste de entrega no puede escalar con cada alumno nuevo.

El tercero, la suscripción. Dos niveles, dos tiendas —App Store y Google Play— y un estado de acceso que tiene que ser el mismo en ambas plataformas y en el back office.

Cómo está construido

Aplicación nativa publicada en App Store y Google Play, con backend desacoplado sobre Firebase: la app y el panel comparten la misma fuente de datos, de modo que publicar un programa nuevo o corregir una rutina llega a todo el mundo sin desplegar una versión.

La gestión de contenido se resolvió con un back office propio sobre WordPress, para que el equipo publique y edite sin depender de nosotros. La app consume el contenido; el back office lo produce.

El acceso premium se resuelve como un estado del usuario, no como una propiedad de la tienda, así que el mismo alumno mantiene su nivel al cambiar de dispositivo o de plataforma.

05 / 12Salud · Área de paciente

Clínica Baviera

El área de paciente de Clínica Baviera, en web y en aplicación móvil: consulta de citas, acceso a la documentación clínica propia y descarga de informes, con autenticación biométrica en el dispositivo.

El punto de partida

Los puntos de contacto digitales estaban repartidos entre sistemas heredados, con equipos distintos manteniendo cada pieza. Para el paciente eso se traducía en que casi cualquier gestión terminaba en una llamada.

El coste está en los dos lados del teléfono: el paciente que no puede resolver algo simple a su hora, y el personal de clínica dedicando tiempo a consultar y leer en voz alta datos que ya existían en un sistema.

El objetivo

Dar al paciente acceso directo a lo suyo —sus citas y sus documentos— sin abrir un canal nuevo de soporte por el camino. En un entorno sanitario eso significa que el acceso tiene que ser sencillo y estricto a la vez: fácil de usar a diario, imposible de usar por otra persona.

Los desafíos

El primero fue la documentación clínica. Son PDF, a veces pesados, que el paciente necesita ver, guardar y a veces compartir con otro profesional. Enviarlo a un visor externo del sistema operativo rompía la experiencia y sacaba el documento del contexto seguro de la aplicación.

El segundo fue la autenticación. Pedir credenciales completas en cada apertura hace que la gente abandone; no pedir nada es inaceptable con datos de salud.

El tercero fue de proceso. Un área de paciente en producción no se despliega a ciegas: cualquier cambio tiene que poder validarse antes con datos que no sean los reales.

Cómo está construido

La aplicación móvil es Flutter, con renderizado de PDF integrado en la propia app, calendario de citas, cámara y selector de archivos para aportar documentación, y acceso biométrico mediante la autenticación local del dispositivo. Nada obliga a salir de la aplicación.

El área web es React con Redux, con su propio visor y generador de PDF, y se publica como aplicación estática en Azure Static Web Apps.

La entrega va por tres entornos —desarrollo, preproducción y producción—, cada uno con su flujo de integración continua y su dominio propio, y con la promoción entre ramas como única vía de llegar a producción. También construimos el formulario de consentimiento que acompaña al área de paciente.

FlutterReactAzure Static Web AppsBiometríaPDFCI/CD
06 / 12Ciencia e innovación · Portal institucional

FGCSIC

La Fundación General CSIC es una entidad privada sin ánimo de lucro creada en 2008 por el CSIC y sus patronos fundacionales. Promueve la colaboración público-privada en investigación e innovación y pone en valor el conocimiento generado en el CSIC y en otras entidades públicas de I+D.

El punto de partida

La FGCSIC no hace una sola cosa. Opera tres líneas —Ciencia y Talento, Innovación e Inversión VBB— y bajo cada una hay programas propios con nombre y entidad: ComFuturo, Proyectos Cero, InspiraTech, Buenas Prácticas Científicas, enValor, Nexofy, Bosque Innova, vigilancia competitiva, acompañamiento a empresas de base tecnológica.

Ese es el problema real de un portal así: cada programa tiene su público, su calendario y su convocatoria, pero todos comparten institución. Si cada uno se resuelve como una página suelta, el sitio se vuelve un directorio inconexo; si se homogeneiza demasiado, ninguno se entiende.

Se suma que el público es doble —investigadores por un lado, empresas por otro— y que la fundación tiene obligaciones de transparencia y canal de denuncias que no pueden quedar escondidas.

El objetivo

Que alguien que llega buscando una convocatoria concreta la encuentre, y que alguien que llega sin saber qué es la fundación entienda en un scroll las tres cosas que hace. Las dos entradas tenían que funcionar sin competir entre sí.

Y que el equipo pudiera abrir una convocatoria nueva o publicar un evento sin pedir un despliegue: en una fundación que vive de plazos, el contenido caduca solo.

Los desafíos

El modelo de contenidos fue el primero. Los programas se parecen lo suficiente para compartir plantilla y se diferencian lo suficiente para que una plantilla rígida los deforme. Se resolvió tratándolos como una familia con estructura común y bloques opcionales, en lugar de como páginas independientes.

Las convocatorias y eventos son contenido con fecha de caducidad, y necesitan su propio tipo: plazos, estado abierto o cerrado, y un archivo que siga siendo consultable después. No es una entrada de blog con una fecha encima.

El bilingüe no era traducir la interfaz: la versión en inglés tiene su propio recorrido de contenidos, con lo que interesa a un público internacional, y eso obliga a gestionar equivalencias entre idiomas y a declarar bien las alternativas para los buscadores.

La accesibilidad y la longevidad de las direcciones, que en una institución pública no son un extra: los enlaces a convocatorias se citan en documentos oficiales y tienen que seguir funcionando años después.

Cómo está construido

WordPress con tema propio, no con una plantilla comercial: la estructura de líneas, programas y convocatorias necesitaba componentes específicos que ninguna plantilla resolvía sin pelearse con ella.

El bilingüe se apoya en WPML, con el par español e inglés declarado por hreflang —incluido el x-default— para que cada buscador sirva la versión correcta y las dos no compitan entre sí en los resultados.

Las convocatorias y eventos viven en su propio tipo de contenido, con el plazo como dato de primera clase, y el buscador y las secciones de noticias y recursos se alimentan de ahí. La transparencia y el canal de denuncias están en la navegación principal, que es donde tienen que estar.

WordPressTema a medidaWPML · ES/ENConvocatoriasSEO técnico
07 / 12Certificación · Campus y app

GROUND

GROUND es un método de entrenamiento con el peso del cuerpo que certifica instructores en ediciones de ocho semanas. En sus tres primeras ediciones superó los 200 instructores certificados enseñando el método en todo el mundo.

El punto de partida

Certificar instructores en varios países a la vez rompe cualquier montaje improvisado. La formación tiene calendario y cohortes; los alumnos tienen que avanzar en orden; los eventos presenciales cambian de ciudad; y los instructores ya certificados necesitan aparecer en algún sitio donde alguien pueda encontrarlos.

Sin una plataforma detrás, cada edición nueva se gestiona como si fuera la primera, y el valor acumulado —la red de instructores— no queda registrado en ninguna parte.

El objetivo

Que una edición de la certificación pudiera abrirse, impartirse y cerrarse sin intervención técnica, y que al terminar el instructor pasara a formar parte de un directorio público y consultable.

Y que el método se pudiera practicar entre ediciones desde cualquier parte, lo que significaba entregarlo también como aplicación de entrenamiento.

Los desafíos

El primero fue la gestión por cohortes. Una certificación de ocho semanas no es un curso siempre abierto: los alumnos entran juntos, avanzan con un calendario y el acceso al contenido depende de la edición en la que estén. Eso exige separar los grupos y controlar qué ve cada uno y cuándo.

El segundo fue la matriculación. Cada edición incorpora a muchos alumnos de golpe, y darlos de alta a mano no es viable.

El tercero fue el directorio. «Dónde entrenar» tiene que filtrarse por país y por ciudad y mantenerse al día conforme se certifican instructores nuevos, sin convertirse en una lista que alguien edita a mano.

El cuarto, la app: publicar una aplicación en dos tiendas mientras se sigue desarrollando obliga a poder probar sin tocar los datos reales de los alumnos.

Cómo está construido

El campus es una plataforma de formación online con gestión de grupos, que es la pieza que permite tratar cada edición como una cohorte con su propio acceso al contenido, más alta masiva de alumnos por importación para que abrir edición no sea un trabajo manual.

La app de entrenamiento es Flutter con Firebase, construida con tres entornos completamente separados —desarrollo, preproducción y producción—, cada uno con su proyecto de Firebase y su identificador de aplicación. Se prueba en condiciones reales sin riesgo para los datos de producción.

La web pública sostiene la agenda de eventos y workshops y el directorio de instructores filtrable por país y ciudad, alimentado por los datos de las certificaciones.

08 / 12Inmobiliario · Plataforma de operaciones

Moana Deals

Moana Deals es una plataforma de operaciones inmobiliarias: permite localizar, analizar y cerrar transacciones en un mismo entorno, con red de inversores, preparación documental y salas de datos virtuales.

El punto de partida

Una operación inmobiliaria mueve mucha documentación sensible entre gente que no se conoce. En la práctica eso se gestionaba por correo: adjuntos que se reenvían, versiones que se solapan y ninguna trazabilidad de quién ha accedido a qué.

Además, las dos puntas del mercado no se encontraban de forma ordenada. El vendedor dependía de su red personal para llegar a inversores y el inversor recibía oportunidades sin criterio ni formato común.

El objetivo

Poner las tres figuras del proceso —vendedor, comprador y colaborador— dentro del mismo circuito, cada una viendo exactamente lo que le corresponde, y que la documentación dejara de viajar por correo para vivir en un espacio controlado.

Los desafíos

El control de acceso fue el eje del proyecto. No basta con tener usuarios registrados: la información de un activo se abre por capas, y quién puede ver la documentación completa depende del punto en el que esté la operación. El modelo de permisos condiciona todo lo demás.

El segundo desafío fue la ficha de activo. Los inmuebles que se listan son muy distintos entre sí y el comprador necesita compararlos, así que la ficha tenía que ser lo bastante rígida para permitir comparación y lo bastante flexible para no dejar fuera lo particular de cada operación.

El tercero, que la plataforma tenía que ser operable por un equipo de negocio, no de desarrollo: publicar un activo o abrir una sala de datos no puede requerir un despliegue.

Cómo está construido

Sobre WordPress, aprovechando su sistema de perfiles como base del control de acceso y extendiéndolo para los tres roles del negocio, de modo que el equipo administra usuarios y operaciones desde un panel que ya conoce.

La ficha de activo se resolvió con un modelo de campos propio, común a todos los listados, que es lo que hace posible el buscador con filtros y la comparación entre oportunidades.

La construcción de páginas se dejó en manos del equipo con un maquetador visual, para que campañas y secciones nuevas no dependan de nosotros.

09 / 12Industria · Campus de formación

Molecor

Molecor desarrolla y fabrica tecnología de tubería de PVC orientado, con presencia industrial en varios mercados. El campus de formación lleva su conocimiento técnico a equipos, filiales y distribuidores sin depender de formación presencial.

El punto de partida

Una compañía industrial con tecnología propia tiene un problema de transmisión: instalar y mantener su producto correctamente exige formación específica, y esa formación viajaba con las personas que la impartían.

Con varios países implicados, eso significa calendarios imposibles, contenido que se cuenta distinto según quién lo explique y ninguna forma de saber quién ha recibido qué.

El objetivo

Un campus donde el contenido técnico estuviera estructurado como formación —con orden, progresión y registro de quién lo ha completado— y disponible en el idioma de cada mercado.

Y que la operativa del día a día, que en un campus corporativo es sobre todo dar de alta gente y organizarla, no exigiera trabajo manual por cada alumno.

Los desafíos

El multi-idioma fue el primero, y no era solo traducir la interfaz: español, inglés y turco conviven con contenidos formativos propios de cada mercado, así que la plataforma tiene que servir versiones distintas del campus sobre una misma base.

El segundo fue la segmentación. Un empleado de fábrica, una filial y un distribuidor externo no deben ver el mismo catálogo, y esa separación tenía que poder gestionarse desde el panel, sin tocar código.

El tercero fue la incorporación de alumnos: los grupos entran por lotes, con sus datos ya existentes en los sistemas de la compañía, y darlos de alta uno a uno no era viable.

Cómo está construido

Una plataforma de formación online sobre WordPress, con el módulo de cursos, lecciones y evaluación como núcleo y una capa de grupos encima que es la que resuelve quién accede a qué catálogo.

El despliegue multi-idioma se organizó por instalaciones de mercado —español, inglés y turco— sobre una base común de tema y funcionalidad, de modo que cada mercado puede tener su contenido sin que evolucionen por separado.

La incorporación de alumnos se resolvió con importación masiva desde ficheros, con sus metadatos, y con sincronización de usuarios contra el sistema de identidad de la compañía, para que las altas no sean un trabajo manual repetido en cada edición.

LMSMulti-idioma ES · EN · TRGestión de gruposAlta masivaCloud
10 / 12Marca · De cero a presencia digital

JAB Solutions

JAB Solutions es la marca matriz que ordena dos negocios distintos —servicios de excavación y obra, y distribución de lubricantes industriales— bajo una misma promesa. El proyecto empezó en el diagnóstico, antes de escribir una línea de código.

El punto de partida

La empresa funcionaba y no existía digitalmente. El diagnóstico inicial encontró seis carencias que se alimentaban entre sí:

  • Invisibilidad digital: sin web, sin ficha de Google, sin redes ni contenidos.
  • Confusión de propuesta: el nombre «Excavaciones» no reflejaba la expansión a distribución.
  • Dependencia del producto: riesgo de comunicar las marcas que se distribuyen en vez de la confianza como distribuidor.
  • Fricción comercial: ni catálogo consultable, ni un flujo de cotización rápido.
  • Sin prueba social: faltaban casos, fotos y reseñas.
  • Sin datos: ninguna medición de leads, canales ni coste por oportunidad.

El objetivo

Construir una marca creíble y recordable que representara el servicio de distribución —asesoría, disponibilidad, velocidad, posventa— y no dependiera de las marcas del producto. La promesa se fijó en tres palabras: disponibilidad, asesoría técnica y respuesta rápida.

En paralelo, el objetivo digital era deliberadamente modesto y medible: ser encontrables, fiables y contactables. Nada más, y nada de eso a medias.

Los desafíos

El desafío de marca fue sostener dos líneas muy distintas —obra y distribución— sin que la matriz se volviera genérica ni ninguna de las dos quedara subordinada. Se resolvió con marca madre y versiones secundarias para cada línea.

La identidad cromática tenía que decir las dos cosas a la vez: un naranja industrial para la fuerza, la maquinaria y la acción; un azul profesional para la fiabilidad y la vocación técnica del área de distribución; y un neutro que sostuviera ambos sin ruido.

El desafío digital fue de secuencia. Con presupuesto contenido, el orden importa: primero encontrabilidad y confianza, después captación de pago, y solo escalar cobertura cuando la logística real pueda atenderla.

Cómo se resolvió

Una web MVP de una sola página, ampliable por bloques: propuesta y llamada a cotizar arriba, bloque de servicios, bloque de distribución con catálogo por marca, viscosidad y aplicación, la transición de Excavaciones JAB a JAB Solutions, casos y contacto.

Alrededor, los activos que hacen que esa web reciba visitas: ficha de Google Business Profile con categorías, horarios y servicios; perfil de WhatsApp Business con catálogo y respuestas rápidas; catálogo descargable en PDF con fichas de uso; y presencia en redes.

Y debajo, medición desde el primer día: etiquetado de campañas, conversiones de formulario y clics a WhatsApp atribuidos por canal. Sobre eso se monta la captación de pago, empezando por la zona inmediata de operación y abriendo cobertura por fases solo cuando el coste por oportunidad y la capacidad logística lo permiten.

Estudio de marcaIdentidad visualWeb MVPCatálogoGoogle Business ProfileMedición UTM
11 / 12Plataforma de reservas · Pago online

ITV A-42

ITV A-42 es una estación de inspección técnica de vehículos junto a la salida 59 de la A-42, en Olías del Rey (Toledo), con más de 2.500 m² de instalaciones y dos líneas de inspección. Construimos su plataforma de cita previa y pago online, con su back office completo.

El punto de partida

El negocio de una estación de ITV es capacidad de línea por franja horaria. Cuando la cita se da por teléfono ocurren tres cosas a la vez: se consume tiempo de personal que debería estar en la línea, la agenda se llena de forma irregular y no hay compromiso de pago, así que las ausencias salen gratis.

A eso se suma que el precio depende del tipo de vehículo y de inspección, y explicarlo por teléfono es lento y propenso a errores.

El objetivo

Que el ciclo completo —consultar precio, elegir hueco, pagar, recibir confirmación y poder anular— ocurriera sin que nadie de la estación interviniera, y que el equipo pudiera cambiar precios, horarios o textos de los correos sin pedirnos un despliegue.

Los desafíos

El pago fue el punto crítico. Cobrar online en España exige integrar la pasarela bancaria de referencia, y una pasarela redirigida se confirma por notificación del banco, no cuando el usuario vuelve a la web: si la reserva depende de que el navegador regrese, se pierden cobros y se duplican citas. La confirmación tenía que colgar de la notificación del banco, no del recorrido del usuario. Y con la devolución contemplada desde el principio, porque una anulación con dinero cobrado es lo normal, no la excepción.

El segundo desafío fue la concurrencia de la agenda. Dos personas mirando el mismo hueco a la vez es el caso habitual en las franjas buenas, y una plaza vendida dos veces se paga en el mostrador.

El tercero fue la integración con el sistema de la estación, que habla un protocolo de servicios web clásico. La plataforma nueva tenía que entenderse con lo que ya había en lugar de sustituirlo.

El cuarto, que casi todo el contenido operativo —precios, franjas, correos— cambia con frecuencia y no podía vivir en el código.

Cómo está construido

Next.js 15 con React 19 sobre MongoDB, con autenticación de sesión para el área de gestión e internacionalización de los textos desde el arranque.

El cobro se resuelve con la pasarela bancaria española y su circuito de notificación, pago y devolución, con la reserva confirmándose contra la notificación del banco. Convive con una integración de tarjeta alternativa para el resto de casos.

La agenda se actualiza en vivo mediante sockets, de modo que la disponibilidad que ve un usuario refleja lo que otro acaba de reservar. La localización se apoya en el mapa integrado, y la comunicación con el cliente en un sistema de plantillas de correo editables desde el panel.

El back office cubre la operación entera: panel de situación, reservas y sus pedidos, tarifas, usuarios con altas y edición, plantillas de correo, boletín y bandeja de contactos. La anulación de cita es pública y no exige cuenta, que es como la gente espera poder cancelar.

Next.js 15React 19MongoDBRedsysStripeNextAuthSocket.IOBack office
12 / 12Industria · Catálogo y distribuidores

JCHammer

JCHammer fabrica herramienta profesional para cubiertas desde 2003 —martillo magnético, hacha magnética, rodillo de corte, martillo de doble cabeza, soporte de cabina— nacida de la experiencia real en obra de su inventor.

El punto de partida

El producto tiene un argumento fuerte: equilibrio, ergonomía y estabilidad estructural, que se traducen en más control y menos fatiga en una jornada de tejado. Pero ese argumento se entiende en la mano, no en una foto.

Y hay una restricción de modelo de negocio que condiciona todo el sitio: la venta va por distribuidores autorizados. La web no cierra la operación, así que no puede medirse en carritos ni optimizarse como una tienda.

El objetivo

Que un profesional entienda por qué esta herramienta es distinta y termine en el distribuidor que le corresponde. Toda la navegación se diseñó apuntando a ese destino, en lugar de a un botón de compra que no existe.

Los desafíos

Comunicar una ventaja física por medios digitales. La diferencia está en el uso, así que la ficha de producto tenía que apoyarse en especificaciones concretas, opciones y fotografía en contexto real de trabajo, no en adjetivos.

El segundo desafío fue la ausencia de checkout. Sin conversión de compra, la estructura del sitio tiene que estar construida para llevar al usuario a la red de distribución sin que se sienta un callejón sin salida.

El tercero, que el catálogo crece: la familia de herramientas se amplía y cada una trae sus variantes, así que añadir producto no podía implicar rehacer plantillas.

Cómo está construido

WordPress con tema propio en lugar de una plantilla comercial: el catálogo tiene una estructura de ficha específica —herramienta, especificaciones, opciones, uso— que ninguna plantilla genérica resolvía sin pelearse con ella.

La composición de páginas se apoya en bloques reutilizables, de forma que el equipo puede montar una ficha nueva o una sección de campaña con las piezas ya existentes.

Sin comercio electrónico por decisión de modelo: el sitio es catálogo y captación, y la sección de distribuidores es el punto al que converge la navegación.

0%Preparando la escena