When we launched AlineBMS, the mobile experience was a Progressive Web App. It was a deliberate decision. Aline was already a web application, and a PWA gave us a practical way to bring the product to mobile without maintaining a separate application from day one.
For an early-stage product, the trade-offs made sense. Users could access Aline from their phones without going through an app store, we could continue developing primarily around the web application, and updates could be shipped without asking users to install a new version.
More importantly, it worked. After launch, almost everyone using Aline on mobile was using the PWA. It wasn't a prototype that we abandoned after a few weeks. It became the actual mobile experience for our users.
We are now building a dedicated mobile application with React Native and keeping the PWA available alongside it. That might sound like a straightforward technology change, but the reason is more interesting than that. It is a story about what happens when a product grows beyond the assumptions it was originally built around.
Starting with a PWA
AlineBMS is designed to bring several parts of business operations into one system, including HR, payroll, attendance, CRM, tasks and projects. Some of these workflows are naturally desktop-oriented, while others need to happen wherever employees and managers happen to be.
That made mobile access important from the beginning. But we didn't want to build a separate mobile application just for the sake of having an app. At launch, the PWA gave us a way to extend the existing product to mobile while keeping the development process relatively simple.
For many workflows, that worked exactly as expected. Employees could access their information, managers could review things from their phones, and the product was available without another installation process. There was no reason to introduce native mobile development if the browser could already handle the job.
The problem was that some of Aline's workflows weren't really about displaying information on a phone. They depended on the phone itself.
When the Device Became Part of the Workflow
Attendance made this especially clear. Aline's attendance workflows can depend on location, which means the application needs access to the device's location at the time the employee is checking in.
In practice, we started seeing a recurring class of issues. An employee might have location turned off completely. Another might have location enabled but have denied the browser permission to access it. Someone else might have previously denied the permission and not remember doing so. From the application's perspective, these situations were different. From the employee's perspective, they were all the same problem: attendance isn't working.
This is where the distinction between a technically supported feature and a reliable product experience became important to us. The browser can access location. That doesn't necessarily mean every user will have a predictable experience getting the browser to access location on their particular device.
Notifications presented a similar problem. Aline uses notifications for things such as overdue items, leave applications, payslips and other updates. Not every notification is critical, but once notifications become part of a business workflow, users reasonably expect them to behave consistently.
Again, the browser supports notifications. But there are several layers between Aline generating a notification and an employee actually seeing it. Permission settings, browser behavior, operating-system restrictions and whether the application is active in the background can all affect that experience.
Background behavior created another layer of friction. None of these issues individually made the PWA unusable. The problem was the accumulation of small dependencies around workflows that were supposed to be simple.
A feature being supported by the browser is not the same thing as that feature being reliably usable by every employee using Aline.
The Nepal Factor
Building Aline for businesses in Nepal made these issues more visible because our users operate across a very diverse set of devices and configurations.
There isn't a single "typical Aline phone." We encountered different Android devices, different versions of Android, different browsers and different configurations. More importantly, the people using the software are not necessarily technical users. They are employees, HR teams, managers and business owners trying to get their work done.
That changes how you think about a product problem.
As developers, we can understand why a permission is missing or why a browser behaves differently on one device. We can explain what needs to be changed in the settings and why. But the employee using Aline shouldn't need to understand any of that.
If someone is using Aline for attendance, the expected workflow is simple: open Aline, check in, and continue with their day. They shouldn't have to determine whether location is enabled at the device level, whether the browser has permission to use it, or whether some previous permission decision needs to be reversed in Android settings.
This is not a problem unique to Nepal, but building Aline here made us confront it directly. We weren't designing for a controlled fleet of identical devices. We were designing for real businesses where employees arrive with whatever phones they already use.
The less technically experienced the user, the more important this becomes. Software should absorb complexity wherever possible instead of transferring that complexity to the person using it.
We Tried to Make the PWA Work
We didn't immediately decide that the solution was to build a mobile app. We tried to improve the experience within the architecture we already had.
We worked on permission flows and different ways of handling the mobile experience. We also looked at ways of packaging the existing PWA as an application rather than rebuilding the whole mobile experience from scratch.
One of the approaches we explored was Capacitor. It allowed us to package the web application for mobile and expose native device capabilities to the web layer.
This was useful because it helped us test an important middle ground. We didn't necessarily need to throw away everything we had. Perhaps we could keep the existing application and give it a more native environment.
But that approach also helped clarify the problem. We could wrap the web application in a mobile application, but we were still fundamentally designing the experience around a web application and then asking it to behave like a mobile application.
At that point, the question changed. Instead of asking how many more workarounds we could add to the PWA, we started asking whether a dedicated mobile client would simply give us a better foundation.
Why We Decided to Build a Mobile App
The answer was yes.
We are now building the Aline mobile application with React Native. The goal isn't to make the entire Aline web application available on a smaller screen. The mobile application has a different purpose.
Some parts of Aline make sense to access from a desktop or a full browser. Others are much more natural on a phone. Attendance, employee actions, notifications and other day-to-day workflows can benefit from an experience designed specifically around the capabilities and constraints of a mobile device.
Going mobile also gives us a more direct relationship with the device. Instead of relying on a browser to sit between Aline and capabilities such as permissions, notifications and location, the application can use the platform more directly.
There is another decision we made deliberately: the mobile application does not need to contain everything Aline can do.
Trying to put an entire business management system onto a phone can make the product harder to use rather than easier. Aline has a lot of functionality, and not all of it belongs in a mobile interface.
So the mobile application is being built around the workflows that actually benefit from being mobile. It is a focused companion to the broader Aline system, not a smaller copy of the desktop application.
The PWA Isn't Going Away Overnight
We are keeping the PWA available while the mobile application is being developed.
The mobile application doesn't have every Aline feature yet, and that is intentional. We would rather build the mobile experience properly and expand it based on what users actually need than rush to reproduce every feature simply so the two platforms look identical.
This also means existing users don't suddenly have to change how they work. The PWA continues to provide access while we build and test the new application.
There is no Play Store or App Store launch to announce yet. We're still in the process of building the application and validating the experience before we make that step.
The Bigger Lesson: Products Have Lifecycles
Looking back, the biggest lesson for me isn't that PWAs are bad or that native applications are always better. It is that technical decisions have a lifecycle too.
When you are launching a product, you make decisions based on what you know at that point. The PWA helped us get Aline to users quickly. It gave us a mobile experience without immediately introducing another application to build, distribute and maintain. And most importantly, it actually got used.
But once a product is in the hands of real users, you learn things that you simply cannot learn from development and testing alone.
We learned how employees actually use Aline. We learned where permissions create friction. We learned how much device diversity we need to account for. We learned which workflows matter on mobile and which ones don't. We learned that a technically valid solution can still create unnecessary work for the person using it.
That is part of the lifecycle of a product. Something that is the right decision at launch does not have to remain the right decision forever.
The PWA wasn't a mistake that we now have to erase. It was the mobile experience that made sense for Aline at an earlier stage, and it helped us get the product where it is today.
Now Aline has grown enough for us to make a different decision.
Building for the Product We Have Now
One of the easiest traps in software development is treating an early architectural decision as permanent. Once you've invested enough time into something, it can feel easier to keep patching it than to reconsider the underlying approach.
But products change. Users change. Requirements change. Sometimes the most responsible thing you can do is recognize that the assumptions behind an earlier decision are no longer the same.
That is where we are with Aline's mobile experience.
We are not abandoning the web application. We are not pretending the PWA never worked. And we are not building a mobile app simply because having an app sounds better.
We are building it because after using Aline with real businesses, we have a much better understanding of what the mobile experience actually needs to be.
The architecture that gets a product to its first users doesn't necessarily have to be the architecture that takes it to its next stage.
For me, that is the most useful lesson from this transition.
Building software is not just about choosing the right technology at the beginning. It is about being willing to change that choice when the product gives you enough evidence that it needs to change.
Aline is still evolving, and so is the technology behind it.
About AlineBMS
AlineBMS is a business management system built for growing businesses, bringing HR, payroll, attendance, CRM, tasks, projects and other business workflows into one system.
Explore AlineBMS features | View AlineBMS pricing
AlineBMS is built by Klivo Studios, a technology studio building digital products and custom software from Kathmandu, Nepal.