--- title: "Construir admin panel para CMS a medida con auth en LATAM" description: "Guía operativa para construir un admin panel CMS con autenticación, RBAC, audit log y editor de contenido propio. Stack y módulos clave." slug: "construir-admin-panel-para-cms-a-medida-con-auth" url: "https://catalizadora.ai/blog/construir-admin-panel-para-cms-a-medida-con-auth" cluster: "software-medida/construir-admin-panel" author: "Pablo Estrada" published_at: "2026-05-11T12:00:00+00:00" updated_at: "2026-06-19T19:59:51.42746+00:00" read_minutes: "5" lang: "es" --- # Construir admin panel para CMS a medida con auth en LATAM > Guía operativa para construir un admin panel CMS con autenticación, RBAC, audit log y editor de contenido propio. Stack y módulos clave. Construir un admin panel para CMS a medida con auth cuesta entre 15,000 y 25,000 USD, se entrega en 8 a 12 semanas y se justifica cuando tu flujo editorial tiene más de 3 roles, contenido multilenguaje o publicación condicional. La trampa común es empezar por el editor WYSIWYG bonito. La forma correcta es empezar por RBAC en base de datos con Row Level Security, audit log inmutable y autenticación con refresh tokens cortos. Software a tu nombre, no prestado. Si tu equipo editorial usa WordPress con plugins acumulados, Sanity Studio con costos creciendo por usuario, o Strapi con parches a medida que no resisten una migración, este artículo te dice qué construir y en qué orden. ## Cuándo construir a medida vs. usar CMS headless La regla operativa de Catalizadora es la siguiente: si tu flujo editorial cabe en una matriz de 3 roles por 2 idiomas con publicación inmediata, usa Sanity, Strapi o Directus. Si necesitas más de 5 roles cruzando categorías de contenido, workflow de aprobación multi-paso, contenido condicional por cliente o integración bidireccional con un sistema interno, construir a medida sale más barato en 18 meses. El error frecuente es elegir mal el corte. Una redacción de 6 personas en un medio digital regional con publicación programada en 4 idiomas no cabe en WordPress sin 12 plugins ni en Sanity sin custom code que pelea con la SDK. Para ese tamaño, construir a medida con MAGIA Forge en 12 semanas suele ser la decisión correcta. ## Los 7 módulos no negociables | Módulo | Función | Complejidad | |---|---|---| | Autenticación con refresh tokens | Login persistente, expiración corta de access tokens | Media | | RBAC en base de datos con RLS | Permisos no saltables por curl directo | Alta | | Editor WYSIWYG con bloques | Tiptap, Lexical o Slate sobre estructura propia | Media | | Versionado de contenido | Historia de cambios y rollback por artículo | Media | | Audit log inmutable | Quién hizo qué, cuándo y desde qué IP | Baja | | Programación de publicación | Cron interno o job queue para releases futuras | Baja | | Asset library con CDN | Imágenes optimizadas servidas por CDN | Media | El módulo de versionado es donde más implementaciones se rompen. La opción incorrecta es guardar el documento completo en cada save, generando tablas de 50 GB para sitios medianos. La opción correcta es event sourcing ligero: tabla de eventos JSON con diff entre versiones y materialización solo para lectura. ## El caso real: RLS multi-tenant para 100 franquicias En un proyecto de plataforma multi-tenant para 100 franquicias internacionales, el módulo de control de accesos se construyó así: - 7 roles RBAC jerárquicos definidos en tabla configurable: admin global, admin regional, dueño de franquicia, admin de franquicia, gerente de franquicia, usuario de franquicia y auditor externo - Custom JWT claims con oficina_id y franquicia_id que viajan en cada request - Row Level Security en cada tabla sensible usando funciones auth.user_oficina_id y auth.user_role - Audit log con SHA-256 hash chain inmutable, DENY UPDATE y DENY DELETE en RLS para garantizar append-only - Session mode pooler de Supabase para conexiones de larga duración El patrón se traduce directo a un CMS multi-redacción: cada redactor solo ve los artículos de su sección o idioma, el editor jefe ve todo, el auditor ve solo el log. Si lo modelas en motor de base de datos, ningún frontend roto te expone datos. ## Stack recomendado en 2026 Para una redacción de 3 a 15 personas con 1,000 a 100,000 artículos, este stack es el más rápido de poner en producción: - Frontend en Next.js 15 con App Router, RSC y server actions para mutaciones simples - API en FastAPI o NestJS con OpenAPI generado automático para el cliente tipado - Base de datos PostgreSQL 16 con extensiones pg_trgm para búsqueda y RLS para permisos - Autenticación con Supabase Auth o Clerk, refresh tokens de 7 días y access tokens de 1 hora - Storage con Supabase Storage o S3 + CloudFront, URLs firmadas de corta duración - Editor WYSIWYG con Tiptap sobre ProseMirror, output estructurado en JSON no en HTML - Audit log en tabla append-only con trigger SQL que firma SHA-256 hash chain - Búsqueda con Meilisearch o Typesense, NO Elasticsearch para menos de 1 millón de docs Evitar al inicio: Kafka, Kubernetes, microservicios y service mesh. Para una redacción de 15 personas un monolito modular en una sola VM con Postgres administrado alcanza con margen. ## Errores comunes en CMS a medida Cinco errores que vemos repetir al auditar CMS hechos a medida: 1. RBAC implementado solo en middleware del frontend, sin RLS en base de datos 2. Almacenar HTML del editor en lugar de estructura JSON, imposible migrar después 3. Sin versionado de contenido desde el día 1, primer error humano destruye trabajo 4. Sin audit log, no se puede demostrar quién publicó qué para compliance 5. Búsqueda con LIKE de SQL en tabla grande, queries de 4 segundos cuando hay 20,000 artículos La forma correcta de evitarlos es definirlos en la fase de Arquitectura, no agregarlos como parche en producción. Cada hallazgo se convierte en módulo, cada módulo mapea un dolor real. ## Próximos pasos Si tu redacción tiene más de 5 personas, más de 2 idiomas o workflow editorial con aprobación, [MAGIA Forge](https://catalizadora.ai/magia/forge) entrega el admin panel CMS a medida en 12 semanas por 20,000 USD, código y datos a tu nombre, sin licencias por usuario. Si lo que tienes es una redacción de 1 a 3 personas con publicación inmediata, [MAGIA Solo](https://catalizadora.ai/magia/solo) en 15 días por 4,500 USD cubre el caso con web editorial, SEO y bot WhatsApp incluidos. Contexto adicional en [Wikipedia: Content management system](https://en.wikipedia.org/wiki/Content_management_system). ## Preguntas frecuentes ### ¿Por qué no usar Strapi, Directus o Sanity como CMS headless? Funcionan para 80% de los casos. El 20% que requiere auth bidireccional con tu sistema actual, RBAC granular por tipo de contenido y flujo editorial complejo termina peleándose con la abstracción del CMS y pierde más en parches que en construir a medida. ### ¿Cuál es la stack mínima viable para un admin panel CMS custom? Next.js o Remix para frontend, NestJS o FastAPI para API, PostgreSQL con RLS para datos, Supabase Auth o Clerk para autenticación, S3 o Supabase Storage para adjuntos y audit log append-only en tabla aparte. ### ¿Cuánto cuesta construir un admin panel CMS a medida desde cero? Entre 15,000 y 25,000 USD para un equipo de redacción de 3 a 15 personas con flujo editorial multi-paso. Incluye RBAC, audit log, editor WYSIWYG, versionado y publicación programada. 8 a 12 semanas en producción. ### ¿Cómo se hace el RBAC por tipo de contenido y por idioma? Tabla user_roles con columna context_type y context_id. Editor en español puede tener rol editor en posts y rol viewer en pages. PostgreSQL Row Level Security lo aplica en motor, no en frontend, así no se puede saltar por curl directo. ### ¿Necesito Redis o cola de mensajes para empezar? No. PostgreSQL alcanza para 95% de los CMS con menos de 100,000 artículos. Redis y RabbitMQ se agregan cuando hay procesamiento de imágenes en background, búsqueda full text avanzada o más de 50 editores concurrentes. --- Source: https://catalizadora.ai/blog/construir-admin-panel-para-cms-a-medida-con-auth Author: Pablo Estrada — AI Catalyst, LLC (catalizadora.ai)