Sistema Atlantic Center

En una escuela de natación de Teusaquillo, casi treinta años de trabajo administrativo pasaban por una pantalla azul. El programa lo habían hecho por encargo en 1996, en plena era DOS: listados en magenta, una barra roja para seleccionar, títulos sobre una franja amarilla y un menú en mayúsculas que iba de MANEJO DE ALUMNOS a TERMINAR. Una de sus pantallas todavía decía "PROTOTIPO 1996". Si nadie lo había reemplazado, era porque funcionaba.

Y funcionaba rápido. El personal no necesitaba el mouse. Volaba por el teclado con Ins para ingresar, Enter para seguir y Esc para volver, a una velocidad que solo dan los años de repetición, y eso nos cambió la idea del proyecto. Íbamos a reemplazar un sistema que la gente quería, anclado a las limitaciones de otra época, y el riesgo estaba en que el programa nuevo, por moderno que fuera, le volviera más lento el día a quien ya era experto.

Atlantic Center fue además nuestro primer cliente externo. Llegó por medio de URG Technology↗, la empresa bogotana con más de 20 años de servicio técnico, y fue la primera vez que el estudio trabajaba con un negocio ajeno, con acudientes, jardines de convenio, profesores, rutas de transporte y plata real pasando por el sistema todos los días. Si algo fallaba, se afectaba la operación diaria de una escuela entera.

Había que reemplazar un sistema que la gente quería sin quitarle velocidad a nadie.

Fuente: Informe detallado del proyecto Atlantic Center V1, §1.1 · Entrevista con el equipo de Damorus Projects, 2026

Que el programa se viera viejo era lo de menos. Todo vivía en una sola máquina, así que el trabajo se hacía en fila: dos personas no podían tocar los mismos datos al tiempo, y el ritmo de toda la oficina dependía de quién estuviera sentado frente a ese equipo. Cualquier conciliación tenía que esperar su turno.

Lo más delicado era algo que no se veía. No existía un respaldo confiable. Con un disco dañado, un virus que secuestra archivos, un robo o un rayo se perdía la historia de alumnos, pagos y cartera, y con ella el negocio. El cliente lo intuía a medias. Creía estar más protegido de lo que estaba, y parte de nuestro trabajo fue decírselo con claridad.

El modelo de datos también era de 1996, y la escuela de hoy maneja jardines y colegios de convenio, transporte por institución, planes flexibles, clases dobles, reposiciones, mora, descuentos por alumno y cursos vacacionales. Nada de eso cabía cómodo en tablas de hace tres décadas. Conectar ese programa con algo moderno, como la nube, era cada vez más difícil.

Y estaba el miedo al cambio. Para un equipo que se mueve rapidísimo con el teclado, una interfaz bonita pero lenta habría sido un retroceso. Ese miedo tenía fundamento, y de ahí salió la primera de tres condiciones que no se negociaban: no perder la velocidad del teclado. Las otras dos eran trabajar en varios equipos con los mismos datos en vivo y ser confiables con la plata de los clientes de la escuela, sin que el dueño tuviera que pelear con instalaciones ni actualizaciones.

Con un disco dañado se perdía la historia de alumnos, pagos y cartera.

Fuente: Informe detallado del proyecto Atlantic Center V1, §1.2

Antes de escribir una línea útil había que entender el negocio, y lo que más nos enseñó fue el propio programa viejo. Las fotos de sus pantallas nos dieron el menú real, la forma de moverse con el teclado y el vocabulario del cliente: "saldos", "ruta", "jardín", "vale", "vacacional". El sistema nuevo usa esas mismas palabras, porque cambiarle el idioma a alguien también lo vuelve más lento.

Después vinieron los datos. Las tablas del DOS estaban guardadas en archivos .DBF: alumnos, datos, horarios, pagos, cursos, profesores, transportadoras, bancos y festivos. Las pasamos a un formato moderno y las estudiamos una por una, y así vimos el tamaño real de la base de datos: 22.483 registros de alumnos acumulados con los años, de los cuales unos 8.036 se podían exportar y 14.447 estaban marcados como borrados.

