Mejorando seguridad y rendimiento del SaaS (Antes de que todo explotara) - Episodio 5

No todo es maravilloso ni de color de rosa.

A veces, pasan cosas...

Ya ves si pasan....

En este post te cuento lo que me pasó cuando creía que todo iba bien...

📅 Diario de un SaaS: Mejorando seguridad y rendimiento (Antes de que todo explotara)

🚀 La calma antes de la tormenta

Cuando construyes un SaaS desde cero, es fácil obsesionarte con agregar funcionalidades y dejar en segundo plano cosas como la seguridad y el rendimiento. Y claro, mientras todo parece ir bien, no sueles preguntarte qué podría salir mal.

💥 Spoiler: muchas cosas pueden salir mal.

Llevaba semanas trabajando en mi plataforma, añadiendo mejoras en la gestión de datos y optimizando la experiencia del usuario. Todo parecía estable. Pero antes de seguir añadiendo más características, decidí hacer una pausa para fortalecer la seguridad y mejorar la eficiencia de las consultas.

Una decisión inteligente, ¿no? Pues sí… y no.

Lo que no sabía era que esto me llevaría a descubrir un problema mucho más grande.

Uno que no tenía nada que ver con el código, pero que podía hacer que todo se fuera al traste.

---

🔐 Seguridad primero: autenticación con JWT y roles

Hasta este punto, la autenticación en mi SaaS era básica: un simple sistema de usuario y contraseña. Suficiente para empezar, pero claramente insuficiente para un sistema que necesita seguridad y control de accesos.

Así que decidí implementar JWT (JSON Web Tokens) para gestionar autenticación y permisos. Con esto:

✅ Los usuarios ahora tienen roles (compradores, vendedores, administradores).
✅ Cada uno solo puede acceder a lo que le corresponde.
✅ Se sienta la base para futuras funcionalidades avanzadas.

📌 Resultado: Un sistema más seguro y escalable, sin depender de sesiones en el servidor.

Me sentí bien.

Todo parecía bajo control.

Pero mientras optimizaba mi código, había algo que estaba ignorando por completo… y que pronto me explotaría en la cara.

---

⚡ Optimizando la base de datos: más rápido, más eficiente

Otro problema que no podía ignorar era la velocidad de las búsquedas. PostgreSQL es potente, pero si no optimizas, las consultas se vuelven un cuello de botella.

Para evitarlo, implementé Full-Text Search.

🔍 ¿Qué conseguimos con esto?
✔ Búsquedas más rápidas, incluso con grandes volúmenes de datos.
✔ Mejor experiencia de usuario, encontrando información de forma más precisa.
✔ Menos carga en el servidor, gracias a índices optimizados.

📌 Resultado: Las consultas pasaron de ser un proceso lento a ejecutarse en milisegundos.

Otra victoria.

Todo parecía ir viento en popa…

Hasta que se me ocurrió la genial idea de migrar todo el sistema que tenía en local a un VPS.

---

💡 El error que no vi venir: la migración al VPS

Hasta este punto, mi SaaS había estado funcionando en local, lo que me permitía desarrollar con flexibilidad sin preocuparme demasiado por la infraestructura. Pero en algún momento, era necesario dar el salto y desplegarlo en un VPS para hacerlo accesible de forma real.

Ese fue el plan. Lo que no esperaba era lo que venía después.

El proceso de migración parecía sencillo: subir el código, configurar la base de datos y arrancar los servicios. Pero en cuanto intenté poner todo en marcha, nada funcionaba como esperaba.

🔹 La API no respondía, aunque en local todo iba bien.
🔹 La base de datos no se conectaba correctamente.
🔹 Los logs no mostraban errores claros, pero el VPS simplemente no ejecutaba mi aplicación como debía.

Lo primero que pensé fue que era un problema menor. Revisé la configuración, ajusté permisos, reinicié los servicios… y nada.

Aquí fue donde me di cuenta del problema real.

🛑 Había asumido que la configuración de un servidor en producción era igual a la de un entorno local.

Era una solución cómoda y funcional en mi equipo, pero al llevarlo a un VPS, me encontré con un montón de configuraciones que no había considerado. Desde la gestión de dependencias hasta la configuración del firewall, cada pequeño detalle contaba, y no estaba listo para ello.

Lo peor vino cuando, tras varios intentos de ajuste, me di cuenta de que mi configuración de base de datos no era óptima y podía poner en riesgo el rendimiento del SaaS desde el día uno.

---

📌 Lecciones aprendidas

Si tuviera que resumir lo que aprendí en esta fase del proyecto, sería esto:

✅ No asumas que lo que funciona en local funcionará en producción sin ajustes. Hay muchas variables en juego en un entorno real, y cada detalle de configuración cuenta.

✅ No subestimes la complejidad de una migración. Aunque parezca que es solo "subir archivos y ejecutar", en la práctica implica entender bien cada componente y cómo interactúan en un VPS.

✅ La infraestructura importa tanto como el código. No basta con que el SaaS esté bien programado; necesita una base sólida para funcionar de manera estable.

---

🔜 Lo que viene: una decisión clave

Después de este desafío, me encontré con una pregunta que definiría el futuro del proyecto:

🔹 ¿Seguir con este VPS o evaluar una infraestructura más robusta y optimizada para producción?

En el próximo post te contaré cómo la lié parda con mi VPS. 🚀

📌 ¿Has tenido problemas migrando proyectos a producción? Cuéntamelo en los comentarios. 😊

Si quieres conocer otros artículos parecidos a Mejorando seguridad y rendimiento del SaaS (Antes de que todo explotara) - Episodio 5 puedes visitar la categoría Proyecto-IA.