ACPOL EB is an academy that prepares students for Spain's national police entrance exam. Its study platform had been running for years on a native app: Android built in Java, native iOS, and a backoffice built in Flutter connected to a Node.js backend.
On paper it worked. In practice, every small change meant touching three separate codebases, with specialised technical profiles for each technology. Shipping one new feature in the study area meant releasing it on Android, on iOS, and on the backoffice separately, then waiting for store review before students could see it.
On top of that came the usual marketplace constraints: features Apple or Google simply do not allow, reviews that stretch out for days or weeks, and an annual developer fee that had to be paid just to keep existing in the App Store.
When a company decides to migrate a platform that already works, the usual instinct is to jump straight to "let's build the new version." That is the most common mistake, and the most expensive one to fix afterwards.
Most of these projects do not fail because of a bad technology choice. They fail because nobody defined precisely what needed to be built before building it. The technical team moves forward on assumptions, scope grows along the way, and a two-month project turns into a six-month one.
There is a common belief that "defining" is a bureaucratic phase that delays the real project. It is the opposite: every week spent on a proper definition saves several weeks of misdirected development later. The time does not disappear, it just moves earlier, when fixing course is still cheap.
A useful definition is not a hundred-page document. It is a clear answer to five questions, and it can be resolved in days, not weeks:
Problem: what is actually failing today, backed by concrete data, not gut feeling.
User: who will use the new platform, and in what real context they will use it.
Scope: what goes into the first version, and what is explicitly left out.
Metric: how you will know the migration worked, expressed as a specific number.
Prototype: a minimal test that validates the technical decision before committing months of development.
When these five points are clear, the technical team stops guessing. When they are not, every decision made during development becomes an improvised negotiation.
Before a single line of new code was written, these five points were resolved with ACPOL EB's team:
Problem: maintaining three codebases (Android, iOS, backoffice) required distinct technical profiles, made every change more expensive, and added days of waiting for store reviews.
User: students preparing for the exam, who need fast access to tests and study material from their phones, and the academy's staff, who manage content through the backoffice.
Scope: replicate the student's study and testing flow and the backoffice's content management, without depending on app stores to ship changes, while also incorporating targeted improvements over the native version where they added immediate value.
Metric: lower maintenance cost, eliminate review wait times, and consolidate development into a single team.
Prototype: before committing to full development, it was validated that a PWA could cover students' real usage on their phones with the same fluidity as the native app.
With those answers settled, the project's scope was fixed from day one. There was no ambiguity about what would be built, or what would not.
An exam-prep academy cannot afford downtime. Students study every day of the year, and a platform going down during migration means students without access to their study material in the middle of exam preparation.
That is why the migration was run in parallel: the native platform kept running normally while the new one was built, without touching the production system until the new version was ready to replace it.
The new platform was built with ReactJs, as a PWA for students and as a standard web application for the backoffice, with PHP as the API. The entire project, from definition to launch, was completed in two months.
With the new platform in production, ACPOL EB no longer needs one developer per system. A single team now maintains both the student PWA and the backoffice on the same technology base.
Without depending on app stores, features are no longer limited by what Apple or Google allow, and every update reaches students immediately, without waiting on external reviews. Apple's annual developer fee also disappeared from the budget.
You can see screenshots and more details of the platform in our project portfolio.
ACPOL EB's case is not an exception. Most companies dragging along an expensive-to-maintain native app share the same pattern: several teams, several technologies, and changes that take weeks to reach the end user.
The difference between a migration that wraps up in two months and one that drags on for half a year is not the technology chosen. It is whether someone sat down to answer those five questions before writing any code.
In this case, two full months, from definition to launch. Actual time depends on the original app's scope and how well-defined the project is before development starts.
Yes, as long as the migration runs in parallel: the old platform keeps working normally while the new one is built, and it's only replaced once the new version is ready.
It doesn't depend on store reviews, doesn't require separate codebases for Android and iOS, and removes developer fees like Apple's. In exchange, there are some device-specific features a PWA cannot cover.
In most cases, it's not a technical problem. Nobody precisely defined the problem, the user, the scope, the success metric, and a prototype before starting to code.
Days, not weeks. A useful definition answers five specific questions; it's not a lengthy document or a process that should drag on.
Our clients' satisfaction is our best introduction.
"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."
