On 6 April 2011, Dr. Aarzoo Saini and I started a business called Acmez Business Solutions in Roorkee. That first year we built point of sale and inventory software for distributors. In 2012 we built software for clinics with more than one location, in 2014 for hotels and restaurants, and in 2018 for school administration. There was also international work, including a franchise management system for a large retail chain operating in the United States and Canada. In 2017 the business was incorporated as Acmez Technologies Pvt. Ltd., and other organisations followed.
Fifteen years is long enough for patterns to become visible. This essay collects the ones I believe matter most for anyone building software for ordinary businesses, especially from a small city.
Customers do not buy software, they buy a quieter day
Early on it was tempting to describe our work in terms of features. Customers rarely cared. A distributor wanted the counter queue to move faster and the stock figures to be right at the end of the day. A clinic wanted fewer missed appointments and less confusion between branches. A school wanted fee collection without arguments.
Once we started describing what would be different about their day, conversations became easier and the software became better. Features that did not change anyone's day started to look like what they were: cost.
The busiest moment defines the product
Every business has a moment when the software is under the most pressure. For a distributor it is the morning rush at the billing counter. For a restaurant it is the dinner service. For a clinic it is a crowded outpatient session. For a school it is the week fees are due.
Software that performs well at that moment is loved. Software that slows down at that moment is abandoned, regardless of how good its reports are. We learned to design, test and optimise for the busiest moment first.
A practical test
Before releasing anything, ask a real user to perform the most common task as fast as they would during their busiest hour. Watch without helping. Every hesitation is a design problem.
Support calls are the best research you will ever get
Small software companies cannot afford research departments. Fortunately, they receive something better: support calls. Each call tells you where the design confused someone, where the process in the software differs from the process in the business, or where a rare case was never considered.
We found it valuable to keep senior people, including founders, close to support. The discomfort of hearing the same problem three times in a week is the fastest route to fixing it properly.
Different industries, the same underlying problems
Distribution, healthcare, hospitality and education look nothing alike from outside. Inside the software, they share a surprising amount:
- Identity: customers, patients, guests or students, and the records attached to them.
- Inventory: stock, medicines, ingredients or books.
- Money: invoices, fees, payments, credit and refunds.
- Time: appointments, tables, classes, delivery schedules.
- Permissions: who can see and change what, especially across branches.
Recognising this helped us build more reliable systems faster. It also taught a lesson that later shaped my thinking about technology in healthcare: the operational core of a clinic is familiar software territory, while the clinical core is not, and confusing the two leads to poor records.
Small, steady customers build durable businesses
There is a common belief that a technology company should chase large clients. Large clients can be valuable. But a base of many small, steady customers who depend on the software every day creates a different kind of strength: predictable work, direct feedback and resilience when any one relationship changes.
It also keeps a company honest. A small business owner will tell you plainly, and quickly, when something is not worth paying for.
Building from a small city
Starting a technology company in Roorkee rather than a large metro had real constraints: a smaller local market, fewer experienced hires and the assumption, among some clients, that serious software came from elsewhere.
It also had real advantages. Customers were close enough to visit. Teams could be built from local graduates willing to learn, and trained carefully. Costs were manageable, which made patience possible. And today, with remote collaboration normal, location matters far less for the quality of work than it did in 2011.
The teaching work that led to founding AIIT Roorkee in 2025 grew partly from this experience. Capable students in smaller cities often lack practical exposure more than ability.
Mistakes worth naming
Fifteen years also leaves a list of mistakes. A few are worth sharing because they are common:
- Saying yes to every customisation. Each one felt like good service. Together they made systems harder to maintain for everyone.
- Underestimating training. Software that is not taught properly is blamed for problems it did not cause.
- Delaying documentation. Knowledge held by one person becomes a risk the day that person is unavailable.
- Quoting for effort rather than value. Customers care about outcomes, and conversations about outcomes are clearer for both sides.
None of these is fatal. All of them are easier to avoid than to fix.
What stays constant
The technology has changed completely since 2011. Desktop software gave way to web and mobile, local servers to the cloud, and now AI is reshaping what business software can do. The essentials have not moved: understand the customer's day, respect their busiest moment, listen to support, keep things simple and stay long enough to earn trust.
Those essentials are also, I have found, a reasonable description of good clinical practice. But that is another essay.
Questions
Frequently asked questions
What kinds of software has Acmez built?
Since 2011 its teams have built software for distributors (point of sale and inventory), multi-location clinics, hotels and restaurants, and school administration, as well as international work including a franchise management system for a retail chain in the United States and Canada.



