Durante mucho tiempo, WordPress ha estado ligado a una idea muy concreta: hacer webs. Pero cuando empiezas a trabajar con él en proyectos más complejos, te das cuenta de algo importante. WordPress no es solo una herramienta para publicar contenido. Puede ser la base de un producto. Y sí, también de un SaaS.
Lo primero que cambia es la mentalidad. Un SaaS no es un proyecto que se entrega y se cierra, es un sistema que evoluciona constantemente, que tiene usuarios, datos, lógica de negocio y, sobre todo, una responsabilidad continua. Si intentas montar algo así con la mentalidad de “instalo WordPress y añado plugins”, te vas a quedar corto muy rápido.
Necesitas empezar por la base. Una estructura sólida que te permita crecer sin romper lo anterior. Aquí es donde tiene sentido trabajar con herramientas como Bedrock, gestionar dependencias con Composer y separar claramente configuración, código y contenido. No es obligatorio, pero es lo que marca la diferencia cuando el proyecto empieza a escalar.
Después viene algo que muchos pasan por alto: los entornos. Un SaaS no puede depender de cambios directos en producción. Necesitas desarrollo, staging y producción bien definidos, con despliegues controlados y reproducibles. Aquí entran en juego pipelines, automatización y un flujo de trabajo claro. Porque en un SaaS, cada cambio afecta a usuarios reales.
La gestión de usuarios es otro punto clave. No se trata solo de registrar usuarios, sino de definir roles, permisos, accesos a funcionalidades y, en muchos casos, planes de suscripción. WordPress tiene una base sólida para esto, pero normalmente hay que extenderla para adaptarla al modelo de negocio. Es en este punto donde deja de comportarse como un CMS y empieza a funcionar como una plataforma.
Luego está el tema de los datos. Un SaaS vive de los datos. Necesitas saber qué hacen los usuarios, cómo interactúan, dónde fallan, qué utilizan más. Esto implica logs, métricas, monitorización y, en muchos casos, integraciones con herramientas externas. Sin visibilidad, no hay evolución.
También necesitas pensar en la arquitectura. No todo tiene que vivir dentro de WordPress. De hecho, muchas veces tiene sentido desacoplar ciertas partes: APIs externas, servicios específicos o procesos asíncronos. WordPress puede ser el núcleo, pero no tiene por qué serlo todo. Encontrar ese equilibrio es clave.
La automatización deja de ser opcional. Despliegues, tareas recurrentes, limpieza de datos, generación de informes… todo lo que puedas automatizar reduce errores y libera tiempo. Aquí WP-CLI, cron jobs o integraciones con otros sistemas pasan a ser parte natural del proyecto.
Y hay algo que muchas veces se subestima: la experiencia de usuario. Un SaaS no se usa una vez, se usa todos los días. La interfaz, los flujos, la claridad de las acciones… todo influye directamente en la retención. Y eso no te lo da WordPress por defecto, hay que diseñarlo.
Montar un SaaS con WordPress no va de usar WordPress como siempre. Va de usarlo como base. Como una plataforma sobre la que construir algo más grande, más estructurado y más controlado.
¿Es la única opción? No. ¿Tiene sentido? En muchos casos, sí. Sobre todo cuando necesitas lanzar rápido, iterar y apoyarte en una base que ya resuelve muchos problemas complejos.
Porque al final, montar un SaaS no va de la tecnología que eliges.
Va de cómo la utilizas.
Y ahí es donde realmente empieza todo.