Esperábamos encontrar el nombre de cada jardín en la tabla de horarios, y no estaba ahí. Estaba en un campo llamado DATOS.NOMBRE, lo que quería decir que la escuela, en la práctica, reconocía a sus instituciones por el nombre. Ese hallazgo pequeño cambió el diseño, porque el sistema nuevo heredó esa lógica, y tiempo después esa herencia nos dejó una de las lecciones más útiles del proyecto.

Cruzando los datos con ese vocabulario entendimos cómo opera la escuela. Un alumno individual suele tomar unas 7 sesiones de 2 horas, y un jardín de convenio, unas 14 sesiones de 1 hora. El transporte se cobra aparte y se organiza por institución. Hay mora cuando alguien ha tomado más clases de las que pagó, y varias instituciones pueden compartir la misma franja. Cada una de esas cosas terminó siendo una función del programa.

Leímos tabla por tabla lo que la escuela había guardado durante casi treinta años.

Fuente: Informe detallado del proyecto Atlantic Center V1, §2.1 y §2.2

El cliente lo pidió varias veces y con esas palabras: hacerlo "lo más para viejitos posible", de "la manera que les quede más fácil a ellos". Pensamos en una persona de 50 o 60 años que no le tiene cariño a la tecnología y que no debería sentir, ni un solo día, que el programa la está poniendo a prueba. Esa frase terminó guiando todas las decisiones de diseño.

Lo primero fue que la gente pudiera reconocer en vez de recordar. Lo importante está a la vista: el estado de cuenta en color, la mora en rojo, una píldora de estado por institución y la fecha escrita dentro de cada casilla de asistencia. Cada color significa una sola cosa en todo el sistema. Verde es que todo va bien, rojo es mora o falla, ámbar es algo a medias y gris es pendiente.

Lo segundo fue el poka-yoke, una idea japonesa de manufactura que consiste en diseñar para que el error sea difícil de cometer. La asistencia siempre empieza vacía. Para borrar un abono hay que escribir el motivo, un abono se bloquea si el alumno ya está al día y avisa si supera lo que debe, y eliminar registros solo lo pueden hacer ciertos usuarios.

Lo tercero, que se pudiera navegar de dos maneras. Quien venía del DOS sigue usando sus teclas de siempre, con la línea de atajos abajo de cada pantalla como homenaje al programa viejo, y quien prefiere el mouse hace lo mismo con clics. Al abrir, una pantalla de carga espera a que todo esté listo (datos, logo, preferencias y claves) antes de mostrar algo, porque un programa que aparece a pedazos se siente frágil.

Una persona de 50 o 60 años no debería sentir, ni un solo día, que el programa la está poniendo a prueba.

Fuente: Informe detallado del proyecto Atlantic Center V1, §3 y §10 · Entrevista con el equipo de Damorus Projects, 2026

El cliente lo tenía claro desde el comienzo: sus computadores conectados a la misma información en la nube, todo andando aunque se fuera el internet y, al volver la señal, que se subiera lo pendiente. Dejar eso para después nos habría encerrado en una mala decisión, así que lo diseñamos desde el primer día. Esa forma de construir se llama local-first. En el computador se trabaja, y la nube es donde los equipos se ponen de acuerdo y donde queda la copia.

Los datos se arman con dos capas. Abajo hay una base inmutable con lo que nunca se edita en caliente, como la configuración inicial de cursos, festivos, días de operación y métodos de pago. Encima va una capa de cambios (overlay, en inglés) guardada en IndexedDB, que es una base de datos local. Cada alta, edición o borrado se escribe en esa capa y, al leer, se impone sobre la base, que nunca se modifica.

Con esa separación, cualquier cambio se puede revertir y cada movimiento deja rastro. La sincronización, además, solo tiene que cargar lo nuevo. Los borrados se guardan como lápidas, marcas que dicen "esto se eliminó" en vez de dejar un hueco en la información. Y como todas las pantallas le piden los datos a un único módulo intermedio, la nube se pudo conectar más tarde sin reescribir una sola vista.

