Corregir, completar o reconstruir la plataforma actual — con una herramienta que le devuelve a la editorial la capacidad de publicar su propio contenido
Editorial Encuentro ya tiene una plataforma en operación, usada a diario por colegios reales. Esta propuesta parte de un diagnóstico técnico completo de esa plataforma y ofrece tres caminos, de menor a mayor alcance.
Antes de proponer nada se hizo una auditoría técnica completa: infraestructura, código fuente, base de datos y uso real. Estos son los hechos que sustentan las tres opciones.
En el último mes: 179 estudiantes de 12 colegios y 32 docentes resolvieron 838 actividades. Hay programaciones cargadas hasta diciembre. En cinco meses se registraron 344 estudiantes nuevos.
Colegios, cursos, docentes, matrícula con código del libro, programación de actividades con fechas, calificaciones y reportes: todo eso existe y funciona bien. No hay que reconstruirlo.
La política de backups automáticos está en estado de error desde septiembre de 2025. Si hoy falla el disco, se pierde todo lo producido desde entonces.
La plataforma está en modo depuración: cualquier visitante que provoque un error ve las credenciales de la base de datos en pantalla.
Comprobado en vivo: un colegio puede leer los datos personales de estudiantes de otro colegio —documento, fecha de nacimiento, acudiente— cambiando un número en la dirección. Es incompatible con la Ley 1581 de habeas data.
Sistema operativo, lenguaje, framework y base de datos están fuera de soporte al mismo tiempo, algunos desde hace cinco años. Una auditoría de dependencias encontró 83 vulnerabilidades conocidas —37 críticas o altas— incluidas las librerías que generan los PDF y Excel de calificaciones.
Unos 110 errores al día. Dos funcionalidades completas nunca llegaron a funcionar desde que se escribieron, y nadie lo notó porque no hay monitoreo ni pruebas automatizadas.
El límite de fondo no es la antigüedad del código. Es que el contenido pedagógico está programado a mano —651 actividades escritas una por una— y la herramienta con la que el equipo de diseño las producía dejó de existir. Hoy la editorial no puede publicar contenido nuevo, y eso no lo resuelve actualizar el framework. Por eso las opciones Actualización y LMS nuevo incluyen una herramienta de autoría (Capítulo 07).
Se construye un LMS multitenant con panel maestro para la editorial y espacios aislados por colegio. El estudiante que compra un libro original se registra con el PIN impreso en el texto, queda matriculado automáticamente en su colegio y curso, y accede a su libro digital, a los textos de cortesía que la editorial le active y a la vitrina con los demás títulos de su grado.
Panel maestro: colegios, cursos, docentes, catálogo por grado, generación de lotes de PINes, licencias por año lectivo y analíticas globales.
Selecciona colegio y grado, ingresa el PIN del libro y en menos de dos minutos está dentro de su curso con su texto digital activado.
Sus cursos llegan preconfigurados por la editorial. Habilita actividades y evaluaciones, hace seguimiento y exporta notas.
Stack definitivo: Frontend en Next.js 15 (React, App Router, RSC). Backend en NestJS + TypeORM + PostgreSQL. Todo TypeScript — los tipos de la API se comparten entre frontend y backend vía un Nx Monorepo. Esta arquitectura corresponde a la opción LMS nuevo. Las opciones Correcciones y Actualización trabajan sobre la plataforma actual, actualizándola a versiones con soporte.
Un solo enlace, cada colegio aislado por dentro. Todos los colegios entran por la misma dirección principal. Al crear un colegio, la plataforma le genera automáticamente su propio espacio de datos, y a partir de ahí toda consulta queda filtrada por ese espacio sin que un programador tenga que recordarlo. Así, un colegio nunca puede ver ni tocar la información de otro — la falla de aislamiento que hoy existe en la plataforma actual queda resuelta de raíz, no parcheada consulta por consulta. Si en el futuro la editorial quisiera que cada colegio tuviera además su propia dirección con su marca (por ejemplo sucolegio.editorialencuentro.com), se suma como complemento sin rehacer nada.
Dos vías de ingreso: el PIN es la vía principal. Adicionalmente, la plataforma soporta matrícula administrada — carga masiva de estudiantes por Excel/CSV o creación manual — para colegios que prefieran entregar las cuentas ya creadas; el PIN del libro se vincula igualmente a cada cuenta para conservar el control anti-piratería.
La editorial activa en bloque, por colegio o por curso, textos digitales adicionales — por ejemplo, quien compró Matemáticas y Lenguaje físicos recibe Ciencias y Sociales en digital. Solo lectura, sin actividades ni evaluaciones. El libro digital se genera a partir del PDF que entrega la editorial (Capítulo 07); la plataforma lo publica en el visor protegido.
El estudiante ve las carátulas de los demás libros de su grado en modo desactivado. Cuando compra el libro físico, ingresa el nuevo PIN y el título se activa al instante — el catálogo completo trabaja para el equipo comercial de la editorial.
Las opciones Correcciones y Actualización actualizan la plataforma actual a versiones con soporte. El LMS nuevo la reconstruye en TypeScript de punta a punta.
Las opciones Correcciones y Actualización no cambian de tecnología: trabajan sobre el sistema que hoy está en producción y lo llevan a versiones vigentes. Es la diferencia de fondo con la opción LMS nuevo, que es una plataforma nueva.
| Componente | Hoy | Después de la intervención | Por qué importa |
|---|---|---|---|
| Sistema operativo | Ubuntu 18.04 | Versión LTS con soporte | Sin soporte estándar desde mayo de 2023: no recibe parches de seguridad |
| Lenguaje | PHP 7.3 | PHP 8.2 o superior | Fin de vida en diciembre de 2021. Es el salto más grande y el que concentra el riesgo |
| Framework | Laravel 8 | Versión con soporte activo | Sin parches de seguridad desde enero de 2023 |
| Base de datos | MySQL 5.7 | MySQL 8 | Fin de vida en octubre de 2023 |
| Servidor web | Apache 2.4 | Apache actualizado | Se conserva; solo se actualiza y se corrige la configuración de la raíz pública |
| Pruebas automatizadas | Ninguna | Cobertura de los flujos críticos | Hoy la cobertura es cero, y por eso hubo funcionalidades rotas durante años sin que nadie lo notara |
Por qué conservar la tecnología actual en estas dos opciones: la plataforma está en uso a diario por colegios reales, con actividades programadas hasta fin de año. Actualizar por etapas —con un entorno espejo y pruebas antes de cada paso en producción— permite mejorarla sin interrumpir el año lectivo. Cambiar de tecnología obliga a reescribirlo todo, y eso es la opción LMS nuevo.
El entorno espejo ya está montado. Durante la auditoría se levantó una réplica local con las versiones exactas de producción y una copia de la base de datos real. Ese mecanismo —probar antes de aplicar— queda disponible desde el primer día del proyecto.
El monorepo Nx no es solo organización de código — es la decisión que hace posible compartir interfaces TypeScript entre Next.js y NestJS, y que permite pasar de la opción Correcciones a la opción LMS nuevo agregando módulos sin tocar los existentes.
ActivationDto, el frontend Next.js falla en compilación antes de llegar a producción. Cero errores de integración API.
Por qué NestJS y no Express u otro framework Node: NestJS tiene un sistema de módulos con inyección de dependencias que replica exactamente la arquitectura de microservicios — solo que todo corre en el mismo proceso. Cuando el crecimiento lo exija, @nestjs/microservices permite separar módulos con un cambio de configuración. Express no tiene ese concepto — habría que reescribir la comunicación desde cero.
La columna marcada indica que la funcionalidad queda operativa al terminar esa opción. Varias ya existen hoy y funcionan bien: se conservan. Todo lo marcado está incluido en el precio.
| Funcionalidad | Correcciones | Actualización + autoría |
LMS nuevo | Detalle |
|---|---|---|---|---|
| Estado técnico, seguridad y operación | ||||
| Corrección de los errores del diagnóstico | ✓ | ✓ | ✓ | Los 10 errores catalogados, incluidas las dos funcionalidades que nunca llegaron a funcionar |
| Cierre de brechas de seguridad | ✓ | ✓ | ✓ | Modo depuración desactivado, credenciales rotadas, consultas parametrizadas, discos cifrados |
| Cierre de las 83 vulnerabilidades de dependencias | ✗ | ✓ | ✓ | Actualización de las librerías con CVEs conocidos (dompdf, phpspreadsheet, guzzle, commonmark y más). En la opción LMS nuevo no aplican: la plataforma se construye con dependencias actuales |
| Aislamiento real entre colegios | ✓ | ✓ | ✓ | Hoy todos los colegios comparten el mismo sistema y la separación depende de un filtro escrito a mano en cada consulta; algunas rutas de edición no lo aplican, de modo que un colegio podría acceder a docentes o estudiantes de otro cambiando el identificador en la petición. Se corrige verificando la pertenencia en cada acceso, no solo en los listados |
| Multi-tenant automático por colegio | ✗ | ✗ | ✓ | En la plataforma nueva, cada colegio queda aislado de raíz: al crearse, el sistema genera su propio ámbito de datos y toda consulta se filtra por ese ámbito de forma automática, sin depender de que un programador lo recuerde. Todos los colegios usan el mismo enlace principal; la separación es interna y no se puede saltar. En las opciones Correcciones y Actualización el aislamiento se refuerza corrigiendo las consultas, pero no cambia el modelo de la plataforma actual |
| Actualización de la pila tecnológica | ✗ | ✓ | ✗ | Sistema operativo, PHP, framework y base de datos a versiones con soporte. En la opción LMS nuevo no aplica: la pila es nueva |
| Backups automáticos verificados | ✓ | ✓ | ✓ | Reparación de la política de respaldos y prueba real de restauración |
| Monitoreo que sí avisa | ✓ | ✓ | ✓ | Reemplaza el vigilante actual, que no vigila nada. Alertas por caída, errores y disco |
| Tests automatizados sobre los flujos críticos | ✓ | ✓ | ✓ | Hoy la cobertura es cero: por eso hubo funcionalidades rotas durante años sin que nadie lo notara |
| Corrección del patrón de fallos por datos faltantes | ✓ | ✓ | ✓ | 35 puntos del código usan un resultado de consulta sin verificar que exista, y cada uno puede mostrar la pantalla de error con credenciales. Se corrigen todos con un patrón seguro, no caso por caso |
| Optimización del costo de infraestructura | ✓ | ✓ | ✓ | Ahorro estimado de USD ~120 al mes sobre la factura actual, sin degradar el servicio |
| Gestión editorial, colegios y usuarios | ||||
| Panel central de la editorial | ✓ | ✓ | ✓ | Ya existe y funciona: colegios, cursos, docentes, catálogo y licencias |
| Crear libros y su estructura (registro y unidades) | ✓ | ✓ | ✓ | Ya existe: la editorial da de alta un libro nuevo, su portada y sus unidades. Pero esto solo crea el contenedor: las actividades quedan vacías hasta llenarlas de contenido (fila siguiente) |
| Asignación de docentes a cursos | ✓ | ✓ | ✓ | Ya existe: un docente puede tener varios cursos simultáneos |
| Roles y permisos diferenciados | ✓ | ✓ | ✓ | Ya existe: 7 roles con permisos por acción |
| Carga masiva de docentes y estudiantes (Excel/CSV) | ✗ | ✓ | ✓ | Hoy solo hay exportación; la importación masiva se agrega |
| Registro unificado en un solo flujo | ✗ | ✓ | ✓ | Hoy conviven dos puertas de entrada distintas: la general y la de la línea de inglés, que pide un código en lugar de contraseña. Se unifican en un único registro |
| Códigos de activación y control de piratería | ||||
| Generación de lotes de códigos por tirada | ✓ | ✓ | ✓ | Ya existe: 315.193 códigos generados históricamente, descargables para imprenta |
| Registro del estudiante con código y matrícula automática | ✓ | ✓ | ✓ | Ya existe: valida que el libro del código corresponda al libro del curso |
| Trazabilidad real de las activaciones | ✗ | ✓ | ✓ | Hoy está roto: 27.140 códigos usados contra 86 activaciones registradas. Es información comercial que la editorial no tiene |
| Contenido y producción editorial | ||||
| Motor de actividades interactivas | ✓ | ✓ | ✓ | Ya existe y está probado sobre 651 actividades en 5 tipos de interacción |
| Autoría de actividades interactivas | ✗ | ✓ | ✓ | El eslabón que falta para la autonomía total: hoy la editorial ya puede crear el libro y sus unidades, pero no su contenido —cada actividad exige que un desarrollador produzca y suba archivos al servidor—. Con la herramienta, el equipo de diseño crea y publica las actividades de un libro nuevo por su cuenta, sin programador y sin despliegues. Sustituye la cadena que dependía de Adobe Animate |
| Migración del catálogo actual a la herramienta | ✗ | ✓ | ✓ | Las 651 actividades existentes ya están enlazadas a su libro y unidad y seguirán funcionando tal cual. La migración las convierte de archivos a datos editables —de forma gradual, sin rehacerlas— para que la editorial también pueda modificarlas desde la herramienta |
| El docente agrega enlaces y recursos externos | ✗ | ✓ | ✓ | Complementar una unidad con material propio |
| Contenidos organizados en las 4 unidades del libro | ✗ | ✓ | ✓ | Toda actividad —existente o nueva— queda asignada a la unidad que le corresponde, y el docente programa por unidad. Hoy esa estructura solo existe en los 15 títulos de la línea más reciente; el resto tiene entre 7 y 84 elementos sueltos por libro |
| Libros digitales de cortesía por colegio y grado | ✗ | ✓ | ✓ | La editorial obsequia títulos digitales —sociales, naturales— a un colegio y un grado concretos. Estudiantes y docentes los ven junto a los libros que sí compraron. El mecanismo por colegio ya existe a medias (691 asignaciones registradas); falta incorporar el grado, que hoy no existe en el modelo de datos |
| Visor de texto digital protegido | ✗ | ✓ | ✓ | No se construye desde cero: hoy el libro ya se muestra embebido, pero el contenido está en la raíz pública y se puede abrir o descargar sin haber comprado el libro. Se blinda sacándolo de acceso público y sirviéndolo por rutas autenticadas, sin descarga directa |
| Vitrina de catálogo con venta directa | ✗ | ✗ | ✓ | Escaparate de los demás títulos del grado, con activación por compra desde la propia plataforma |
| Evaluación y control docente | ||||
| Programación de actividades con fecha de apertura y cierre | ✓ | ✓ | ✓ | Ya existe y se usa: 3.299 programaciones cargadas |
| Libro de calificaciones y exportación a Excel y PDF | ✓ | ✓ | ✓ | Ya existe en el panel del docente |
| Evaluación con nota real | ✗ | ✓ | ✓ | Hoy la estructura existe pero no se usa: el 92% de las notas son exactamente 100. Se pone en operación con rúbricas y ponderaciones |
| Práctica repetida y reintentos | ✗ | ✓ | ✓ | Hoy la actividad se bloquea para siempre al terminarla. En una plataforma de lectura y aritmética temprana, repetir es el aprendizaje |
| El docente crea sus propias evaluaciones | ✗ | ✓ | ✓ | Banco de preguntas propio del docente, además de las evaluaciones que define la editorial. Puede armarlas por unidad y programarlas a su curso con fecha de apertura y cierre |
| Autoría de evaluaciones: talleres y prueba tipo Saber | ✗ | ✓ | ✓ | Módulo distinto al de actividades, con su propio acceso y su propio bloque dentro de la unidad. Hoy no existe nada de esto: se crea el modelo completo. Dos formatos — taller (selección múltiple de única respuesta, con tiempo configurable) y prueba tipo Saber (20 preguntas, 60 minutos, única respuesta) — con temporizador y calificación automática. Poca variación de tipos de pregunta, pero requisitos de examen (tiempo, control de intentos) que las actividades no tienen |
| El docente publica contenido propio para su curso | ✗ | ✓ | ✓ | Material adicional —documentos, enlaces, recursos— visible para sus estudiantes junto al contenido editorial, sin pasar por la editorial ni por un desarrollador |
| Reportes y seguimiento | ||||
| Reportes y gráficas para el docente | ✓ | ✓ | ✓ | Ya existe: progreso del curso y desempeño por estudiante |
| Panel de seguimiento para el estudiante | ✗ | ✓ | ✓ | Que el propio alumno vea su avance |
| Reportes agregados para el colegio y la editorial | ✗ | ✓ | ✓ | Hoy solo el docente tiene visión; la institución y la editorial no |
| No incluido en ninguna opción | ||||
| Producción editorial del contenido | ✗ | ✗ | ✗ | Ilustración, locución y redacción pedagógica las aporta el equipo de la editorial — que con la herramienta de autoría las publica sin intermediarios |
| App móvil nativa en tiendas iOS y Android | ✗ | ✗ | ✗ | La versión web responsiva cubre el uso en tableta y celular |
| Videoconferencia, chat entre estudiantes y pasarela de pagos | ✗ | ✗ | ✗ | Fuera del alcance por decisión de producto |
Módulos concretos, cada uno con pruebas funcionales y documentación antes de pasar al siguiente. Los módulos 08 (actividades) y 09 (evaluaciones) corresponden a las opciones Actualización + autoría y LMS nuevo.
Workspace Nx con Next.js + NestJS y librerías compartidas de tipos. GitHub Actions para tests automáticos y deploy a staging. Entornos de desarrollo, pruebas y producción configurados.
JWT con refresh tokens, guards por rol (editorial / rector / docente / estudiante), restablecimiento de contraseña, consentimiento de acudiente y aislamiento de datos por colegio.
Gestión de colegios, cursos, docentes y catálogo. Generación de lotes de PINes con checksum y exportación para imprenta. Licencias por año lectivo. CMS para organizar libros, unidades y contenido. Activación en bloque de cortesías.
Flujo completo colegio → grado → PIN → curso, con validación anti-piratería, bloqueos y auditoría. Dashboard con sus libros activos, vitrina del catálogo del grado y textos de cortesía.
Lectura paginada del libro digital generado a partir del PDF de la editorial: sin descarga, marca de agua con el nombre del estudiante, índice navegable, zoom y enlaces firmados con expiración.
Cursos asignados, habilitar/deshabilitar contenido, programación con cierre automático, calificación automática de preguntas cerradas, banco de preguntas del docente para evaluaciones propias, libro de calificaciones y exportación Excel/PDF.
Motor que ejecuta las actividades interactivas del Capítulo 07 con contrato único (configuración de entrada → puntaje, respuestas y tiempo de salida). Reportes de PINes, registros y progreso para la editorial.
Editor donde el equipo de diseño de la editorial crea las actividades interactivas de práctica (arrastrar, trazo, audio, emparejar…) por sí mismo, sin programar: elige el tipo, sube sus imágenes y audios, escribe el enunciado, marca las respuestas, previsualiza y publica. Cada actividad queda enlazada automáticamente a su libro y a su unidad (la relación ya existe en la plataforma) y aparece de inmediato dentro del libro. El contenido se guarda como dato, no como código, y el motor lo ejecuta igual que a las 651 actividades actuales.
Un módulo aparte del de actividades, con su propio acceso y su propio bloque dentro de la unidad. Hoy no existe en la plataforma: se construye el modelo completo. La editorial arma talleres (selección múltiple de única respuesta, tiempo configurable) y pruebas tipo Saber (20 preguntas, 60 minutos), con temporizador, control de intentos y calificación automática. El docente las reutiliza o crea las suyas.
La editorial activa títulos digitales de cortesía a un colegio y un grado concretos —por ejemplo, regalar sociales y naturales a quien compró lenguaje y matemáticas— y estudiantes y docentes los ven junto a los libros adquiridos. En paralelo, el docente puede crear sus propias evaluaciones a partir de un banco de preguntas propio y publicar material adicional para su curso. Incluye la unificación del registro en un solo flujo de entrada.
Despliegue en la infraestructura elegida por el cliente, CI/CD de producción, documentación técnica del monorepo, manual de usuario por rol (PDF) y capacitación al equipo de Editorial Encuentro. Acompañamiento en la primera generación de PINes.
Cada fase cierra con entregables verificables. El cliente aprueba antes de iniciar la siguiente. La opción Actualización continúa donde termina la opción Correcciones, así que puede contratarse por etapas.
Reparación de los respaldos y prueba de restauración. Modo depuración desactivado y credenciales rotadas. Rotación del log y liberación de disco. Recuperación del acceso administrativo. Entregable: la plataforma deja de estar en riesgo de pérdida de datos y de fuga de credenciales.
Corrección del error reportado, las notificaciones, los dos cron rotos, el informe de calificaciones y las validaciones ausentes. Corrección de los 35 puntos que usan datos sin verificar (la causa de la mitad de los 500). Entregable: catálogo de errores cerrado y verificado.
Cierre del acceso indebido entre colegios (hoy un colegio puede leer datos de menores de otro) y parametrización de las consultas construidas a mano. Pruebas automatizadas sobre los flujos críticos, hoy inexistentes. Entregable: los datos de cada colegio quedan aislados y verificados con pruebas.
Monitoreo que avisa de verdad ante caídas y errores. Optimización de la infraestructura (ahorro estimado de USD ~120 al mes). Documentación y capacitación. Aquí termina Correcciones: la plataforma queda estable y segura, sobre la misma tecnología actual.
Editor donde el equipo de diseño crea y publica actividades sin programar, sobre los tipos de interacción que ya funcionan hoy. Migración del catálogo actual: las actividades existentes pasan de ser código a ser datos editables. Entregable: la editorial publica una actividad nueva sin intervención de un desarrollador.
Reorganización de todo el catálogo en las cuatro unidades de cada libro. Blindaje del visor de libro: el contenido sale de la raíz pública y pasa a servirse por rutas autenticadas, sin descarga directa. Activación de libros digitales de cortesía por colegio y grado —lo que obliga a incorporar el concepto de grado, hoy inexistente—. Evaluaciones propias del docente y publicación de contenido suyo para el curso. Evaluación con nota real, práctica repetida y reintentos. Reportes agregados para el colegio y la editorial, trazabilidad de los códigos de activación y unificación del registro en un solo flujo. Aquí termina la opción Actualización: la plataforma queda completa como LMS y la editorial, autónoma.
Se puede contratar por etapas. La opción Actualización arranca exactamente donde termina la opción Correcciones, sin repetir trabajo. La editorial puede contratar primero la opción Correcciones, verificar el resultado y decidir después si continúa — manteniendo el precio acordado para el total.
Levantamiento de requisitos con la editorial. Diseño de los paneles (editorial, colegio, docente, estudiante). Monorepo, esquema de base de datos y despliegue continuo desde el primer día. Entregable: prototipo aprobado y entorno de pruebas funcionando.
Panel maestro de la editorial, generación y exportación de lotes de códigos, licencias por año lectivo y gestión de contenido. Entregable: la editorial crea colegios, cursos y genera lotes de códigos reales.
Registro con código y validación anti-piratería, panel del estudiante, visor protegido del texto digital, cortesías y vitrina de catálogo. Entregable: un estudiante activa un libro con su código y lo lee en la plataforma.
Motor de evaluaciones con banco de preguntas propio del docente, libro de calificaciones, reportes, activación de cortesías por colegio y grado, y herramienta de autoría de contenido. Migración de los datos actuales —colegios, cursos, estudiantes, calificaciones e historial— y del catálogo de actividades. Operación en paralelo con la plataforma actual hasta el corte. Entregable: plataforma nueva en producción, sin pérdida de información ni interrupción del año lectivo.
La plataforma actual no se apaga hasta que la nueva esté probada. Hay colegios usándola a diario y actividades programadas hasta fin de año, así que las dos operan en paralelo durante la migración y el corte se acuerda con la editorial en una fecha que no interrumpa el calendario escolar.
El desarrollo es idéntico en los tres casos. Solo varía el costo mensual de operación que asume la editorial.
DevGrafik configura e instala el sistema en la opción elegida — la configuración está incluida en el precio de desarrollo. Los costos mensuales de operación los paga Editorial Encuentro directamente a cada proveedor, y varían según el tráfico real, la región y las tarifas vigentes de cada servicio.
Los costos de infraestructura no están incluidos en el precio de desarrollo — son gastos operativos mensuales que Editorial Encuentro consulta y contrata directamente con el proveedor elegido, ya que dependen del tráfico real, la región y las tarifas vigentes en el momento de la contratación. Como la editorial ya cuenta con AWS, se recomienda la Opción A: DevGrafik despliega sobre la cuenta AWS del cliente con permisos delimitados y entrega la configuración documentada con su guía de operación, para que el equipo de la editorial pueda cotizar el costo mensual directamente con AWS según su volumen esperado.
El cuello de botella de la plataforma no es tecnológico: es que publicar una actividad nueva exige un programador. Este capítulo explica cómo se resuelve.
La cadena de producción de Editorial Encuentro era: el equipo de diseño creaba la actividad en Adobe Animate, se la pasaba a un desarrollador, éste la integraba en la plataforma y se desplegaba. Esa cadena está rota en dos puntos a la vez.
La herramienta con la que el equipo de diseño producía los recursos ya no existe. Aunque no se tocara una línea de código de la plataforma, la editorial hoy no puede crear actividades nuevas.
Cada una de las 651 actividades actuales está escrita a mano como una plantilla con su propia dirección en el sistema. Publicar una actividad nueva significa escribir código y desplegar el servidor. La editorial depende de un desarrollador para cada ejercicio.
La consecuencia económica: cada actividad nueva es un gasto variable que la editorial no controla. Hoy ese gasto está en cero, pero porque la producción está detenida.
Un editor dentro de la plataforma, pensado para diseñadores y no para programadores. El motor que ejecuta las actividades ya existe y está probado sobre las 651 actividades actuales: lo que se construye es la interfaz para alimentarlo.
De un catálogo de mecánicas ya construidas y probadas. No hay que inventar la interacción: se configura.
Los recursos que el equipo de diseño produce con la herramienta gráfica que prefiera. La plataforma deja de depender de un programa concreto.
Se escribe la instrucción para el estudiante, se marcan las respuestas válidas y la actividad queda enlazada a su libro y a su unidad. Esa relación libro → unidad → actividad ya existe en la plataforma, así que la actividad nueva aparece de inmediato dentro del libro correcto, en la unidad correcta. Sin tocar una línea de código.
Se prueba la actividad tal como la verá el estudiante y se publica. Sin despliegues, sin esperar a un desarrollador, sin costo por actividad.
Qué pasa con el catálogo actual: las 651 actividades existentes se migran a este formato, de modo que dejan de ser código y pasan a ser contenido editable. La editorial puede corregir una errata, cambiar una ilustración o ajustar un enunciado sin pedirle nada a nadie — algo que hoy es imposible.
Todo se organiza por unidades. Cada libro se estructura en sus cuatro unidades y toda actividad queda asignada a una de ellas, tanto las nuevas como las 651 existentes. El docente programa por unidad y el estudiante ve el contenido agrupado igual que en su libro físico. Hoy esa estructura solo existe en los 15 títulos de la línea más reciente: en el resto del catálogo hay entre 7 y 84 elementos sueltos por libro, sin agrupación.
Cada mecánica es una plantilla configurable que se construye una sola vez y se reutiliza en todos los libros y todas las áreas. Todas registran puntaje, respuestas y tiempo en el libro de calificaciones.
Pregunta con opciones (texto o imagen); el estudiante elige y recibe retroalimentación inmediata.
Mover elementos al lugar correcto: partes de una célula, números en una recta, palabras en una oración.
Unir columnas o parejas relacionadas: concepto con definición, país con capital, imagen con palabra.
Frases o ejercicios con espacios en blanco que el estudiante llena escribiendo o eligiendo la palabra.
Poner en el orden correcto los pasos de un proceso, eventos históricos o etapas de un ciclo.
Arrastrar elementos a la caja que corresponde: vertebrados/invertebrados, sustantivos/verbos.
Vocabulario de la unidad en formato de juego, generado desde las palabras clave del libro.
Voltear tarjetas para encontrar parejas — imagen con imagen o imagen con palabra. Ideal para primaria baja.
Señalar sobre una lámina del libro: ubicar órganos, regiones del mapa, partes de una planta.
El catálogo de mecánicas crece con el uso. Si la editorial necesita una interacción que no está en la lista, se agrega como plantilla nueva al motor y queda disponible para todos los libros a partir de ese momento — no hay que rehacerla libro por libro.
La editorial podrá crear dos cosas diferentes, desde dos accesos diferentes, aunque ambas vivan dentro de la unidad del libro. Se separan porque tienen naturaleza, requisitos y modelo de datos distintos.
Los ~8 tipos de mecánica (arrastrar, trazo, audio, emparejar…). El estudiante practica y recibe retroalimentación. Es lo que ya existe hoy como las 651 actividades, y lo que el editor de autoría permite crear sin programador.
Un bloque aparte dentro de la unidad, con su propio acceso. Dos formatos: taller (selección múltiple de única respuesta, con tiempo configurable) y prueba tipo Saber (20 preguntas, 60 minutos). Con temporizador, control de intentos y calificación automática. Hoy no existe en la plataforma: se construye desde cero.
Por qué se separan y no se mezclan: una actividad de práctica y una prueba tipo Saber comparten poco. La prueba necesita tiempo cronometrado, una sola respuesta correcta por pregunta y control de un único intento; la actividad busca que el niño repita hasta aprender. Unificarlas complicaría ambas. Por eso son dos editores y dos experiencias, con calificación en las dos.
De menor a mayor alcance. Las tres resuelven los errores y las brechas de seguridad; se diferencian en cuánto transforman la plataforma.
Por qué la opción Actualización es la recomendada: las tres opciones dejan la plataforma sana y segura, pero solo la Actualización y LMS nuevo incluyen la herramienta de autoría, que es la que le devuelve a la editorial la capacidad de publicar contenido por su cuenta. La opción Correcciones arregla lo que está roto, pero mantiene la dependencia de un desarrollador para cada actividad nueva.
| Alcance | El precio de cada opción cubre las funcionalidades marcadas con ✓ en la tabla del Capítulo 03. Cualquier funcionalidad adicional se cotiza por escrito antes de iniciar. |
| Cambios de alcance | Hasta 2 ajustes por fase sin costo, siempre que no superen el 10% del esfuerzo de esa fase. Cambios mayores se cotizan y aprueban por escrito. |
| Plan de pagos | Se acuerda directamente con el cliente, ligado a hitos y metas verificables del cronograma. Precio fijo por opción (Capítulo 8.1). |
| Propiedad del código y del contenido | Al completar el pago total, Editorial Encuentro recibe el código fuente completo (repositorio privado en GitHub a su nombre) y la propiedad intelectual del 100% del contenido producido. |
| Infraestructura | Los costos mensuales de hosting, bases de datos y CDN son responsabilidad de la editorial. DevGrafik configura el entorno como parte del proyecto (Capítulo 06). |
| Continuidad del servicio | La plataforma está en uso activo por colegios reales. Toda intervención se ejecuta sin interrumpir la operación: los cambios se prueban en un entorno espejo antes de aplicarse en producción, y se acuerdan ventanas de mantenimiento con la editorial. |
| Garantía de calidad | Todos los módulos se entregan con tests automatizados documentados. Bugs reportados en los primeros 60 días post-entrega se corrigen sin costo adicional. |
| Protección de datos de menores | Tratamiento conforme a la Ley 1581 de 2012 (habeas data): datos mínimos, consentimiento del acudiente, sin publicidad ni terceros, comunicación siempre mediada por el docente. |
| Confidencialidad | DevGrafik mantiene absoluta confidencialidad sobre el contenido, datos de usuarios y lógica de negocio de la editorial durante y después del proyecto. |
| Vigencia de la propuesta | Precios y condiciones válidos por 30 días calendario desde el 11 de septiembre de 2026. |
La firma de ambas partes constituye la aceptación formal del alcance, precios y condiciones descritos en este documento, indicando la opción elegida: Correcciones, Actualización + autoría o LMS nuevo.
Al firmar esta propuesta, Editorial Encuentro acepta el alcance de la opción elegida (Capítulo 03), los precios indicados en el Capítulo 08 y el plan de pagos que se acuerde por hitos. DevGrafik se compromete a ejecutar el proyecto según el cronograma del Capítulo 5 con los entregables del Capítulo 4.
Fecha de emisión: 11 de septiembre de 2026 · Válida 30 días · LMS: opción ______ · Contenidos: ______ libros