LMS V2: modernizar sin incendiar la casa
Reescribir todo desde cero casi nunca es estrategia. A veces es ansiedad con presupuesto.
De deuda silenciosa a evolución controlada
El sistema funcionaba. Ese era exactamente el problema.
La deuda técnica más incómoda no siempre rompe el producto. A veces lo mantiene andando, pero vuelve cada mejora más lenta, más riesgosa y más difícil de sostener.
Antes: deuda silenciosa
- Servicios dispersos
- Lógica duplicada
- Estilos poco gobernados
- Componentes difíciles de reutilizar
Después: evolución controlada
- API centralizada
- Contratos claros
- Rutas gobernadas
- Tests y build reproducible
La deuda técnica no siempre se ve como caos.
A veces se ve como algo mucho más peligroso: un sistema que funciona.
Cuando empezamos a revisar el estado actual del LMS de PLG, encontramos algo muy común en productos reales: una base funcional que sí resolvía la operación, pero que también cargaba deuda técnica acumulada.
Autenticación, roles, rutas por tipo de usuario, clases, reportes, procesos académicos, estudiantes, profesores y operación diaria.
El sistema funcionaba. Y justamente por eso había que tener cuidado.
“Esto está viejo, hagámoslo todo otra vez” suena moderno. También puede ser la forma más elegante de incendiar la casa.
El problema no era que existiera una V1.
En un LMS real, donde hay estudiantes, profesores, datos académicos, procesos activos e integraciones existentes, “reescribir todo” puede sonar menos a innovación y más a:
“vamos a romper todo, pero con buena intención”.
Y ese no era el camino.
La deuda más importante no era “código viejo”.
Era la falta de límites explícitos.
Muchas pantallas resolvían problemas reales, pero cada una a su manera. Unas con lógica duplicada. Otras con responsabilidades mezcladas. Otras con interfaz, estado, API y reglas de negocio viviendo en el mismo apartamento, sin contrato de arriendo y con problemas de convivencia.
Fronteras claras
Separar UI, estado, consumo de API y reglas de negocio.
Contratos explícitos
Formalizar errores, sesión, permisos, rutas e integraciones.
Confianza operativa
Construir pruebas, gates y observabilidad para mejorar sin rezar antes del deploy.
El backend no era el enemigo.
La fuente de verdad del LMS seguía siendo crítica: clases, reportes, procesos, usuarios y datos académicos.
El objetivo no era reemplazar todo por deporte.
Era ordenar cómo se exponía, cómo se consumía y cómo se protegía la compatibilidad con lo que ya usaban estudiantes, profesores, mobile, scripts e integraciones existentes.
Modernizar no es negar lo anterior. Es entender qué debe mantenerse, qué debe aislarse y qué debe reconstruirse con criterio.
Menos cirugía con motosierra. Más evolución con bisturí.Por eso no hicimos un refactor masivo.
La ruta fue crear una plataforma frontend V2, mantener V1 operable y migrar por cortes gobernados.
Eso significa convivir con el LMS actual, proteger los flujos existentes y construir una base nueva para reducir riesgo.
- Vite
- React
- TypeScript
- Rutas controladas
- Estructura por features
- UI primitives
- Data layer compartido
- Pruebas
- Build reproducible
- Contratos con backend
El cambio importante no es solo el stack.
El cambio importante es la mentalidad.
Una plataforma no se construye para que el código se vea bonito en GitHub. Se construye para reducir riesgo, acelerar mejoras y darle al equipo una base confiable para seguir creando producto.
Mantener V1 operable
No se apaga la operación para sentirse moderno.
Aislar lo legacy
Primero se definen límites. Después se migra.
Formalizar contratos
Sesión, errores, permisos, rutas, datos e integraciones necesitan acuerdos claros.
Migrar por cortes gobernados
Cada mejora debe tener alcance, evidencia, pruebas y criterios de cierre.
El LMS no partía de cero.
Partía de algo más difícil: un sistema usado, con historia, usuarios, flujos críticos y decisiones acumuladas.
Ahí se nota la diferencia entre hacer tecnología por ego y construir producto con responsabilidad.
Porque en tecnología educativa, la velocidad importa. Pero la confianza importa más.
Construir EdTech real no es decorar procesos con tecnología.
Es hacer que el producto mejore sin que estudiantes, profesores y equipo tengan que pagar el costo de nuestras ganas de “modernizar”.
Y sí, eso es menos glamuroso que anunciar una reescritura total. Pero también es mucho más serio.
La pregunta no es: “¿qué tan nuevo se ve el stack?”
La pregunta es: “¿qué tan confiable es la base sobre la que vamos a seguir creciendo?”
Porque en EdTech, si la tecnología no mejora la experiencia real de aprendizaje y la operación académica, entonces no es innovación.
Es decoración técnica.
Y para decoración ya tenemos Canva.