Aquí también hubo una decisión de privacidad. El instalador de producción arranca vacío, sin datos personales dentro del ejecutable, y la información real vive en la nube privada y en la capa de cambios de cada equipo. La interfaz la escribimos a mano, sin framework, porque un framework habría sumado peso y habría complicado el control fino del teclado que necesita este usuario.

El histórico nunca se edita. Lo nuevo se escribe encima, como en una hoja transparente puesta sobre un mapa.

Fuente: Informe detallado del proyecto Atlantic Center V1, §2.3, §4.1 y §4.2

Sincronizar equipos es un problema de ingeniería enorme cuando hay miles de usuarios. Aquí eran dos personas administrativas, y diseñar para un escenario que no existe habría sido un error caro. Elegimos a propósito un modelo simple. Cada pieza de información viaja como un documento independiente a una base privada en la nube, y cada equipo escucha los cambios del otro mientras está abierto. Si los dos llegaran a tocar el mismo documento, se queda la versión más reciente. Para dos personas esa regla alcanza, y cualquiera la entiende.

Lo que facilita la sincronización es cómo se guardan la asistencia y los pagos. En vez de una tabla enorme, cada dato tiene una llave que se explica sola: quién dio la clase de tal fecha y tal hora, qué transportadora hizo ese trayecto, si la clase fue doble, si la franja se lleva separada por jardín o cuántos niños se contaron en un curso vacacional. Cada llave sube y baja por su cuenta, sin coordinarse con las demás.

Hay dos reglas para no perder información. Sin señal no se pierde nada, porque lo pendiente espera en fila y sale solo cuando vuelve la conexión. Y al descargar desde la nube, lo que existe en el equipo y todavía no está arriba se conserva, aunque la nube llegue vacía por un error; durante las pruebas, esa regla salvó información más de una vez. Aparte, cada equipo reconoce su propio eco y no vuelve a procesar un cambio que él mismo hizo, lo que evita bucles y parpadeos.

Lo que un equipo tiene y la nube todavía no, no se descarta nunca.

Fuente: Informe detallado del proyecto Atlantic Center V1, §4.3 y §4.4

En la lista de alumnos es donde el personal pasa más tiempo, y tiene que moverse entre miles de filas sin titubear. Una tabla HTML común se ahoga con ese volumen, y un componente de terceros habría traído peso extra y menos control sobre el teclado. Así que hicimos nuestro propio grid virtualizado: las filas tienen altura fija y solo se dibujan las que caben en pantalla. Las demás existen, pero no cargan la memoria del programa hasta que se necesitan.

Encima de eso vinieron los detalles que lo acercan a una hoja de cálculo. Cada columna calcula su ancho según el contenido, con topes para que un nombre largo no deforme la tabla entera. Si las columnas no caben, hay desplazamiento horizontal. Los encabezados ordenan en tres pasos (de la A a la Z, de la Z a la A y el orden original), los filtros son chips que se recuerdan mientras uno está en la sección, y hay máscaras para escribir plata con separador de miles y fechas sin errores.

Lo más fino es la navegación con flechas. Moverse a la derecha nunca sube de fila por accidente, porque la navegación maneja filas y columnas por separado. Las columnas, además, van en orden de importancia para el negocio: lo que se debe y las asistencias aparecen antes que la edad o el curso, porque es lo primero que mira quien administra. Es de las piezas que más horas se llevaron, aunque casi nadie la note.

La tabla tiene miles de filas y solo dibuja las que caben en la pantalla.

Fuente: Informe detallado del proyecto Atlantic Center V1, §4.5 y §5.2

Todo empieza en Inscripciones, que abre por categoría: bebés, niños, adultos, instituciones, vacacional y práctica libre. Cada tipo tiene su propio formulario (un adulto no necesita acudiente), y el calendario del formulario marca los festivos en rojo mientras muestra en vivo el cronograma que se está creando. Las sesiones las genera un agendador que salta festivos y días cerrados y respeta los días y horas de cada curso; lo validamos contra una serie real de lunes, miércoles y viernes. Si el alumno entra a un jardín que ya está en curso, hereda su horario, sus sesiones y su ruta.

