AlineBMS is a product I've been building with Klivo Studios to bring more of a business's day-to-day work into one system.
The idea behind it came from a problem we kept seeing: businesses were using one tool for customer management, another for HR, spreadsheets for attendance, something else for payroll, and yet another tool for managing projects and tasks.
Each tool solved a problem on its own.
The problem was everything in between.
Information had to be copied from one place to another. Teams had to switch between systems. Important context got lost. And as the business grew, the number of tools grew with it.
We wanted one connected system for the work that keeps a business moving.
One connected system for the work that keeps a business moving.
Where AlineBMS started
We kept running into the same pattern while working with businesses.
Customer information was in one place. Tasks were somewhere else. Attendance lived in spreadsheets or another system. Payroll meant bringing information together manually.
None of these tools were necessarily bad. They just weren't connected.
That's when we started asking:
What if the different parts of a business could work from the same system and the same underlying information?
That question became the foundation for AlineBMS.
Rather than building another tool for just one department, we wanted to connect the workflows that businesses deal with every day.
What AlineBMS does
AlineBMS brings customer work, people operations, execution, and support into one workspace.
HR and attendance
Aline's HR suite brings employee records, departments, attendance, leave, and related people operations together.
Attendance can use geofencing to verify where employees check in, while leave requests can follow defined approval workflows.
This information then becomes useful elsewhere in the system instead of becoming another isolated HR dataset.
Payroll
Payroll is one of the areas where that connection becomes particularly important.
Aline can use attendance and employee information as part of the payroll workflow, including support for Nepal-specific SSF, CIT, and IRD tax calculations.
Instead of exporting attendance, opening a spreadsheet, calculating salaries, and manually preparing payslips, the goal is to keep that process inside the same system.
For a product built from Nepal, supporting local payroll requirements wasn't something we wanted to treat as an afterthought.
Sales and CRM
Aline's CRM handles the journey from the first enquiry to the customer relationship.
Teams can capture and assign leads, manage pipelines, track follow-ups, maintain customer accounts, create quotations, and keep customer history in one place.
The goal isn't just to have a pipeline.
It is to make sure that when a lead becomes a customer, the context doesn't disappear.
Projects and tasks
Running a business isn't just about winning customers. Someone still has to do the work.
Aline's project and task tools let teams create projects, assign tasks, set deadlines, run meetings, track recurring work, and keep progress visible.
Projects can also connect back to customers and other parts of the business, giving teams more context around the work they are doing.
Marketing and connected tools
Aline also includes tools that connect marketing and operational workflows.
Website forms can feed leads directly into the CRM, while email campaigns can be managed from the same platform. Assets and inventory can also be tracked with their own workflows.
These aren't meant to turn Aline into a collection of unrelated features.
The point is to make the information generated by one part of the business useful to another.
Support and tickets
Customer issues and internal requests can be managed through a shared ticketing workflow.
Instead of important issues disappearing into email threads or separate communication channels, teams can keep them in a queue, assign ownership, and track what happens next.
The important part is the connection
The feature list is probably the easiest way to describe Aline.
But it isn't the most important part.
The real idea behind the product is what happens between those features.
A lead becomes a customer.
A customer has projects.
Projects have tasks and people working on them.
Employees have attendance and leave records.
Attendance and leaves contribute to payroll.
Support issues are connected to customers.
And the business can see information from all of these areas without constantly moving data between systems.
The feature list is probably the easiest way to describe Aline.
But the feature list isn't really the point.
The interesting part is what happens between those features.
Built for the stage where spreadsheets stop being enough
Aline is designed primarily for growing teams.
There is a particular stage where a business becomes too complex to comfortably run on spreadsheets and disconnected tools, but a traditional enterprise system can feel like far more than the business actually needs.
That's the stage we're building for.
Aline is built for teams that need more structure without adding unnecessary bureaucracy.
That affects a lot of product decisions.
We don't want every feature to come with another layer of configuration. We don't want a dashboard filled with information just because we can display it. And we don't want the product to require a huge implementation project before a team can start using it.
The goal is fairly simple:
Powerful enough to handle a growing business, simple enough to use every day.
Building from Nepal, building for the world
AlineBMS is being built from Nepal, and that has influenced the product in practical ways.
Payroll is a good example.
Local businesses have specific requirements around SSF, CIT, and IRD tax calculations. Those aren't generic international payroll concepts that can simply be added later.
They are part of how businesses here actually operate.
So Aline includes Nepal-ready payroll workflows alongside the broader business management system.
But we don't want Aline to be a Nepal-only product. The workflows we're building around CRM, HR, projects, support, and operations are relevant to growing businesses well beyond Nepal.
Aline AI
AI is another layer we've been adding to Aline.
But we didn't want to add an AI chatbot just so we could put "AI-powered" on the homepage.
The interesting part is that Aline already has a lot of business information to work with.
The system knows about deals, customers, tasks, attendance, payroll, projects, and support.
That means it can potentially identify things that deserve attention before someone manually goes looking for them.
For example:
a deal that hasn't had a follow-up in several days
employees with unusual attendance patterns
overdue tasks
payroll deadlines approaching with incomplete information
other operational signals that might otherwise get missed
The idea behind Aline AI is therefore less about asking an AI random questions and more about making the next useful action easier to see.
Designing around clarity
One of the things I care about most while building Aline is how much information we ask people to deal with.
Business software naturally becomes complicated.
There are employees, customers, permissions, projects, invoices, attendance records, payroll rules, reports, deadlines, and countless small pieces of information.
The answer isn't to hide all of that.
It is to organize it well.
That led me to a simple product principle:
Complex businesses don't necessarily need complicated software.
The system can be powerful underneath while still presenting people with a clear next step.
That principle affects everything from the information architecture to individual screens and workflows.
My role in building Aline
I've worked across both the product and technical sides of Aline.
That includes development, UI and UX decisions, product direction, figuring out how different workflows should connect, and working through the practical problems that come up when you try to turn an idea into software people can actually use.
It has also changed how I think about building products.
Writing the code is only one part of it.
You have to decide what is actually worth building.
You have to figure out whether the problem is real.
You have to explain the product to someone who has never seen it before.
You have to watch where people get confused.
You have to hear "we don't need this" after spending days building something.
And then you have to decide what to change.
That feedback loop between building, showing, listening, and rebuilding has probably been one of the most valuable parts of working on Aline.
Where Aline is now
AlineBMS is no longer just an idea or a collection of early screens.
It is a working product with connected workflows across CRM, HR, attendance, payroll, projects, support, marketing, and AI.
But it is also nowhere near finished.
There are still workflows to improve, features to rethink, assumptions to test, and new problems to solve.
We're also exploring more focused products and industry-specific workflows around the same foundation.
The direction is still the same:
Build useful business software that removes operational friction instead of adding to it.
That's where AlineBMS is today.
It's a working product, but there's still a lot left to figure out. And that's probably what makes building it interesting.
I'm not just learning how to build software through Aline. I'm learning how to decide what deserves to be built in the first place.