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:
- RBAC implementado solo en middleware del frontend, sin RLS en base de datos
- Almacenar HTML del editor en lugar de estructura JSON, imposible migrar después
- Sin versionado de contenido desde el día 1, primer error humano destruye trabajo
- Sin audit log, no se puede demostrar quién publicó qué para compliance
- 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 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 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.