Después está Alumnos, con el grid principal y la ficha de cada estudiante (hoja de vida, abonos, horario, y recibos y horarios en PDF). En Instituciones, cada jardín tiene su lista de niños, un valor de plan global y descuentos por alumno. Asistencias y pagos agrupa el mes por franja y le pone color a cada clase: verde si se llamó a toda la lista, amarillo si quedó a medias y gris si falta llamarla. Dentro del llamado, cada casilla es verde si el alumno asistió, roja si faltó y gris mientras nadie la define.

Transportadoras lleva cada empresa de ruta con el valor de cada trayecto, lo que se le debe y sus pagos. Profesores es la nómina, con pago por sesión, mensual, quincenal o semanal, una guía de cuándo y cuánto pagarle a cada uno y órdenes de pago para imprimir. Informes y vales muestra el flujo por método de pago, lo que se debe, lo que falta por cobrar y el neto, además de ingresos y gastos externos, transferencias y una auditoría con hora, en ventanas de tiempo que van desde ayer hasta el histórico completo. El último módulo es Sistema, con temas, tamaño de letra, festivos, usuarios y respaldo.

Son ocho módulos, desde la inscripción de un alumno hasta la orden de pago del profesor.

Fuente: Informe detallado del proyecto Atlantic Center V1, §4.6 y §5 · Entrevista con el equipo de Damorus Projects, 2026

El cliente creaba profesores y al rato "no veía ningún profesor". Pasaba incluso en los dos computadores al mismo tiempo, así que descartamos una falla puntual de la nube. Investigando, vimos que la lista de profesores se manejaba como un dato suelto, separado de las clases, mientras que el nombre de cada profesor sí quedaba guardado en la asignación de cada clase. Cuando la capa de cambios se reconstruía o llegaba información del otro equipo, la lista quedaba vacía aunque las clases conservaran a su profesor. No se había perdido nada; faltaba que la lista saliera de un solo lugar.

La salida empezó por una definición: profesor es quien ha dado clases. Con esa idea armamos una reconstrucción automática que rearma la lista de profesores y de transportadoras a partir de lo que realmente pasó en las clases, y desde entonces la lista aparece siempre, con o sin internet y venga de donde venga la información. Tiempo después, cuando las clases empezaron a guardar también la tarifa, tocó enseñarle a esa reconstrucción a leer el formato nuevo, o el problema habría vuelto.

La segunda historia era más peligrosa, porque generaba cobros. El sistema daba por asistidas, o por falladas, las clases con fecha pasada, y así inventaba fallas y cobros que nadie había registrado. Alumnos que ya estaban borrados seguían apareciendo con cuatro fallas que nunca ocurrieron. La suposición de que "si la fecha ya pasó, algo ocurrió" estaba repetida en seis lugares del programa, entre ellos la lista, la impresión, la mini grilla de la ficha y el conteo de sesiones.

En el fondo, el programa confundía "el tiempo pasó" con "el evento ocurrió", y una asistencia solo existe cuando alguien la registra. Quitamos la suposición de los seis lugares, y ahora la asistencia siempre empieza vacía hasta que quien administra la define. Lo probamos con siete clases de fecha pasada: cero quedaron marcadas como asistidas y las siete quedaron vacías. El cliente confirmó que dejaron de aparecer cobros y fallas inventadas.

Que la fecha de una clase ya haya pasado no dice si el alumno fue.

Fuente: Informe detallado del proyecto Atlantic Center V1, §6.1 y §6.2

El cliente lo describió como "muuuy DEMASIADO MOLESTO", y lo reportó más de una vez. Al marcar cualquier cosa en el llamado de lista, el foco saltaba a la primera casilla de arriba, y quien iba por la mitad de la lista tenía que volver a bajar después de cada marca. En un programa que se usa con teclado, el cursor es el lugar donde está la mano, así que era un error crítico.

La causa estaba en una lista blanca. Después de cada marca, la lista se vuelve a dibujar para actualizar los estados, y una rutina devolvía el foco a su sitio, pero solo reconocía un grupo fijo de botones. Cuando agregamos botones nuevos, como el de marcar clase doble, quedaron por fuera de ese grupo y el cursor se escapaba hacia arriba. Cambiamos la excepción por una regla general: ahora el sistema recuerda cualquier elemento activo a partir de todos sus atributos de identificación, y el foco se queda quieto con cualquier botón, actual o futuro.

