El panel admin que se adapta: CMS dinámico para negocios reales

La primera capa del CMS dinámico es el sistema de features. Cada tenant tiene un registro en la base de datos central que define qué módulos están activos.

Cuando el admin de la inmobiliaria abre el panel, ve el módulo de propiedades, el de contratos, el de portal de inquilinos, el de pagos. No ve el módulo de productos, porque no tiene ecommerce. No ve el constructor de menú estilo restaurante.

Eso no es solo UI. El backend verifica las features en cada request. Si el tenant no tiene ecommerce habilitado y llega una request a `/api/products`, el featureGuard devuelve 403. La configuración de features no es cosmética — es el contrato de lo que existe para ese cliente.

Esto significa que podemos incorporar un cliente nuevo sin crear un backend personalizado. Habilitamos las features que necesita, configuramos el schema de contenido, y el sistema funciona. Si meses después necesita un módulo adicional, se habilita sin código nuevo.

La segunda capa es el sistema de contenido: todos los textos, imágenes de fondo, configuración de navegación y metadata de SEO que el cliente puede editar sin tocar código.

El modelo es simple: una tabla `site_contents` con pares clave-valor. La clave sigue un patrón jerárquico: `home.hero.title`, `contact.page.form.button`, `settings.siteMeta.description`. El valor puede ser texto plano o JSON, dependiendo del tipo declarado.

El admin expone un editor visual para cada clave. El cliente ve el campo "Título del hero", escribe el nuevo texto, guarda. El sitio lo muestra en tiempo real en el próximo request.

El frontend consume esos valores a través del endpoint `/api/site-contents`. El service los normaliza: los campos de texto se asignan directamente, los campos JSON se parsean y se distribuyen a la estructura de cada página.

La tentativa inicial es construir un editor genérico: una tabla con todas las claves y sus valores, donde el admin puede editar cualquier cosa. Es fácil de implementar y funciona técnicamente.

El problema es que "funciona técnicamente" no es suficiente. Un campo que dice `home.hero.metrics` con un JSON array de objetos no le dice nada a un cliente que no sabe qué es un JSON array. El editor tiene que traducir el modelo de datos a términos del negocio.

Lo que construimos tiene dos niveles: un editor estructurado por sección (Hero, Servicios, Contacto, etc.) con campos rotulados en lenguaje del cliente, y un editor raw para los campos que no tienen editor estructurado todavía. Con el tiempo, los campos más usados migran al editor estructurado.

La tercera capa es la más familiar: un editor WYSIWYG para publicaciones de blog. Título, contenido enriquecido, imagen destacada, categorías, tags, estado de publicación.

Lo que lo hace interesante en el contexto multi-tenant es que cada cliente tiene sus propias categorías y tags. Los posts de la inmobiliaria tienen categorías como "Noticias del mercado" y "Consejos para inquilinos". Los posts del estudio tienen "Proyectos" y "Process".

El editor no sabe qué cliente está editando — recibe una lista de categorías y tags del tenant activo y las muestra. El mismo componente sirve para todos.

Todo lo que es contenido: textos del sitio, imágenes, posts del blog, servicios, proyectos, testimoniales. Todo lo que es configuración: metadata de SEO, idiomas activos, configuración de navegación.

Lo que no puede editar sin intervención: el diseño visual, la estructura de páginas, features nuevas. Eso sigue siendo código. Pero es una fracción pequeña de lo que los clientes cambian en el día a día.

La mayoría de los cambios que un negocio necesita hacer en su sitio web son de contenido. Esa es la parte que tiene que ser fácil.