ACPOL EB es una academia de preparación de oposiciones a policía nacional. Su plataforma de estudio llevaba años funcionando con una app nativa: Android en Java, iOS nativo, y un backoffice en Flutter conectado a un backend en Node.js.
Sobre el papel funcionaba. En la práctica, cada cambio pequeño requería tocar tres proyectos distintos, con perfiles técnicos especializados en cada tecnología. Publicar una función nueva en el aula virtual significaba subirla a Android, a iOS y al backoffice por separado, y esperar la revisión de las stores antes de que los alumnos la vieran.
A eso se sumaban las limitaciones propias de los marketplaces: funcionalidades que Apple o Google no permiten, revisiones que se alargan días o semanas, y una cuota anual de desarrollador que había que pagar solo por seguir existiendo en la App Store.
Cuando una empresa decide migrar una plataforma que ya funciona, el instinto habitual es saltar directo a "vamos a construir la versión nueva". Es el error más común, y el que más dinero cuesta corregir después.
La mayoría de estos proyectos no fallan por elegir mal la tecnología. Fallan porque nadie definió con precisión qué había que construir antes de empezar a construirlo. El equipo técnico avanza sobre supuestos, el alcance crece sobre la marcha, y lo que iba a tardar dos meses termina tardando seis.
Existe la idea de que "definir" es una fase burocrática que retrasa el proyecto real. Es justo al revés: cada semana que se invierte en definición bien hecha ahorra varias semanas de desarrollo mal dirigido. El tiempo no desaparece, simplemente se mueve de después a antes, cuando corregir todavía es barato.
Una definición útil no es un documento de cien páginas. Es una respuesta clara a cinco preguntas, y puede resolverse en días, no en semanas:
Problema: qué está fallando exactamente hoy, con datos concretos, no sensaciones.
Usuario: quién va a usar la plataforma nueva y en qué contexto real la va a usar.
Alcance: qué entra en la primera versión y qué queda explícitamente fuera.
Métrica: cómo se sabrá si la migración ha funcionado, con un número concreto.
Prototipo: una prueba mínima que valide la decisión técnica antes de comprometer meses de desarrollo.
Cuando estos cinco puntos están claros, el equipo técnico deja de adivinar. Y cuando no lo están, cada decisión durante el desarrollo se convierte en una negociación improvisada.
Antes de escribir una línea de código nuevo, se resolvieron esos cinco puntos con el equipo de ACPOL EB:
Problema: mantener tres codebases (Android, iOS, backoffice) exigía perfiles técnicos distintos, encarecía cualquier cambio y añadía días de espera por las revisiones de las stores.
Usuario: alumnos preparando la oposición, que necesitan acceso rápido a test y temario desde el móvil, y el equipo de la academia, que gestiona contenido desde el backoffice.
Alcance: replicar el flujo de estudio y test para el alumno y la gestión de contenido del backoffice, sin depender de las stores para publicar cambios, incorporando además mejoras puntuales sobre la versión nativa allí donde aportaban valor inmediato.
Métrica: reducir el coste de mantenimiento, eliminar los tiempos de espera de revisión y consolidar el desarrollo en un único equipo.
Prototipo: antes de comprometer el desarrollo completo, se validó que una PWA podía cubrir el uso real de los alumnos en sus móviles, con la misma fluidez que la app nativa.
Con esas respuestas cerradas, el alcance del proyecto quedó fijado desde el primer día. No hubo ambigüedad sobre qué se iba a construir ni sobre qué no.
Una academia de oposiciones no se puede permitir una parada. Los alumnos estudian todos los días del año, y una plataforma caída durante la migración significa alumnos sin acceso a su temario en plena preparación.
Por eso la migración se planteó en paralelo: la plataforma nativa siguió funcionando con normalidad mientras se construía la nueva, sin tocar el sistema en producción hasta que la versión nueva estuvo lista para sustituirla.
La nueva plataforma se construyó con ReactJs, como PWA para los alumnos y como aplicación web estándar para el backoffice, con PHP como API. Todo el proyecto, desde la definición hasta el lanzamiento, se completó en dos meses.
Con la plataforma nueva en producción, ACPOL EB dejó de necesitar un desarrollador por cada sistema. Un único equipo mantiene ahora la PWA de alumnos y el backoffice sobre la misma base tecnológica.
Al no depender de las stores, las funcionalidades ya no están limitadas por lo que Apple o Google permiten, y cada actualización llega a los alumnos al momento, sin esperar revisiones externas. La cuota anual de desarrollador de Apple también desapareció del presupuesto.
Puedes ver capturas y más detalles de la plataforma en nuestro portfolio de proyectos.
El caso de ACPOL EB no es una excepción. La mayoría de empresas que arrastran una app nativa cara de mantener tienen el mismo patrón: varios equipos, varias tecnologías, y cambios que tardan semanas en llegar al usuario final.
La diferencia entre una migración que se resuelve en dos meses y una que se alarga medio año no está en la tecnología elegida. Está en si alguien se sentó a responder esas cinco preguntas antes de empezar a programar.
Cuéntanos qué plataforma quieres migrar y te decimos si es viable hacerlo sin parar tu negocio.
En este caso, dos meses completos, desde la definición hasta el lanzamiento. El tiempo real depende del alcance de la app original y de lo bien definido que esté el proyecto antes de empezar a construir.
Sí, siempre que la migración se plantee en paralelo: la plataforma antigua sigue funcionando con normalidad mientras se construye la nueva, y solo se sustituye cuando la versión nueva está lista.
No depende de las revisiones de las stores, no requiere mantener código distinto para Android e iOS, y elimina cuotas de desarrollador como la de Apple. A cambio, hay funcionalidades muy específicas del dispositivo que una PWA no puede cubrir.
En la mayoría de casos no es un problema técnico. Es que nadie definió con precisión el problema, el usuario, el alcance, la métrica de éxito y un prototipo antes de empezar a programar.
Días, no semanas. Una definición útil responde a cinco preguntas concretas; no es un documento extenso ni un proceso que deba alargarse.
La satisfacción de nuestros clientes es nuestra mejor carta de presentación.
"Tengo un negocio de Paquetería, en el que vienen muchas personas diariamente, tanto para recoger como para dejar paquetes. Llevábamos años gestionando muchos de nuestros procesos de paquetería de forma manual, y gracias a Blimbur Technologies hemos dado un salto enorme. Nos desarrollaron una app móvil y una web totalmente adaptadas a nuestro flujo de trabajo, con las que ahora tenemos todo automatizado, trazable y mucho más rápido. Ahora, el cliente sabe si tenemos el paquete y al estar todo mucho más organizado, es mucho más rápido y ágil, lo que hace que los clientes vengan y se vayan con otra cara y sin esperas. El trato ha sido impecable y el resultado, todavía mejor. Un equipo serio, técnico y que se implica de verdad."