En la misma sesión apareció un error parecido. En el computador que solo estaba mirando, la tabla saltaba al inicio cada vez que llegaba una sincronización del otro equipo. Cambiamos el refresco para que ocurra en sitio: si hay una grilla activa, se actualiza ella misma y conserva el desplazamiento y la celda seleccionada. Así, quien está mirando ve cambiar los datos sin perder su lugar.

Ahora el sistema recuerda cualquier elemento activo, y el foco se queda quieto con cualquier botón, actual o futuro.

Fuente: Informe detallado del proyecto Atlantic Center V1, §6.3 y §11 (versiones 1.8.0 y 1.9.0)

De los problemas conceptuales del proyecto, este es el que más nos gustó. Un miércoles a las 10:15 pueden coincidir tres jardines en la piscina. A veces es una sola clase combinada, con un profesor y una transportadora, y por lo tanto un solo pago. Otras veces son tres clases distintas, cada jardín con su propio profesor y su propia ruta. Un sistema genérico escoge una de las dos opciones para siempre, y con cualquiera de las dos algo termina mal.

Si los obliga a ir siempre juntos, no hay forma de separar los equipos de trabajo. Si los separa siempre, al profesor se le paga tres veces por una sola hora. Como tocaba la nómina real, lo hablamos con el cliente de forma explícita. Quedó un interruptor por franja: por defecto van juntos, y si alguien elige verlos por separado, cada jardín se abre con su propio profesor, su transportadora, su asistencia y sus pagos. Siempre se pueden volver a juntar.

Por dentro, el interruptor usa las mismas llaves de la sincronización. Cuando una franja se separa, las llaves de profesor y de transportadora agregan el nombre de la institución, y así cada jardín tiene su propio equipo sin chocar con los demás. Al cambiar de modo se limpian las llaves del modo anterior, para que nunca se pague doble. Más adelante, a pedido del cliente, quitamos un botón que sobraba y volvimos más discreto el de separar.

Por defecto los jardines de una franja van juntos, y con un interruptor se separan sin pagarle doble al profesor.

Fuente: Informe detallado del proyecto Atlantic Center V1, §4.3 y §6.10

Un profesor puede cobrar distinto según el día. Al principio el sistema guardaba un solo valor por profesor, y cambiarlo recalculaba todo su historial: las clases viejas se revaloraban con la tarifa nueva y una deuda podía saltar de golpe en más de $200.000 COP. Para esquivarlo, el cliente empezó a crear el mismo profesor varias veces, con un número al final, una copia por tarifa. Pero al renombrar una de esas copias perdía la deuda, porque las clases estaban atadas al nombre. En los datos había unas 19 entradas de profesor, con las clases de una misma persona repartidas entre varios nombres.

La solución ya estaba en el propio sistema. Las transportadoras guardaban el valor de cada viaje y por eso no tenían ese problema, así que llevamos el mismo patrón a la nómina: el valor se guarda dentro de cada clase, como una foto del momento. Cambiar la tarifa por defecto ya no toca el pasado, y el selector muestra el valor antes de elegir. El cliente decidió conservar sus duplicados y lo respetamos. Lo que sí aseguramos fue que renombrar no dañara nada, porque ahora las clases siguen al profesor con su valor intacto. Como había plata de por medio, escribimos pruebas automáticas del renombrado y de la nómina antes de tocar la versión en uso.

El otro caso fue el de una alumna de un jardín de convenio que tomó una sola clase. La directora pagó esa clase, pero el sistema la seguía mostrando en deuda porque le cargaba el cronograma completo del jardín. Creamos el modo de clases sueltas: se define cuántas clases toma y a qué precio, y al pagar queda a paz y salvo, incluso de forma retroactiva. Quedaba un detalle. La fórmula de la cuenta volvía a sumar el transporte si el alumno tenía ruta, así que había que dejar la ruta en "No", o la alumna habría quedado debiendo un transporte que nunca usó.

