An app can look flawless in a demo. Clean screens, smooth animations, everything works in front of the client in the meeting room. Then it goes into production, and a warehouse operator opens it on an old phone, with an intermittent connection and data that doesn’t match the web portal they use an hour later.
A demo proves that an app works. Production proves that it was designed well.
The real test begins when the app leaves the meeting room
A business app lives in conditions a demo never shows: unstable networks, ageing devices, data that has to stay consistent with other systems used by the same people at the same time. A business app doesn’t need to work well when everything goes well. It needs to keep working when nothing goes to plan.
A business app never stands alone
In these cases, the problem is almost never the interface. It is the architecture behind it. A business app is not necessarily a standalone product. It is often an interface through which users access a larger system, made up of existing ERPs, CRMs, portals and APIs. When it is developed as an isolated object, disconnected from those systems, it works well as long as it remains a prototype. It becomes a problem when users start relying on it every day alongside other tools, expecting the data to be identical wherever they look.
When two systems tell two different truths
Here is a real case from the pharmaceutical sector. An app displayed data that conflicted with the web portal used by the same distribution network. The two platforms queried different sources and applied different update logic. This structural misalignment caused daily operational confusion for the people who relied on those figures to do their jobs. The solution was not to fix the symptoms case by case. Instead, we eliminated the duplicated logic and moved both platforms onto the same API layer, making it the single application source for shared data.
The problems a demo cannot show
The difficulties that emerge in production fall into three distinct levels.
Usage issues: devices, performance, network, compatibility. These concern the day-to-day experience of the people who use the app.
System issues: data synchronisation, integration, authentication, governance. These affect the architecture, and a simulator test alone cannot catch them.
Continuity issues: documentation, accountability, maintainability, vendor dependency. These relate to the lifecycle and surface months or years after release.
Quality is designed before go-live
Technology shouldn’t be the starting point. It is a consequence of the requirements. The choice between native, cross-platform or PWA depends on several factors: hardware needs, offline use, performance, distribution and update frequency. It should not rest on an a priori technical preference.
The same applies to privacy. “GDPR by design” means little if it remains a slogan. In practice, it means data minimisation, access segregation, defined retention periods and encryption.
Where does company data end up, temporarily, on the device when there is no connection?
This question must be asked before the first line of code is written, not once the app is already in production.
An app must be maintainable even by those who didn’t build it
A premium project must be transferable, not just functional.
That means testing on real physical devices before every release, not just on simulators. It means delivering complete technical documentation at go-live. With it, the client’s team, or a future supplier, can take over the project without depending on whoever wrote it. No reliance on a single person, and no knowledge left outside the documentation.
A business app is measured over time
Today we manage more than 15 business apps already in production. We don’t regard go-live as the end of development. It is the moment the project has to prove it is ready for the real world. Our apps are approved by the stores on first submission. This is the result of a process that runs checks on requirements, security, behaviour and compliance before submission, rather than after a rejection.
A business app isn’t judged when it is presented. It is judged when it becomes part of the company’s processes and keeps working months and years later. That is where you see the difference between a delivered product and a system designed to last.
Before designing the screen, design the system it will have to live in. That is where a business app built to last begins.