Cada clase guarda la tarifa con la que se dictó, y cambiar el precio de hoy ya no recalcula las clases viejas.

Fuente: Informe detallado del proyecto Atlantic Center V1, §6.11 y §6.12

El primero apareció al renombrar instituciones. El cliente cambió el orden de las palabras en el nombre de varios jardines, con el tipo al final en lugar de al principio, y de pronto "se les borraron los estudiantes". Era la herencia de aquel campo DATOS.NOMBRE del sistema viejo: los alumnos se unían a su institución por el texto del nombre, y con un texto distinto la unión se rompía. Arreglamos los datos en la nube, volvimos a unir unos 60 alumnos con su institución y cambiamos la regla. Ahora renombrar actualiza a todos los alumnos, sin importar mayúsculas ni espacios.

El segundo tenía que ver con los códigos. Después de borrar registros, el siguiente alumno nuevo reutilizaba un código viejo y heredaba su asistencia, así que aparecía con clases que no eran suyas. El cálculo tomaba el código más alto entre los registros vivos, y al borrar, ese máximo bajaba. Lo cambiamos por una marca de agua alta que recuerda el código más alto que se haya usado y no lo vuelve a asignar, calculada también hacia atrás para respetar el pasado. La prueba fue sencilla: se borró el código 67 y el siguiente alumno salió con el 68.

El tercero no hizo ruido. Los informes de flujo por método de pago y por usuario salían en $0 aunque sí había abonos. El lector de fechas exigía dos dígitos en el mes, y el propio sistema escribía fechas como 27/8/2026, con uno solo, así que esas fechas se leían mal y los abonos quedaban por fuera del período. Se arregló cambiando una línea.

Los tres errores tienen algo en común, y desde entonces lo vigilamos: detrás de un número con plata había un supuesto pequeño, que un nombre no cambia, que un máximo no baja o que un mes siempre trae dos dígitos.

Un mes escrito con un solo dígito bastaba para que los informes de flujo salieran en $0.

Fuente: Informe detallado del proyecto Atlantic Center V1, §6.5, §6.6 y §6.7

Un programa de escritorio tiene que llegar a cada computador y mantenerse al día, algo de lo que una página web no se tiene que preocupar. Lo empaquetamos como programa de Windows, con su instalador y un ícono propio de olas en el azul de la marca, porque el logo original era un banner horizontal que no se leía en tamaño pequeño. Las actualizaciones llegan por aire: al arrancar, el programa revisa si hay una versión nueva, descarga solo las partes que cambiaron y la aplica cuando vuelve a abrir, con un punto verde como señal. De la 1.6 a la 1.9.0, las versiones llegaron así a los equipos del cliente.

Entonces pasó algo con lo que no contábamos. El cliente instaló el programa dentro de su carpeta de iCloud. Cuando llegó una actualización aparecieron montones de ventanas pidiendo permiso sobre archivos internos, y el programa se dañó. Eran dos problemas encimados. iCloud sincroniza y renombra archivos mientras el actualizador intenta reemplazarlos. Y, más de fondo, borrar la carpeta tampoco desinstalaba el programa, porque Windows seguía recordando la ubicación original y las actualizaciones apuntaban allá.

Rehicimos el instalador para que sea asistido. Ahora pregunta dónde instalar y muestra el progreso, igual que el desinstalador, y así se puede reinstalar limpio fuera de iCloud sin dañar las actualizaciones silenciosas. Para equipos nuevos hay una página privada de descarga, protegida con clave y con freno a los intentos repetidos. También le contamos al cliente lo que quedó sin hacer. El instalador no tiene firma de código, así que Windows muestra "editor desconocido" la primera vez. El certificado tiene un costo anual que por ahora no se justificaba, y el cliente aceptó ese aviso.

Windows seguía recordando dónde estaba instalado el programa, aunque la carpeta ya no existiera.

Fuente: Informe detallado del proyecto Atlantic Center V1, §6.4, §6.14 y §7 · Entrevista con el equipo de Damorus Projects, 2026

En la nube, la información está protegida por reglas de seguridad de la misma base de datos, lo que se conoce como seguridad a nivel de fila (RLS). El registro público está apagado y solo una sesión autenticada de la escuela puede leer o escribir, así que la llave pública del servicio, que por diseño no es secreta, por sí sola no sirve de nada. Encima pusimos otra capa a propósito: la aplicación no tiene permiso para borrar. Cuando alguien elimina algo, el programa lo marca como borrado, y el borrado real solo se puede hacer con una llave maestra que guarda el dueño. Desde el programa, ni un error de código ni alguien con malas intenciones sentado frente a un equipo pueden destruir la historia.

El respaldo tiene tres capas: las copias automáticas del proveedor de la nube, en la cuenta del cliente; copias semanales en cada computador, con rotación de unas diez; y un respaldo diario fuera de la oficina, con historial de versiones, en un repositorio privado del cliente. La tercera salió de una conversación. El cliente creía que las copias locales eran incorruptibles, y le explicamos que también son archivos en un disco, expuestos a un virus o a un borrado. El primer respaldo diario se verificó en producción, con los datos reales de la escuela.

Después, el cliente pidió que la base pasara de la cuenta del estudio a una cuenta suya. Se podía crear un proyecto nuevo, migrar los datos, cambiar las llaves y redistribuir instaladores, o transferir el proyecto completo con su dirección y sus llaves. Transferimos, porque así la app seguía funcionando sin cambiar una línea de código ni tocar un solo equipo, y lo verificamos con una prueba de inicio de sesión, lectura y escritura. No hubo tiempo fuera de servicio, y hoy los datos son del cliente.

Cuando alguien elimina algo, la app lo marca como borrado. El borrado real necesita la llave maestra que guarda el dueño.

Fuente: Informe detallado del proyecto Atlantic Center V1, §8.1, §8.2 y §8.3 · Entrevista con el equipo de Damorus Projects, 2026

Nunca hubo un documento de requisitos cerrado. El software salió de conversaciones: el cliente contaba con sus palabras lo que veía ("se me borró la deuda", "el cursor me salta arriba", "que la fecha quede adentro de la casilla"), y a nosotros nos tocaba convertir cada frase en una decisión de ingeniería. Él pedía ritmo ("junta todo", "termina todo de una vez"), así que cada versión reunía muchos cambios. Se probaba en bloque, con scripts para la lógica delicada y con la app real para la interfaz, y salía de una sola vez por actualización automática.

A ese ritmo hace falta criterio. Varias veces el pedido literal escondía otra necesidad. Cuando el cliente quiso crear la misma transportadora con tres precios, el sistema ya permitía cambiar el precio en cada viaje; en profesores eso no existía, y hubo que construirlo. Cuando había plata en juego preguntamos antes de actuar, como pasó con los profesores duplicados. Y cuando el cliente se creía más protegido de lo que estaba, se lo dijimos.

La cronología lo muestra. La versión 1.0.0 salió con los ocho módulos, la sincronización, la descarga privada y las actualizaciones por aire. Las siguientes estabilizaron cálculos, calendario e interfaz. La 1.8.0 fue una tanda grande, con clases dobles, clases sueltas y jardines por separado, y la 1.9.0 trajo las tarifas por clase y la corrección definitiva del cursor. Cada versión se instaló y se verificó antes de llegar a los equipos del cliente.

Varias veces, lo que el cliente pedía al pie de la letra escondía otra necesidad.

Fuente: Informe detallado del proyecto Atlantic Center V1, §9 y §11

Las pantallas de un software administrativo están llenas de nombres, deudas y teléfonos reales, y eso no se puede mostrar. Para enseñar Atlantic Center sin exponer a nadie, el mismo programa puede arrancar en modo demo, con una base de datos separada de la real y un script que siembra datos ficticios pero creíbles: unos 42 alumnos en 9 instituciones, con abonos, horarios y cuentas en todos los estados posibles. Al principio todos los jardines del miércoles caían a la misma hora y no se veía la función de juntos o separados, así que los repartimos en franjas distintas.

Las capturas tampoco se toman a mano. Un script abre la app en modo demo en una ventana de 1.600 píxeles, inicia sesión, espera a que la interfaz quede quieta y recorre 13 pantallas principales, abriendo por código los modales que hagan falta. Haciéndolo descubrimos que, con la ventana oculta, la foto a veces sale con un fotograma viejo. Ahora se captura con la ventana visible y con un margen para que la imagen termine de pintarse.

La app está en español, y el sitio del estudio necesita capturas en tres idiomas. En lugar de traducir el programa completo, hicimos una capa que traduce la pantalla justo antes de la foto. Sacamos más de 600 textos visibles, armamos un diccionario exacto y reglas para frases con fechas y números, y dejamos intacto lo que no es idioma, como códigos y montos. Hubo detalles finos, como el orden de la fecha en alemán o las vocales con tilde al final de una palabra. Quedaron tres juegos idénticos de 13 capturas, en español, inglés y alemán.

Las capturas muestran datos creíbles de personas que no existen.

Fuente: Informe detallado del proyecto Atlantic Center V1, §14 y §18

La escuela usa el sistema todos los días. Corre en dos o más computadores sincronizados en vivo, maneja unos 390 alumnos, unas 30 instituciones y unos 15 profesores activos, y va en la versión 1.9.0, que llegó sola por actualización automática. El respaldo diario fuera de la oficina funciona, la base ya está en la cuenta del cliente y el programa de 1996 se retiró del todo, sin que el personal tuviera que dejar su teclado. El cliente quedó contento, y seguimos mejorando el sistema después de la entrega.

También tiene límites. No tiene firma de código, así que la primera instalación muestra un aviso de Windows. Todavía no hay un portal para que los acudientes consulten saldos y horarios en línea; quedó para una fase futura, porque exige pensar con cuidado la privacidad de menores. Y no hay versión web pública, a propósito: la Ley 1581 de protección de datos personales pesó más que la comodidad de abrirlo desde cualquier navegador.

La regla de que gana el cambio más reciente sirve para dos personas. Si algún día fueran muchas editando el mismo registro, habría que pasar a una fusión más fina, campo por campo. Los profesores duplicados siguen ahí porque el cliente así lo decidió; el sistema los tolera y no se daña al editarlos, pero limpiarlos sería un trabajo de datos aparte, para cuando el cliente lo pida. Nada de esto impide el uso diario.

No hay versión web pública, a propósito. La Ley 1581 de protección de datos personales pesó más que la comodidad.

Fuente: Informe detallado del proyecto Atlantic Center V1, §12 y §13 · Entrevista con el equipo de Damorus Projects, 2026

En medio de este proyecto hubo un momento en que entendimos algo sobre nosotros mismos. Habíamos tomado un programa de treinta años, leído sus tablas, entendido un negocio ajeno y construido encima, con Claude como herramienta de construcción, un sistema que funciona sin internet, sincroniza varios equipos, se actualiza solo y protege la plata de una escuela. Todo en cerca de mes y medio y con el cliente al lado. La sensación fue muy clara: podemos construir cualquier cosa.

La segunda lección fue más incómoda: nunca subvalorar un proyecto. Visto desde afuera, "modernizar el programa de una escuela" suena pequeño. Por dentro aparecieron la sincronización, las tarifas por clase, los jardines que comparten franja, el instalador, los respaldos y varios errores de una línea con plata detrás. Casi toda la inteligencia del producto está en decisiones que no se ven. Desde entonces, para dimensionar un proyecto miramos lo que tiene que sostener.

La tercera tiene que ver con cómo trabajamos. Se puede reemplazar un sistema querido sin traicionar a quien lo usa, y en Atlantic Center respetar el teclado de siempre, el vocabulario de siempre y el miedo al cambio fue la condición para que el proyecto funcionara. Una herramienta nueva se gana la confianza de la gente cuando la deja trabajar como ya sabía hacerlo, con más respaldo.

Casi toda la inteligencia del producto está en decisiones que no se ven.

Fuente: Entrevista con el equipo de Damorus Projects, 2026 · Informe detallado del proyecto Atlantic Center V1, §17