In September 2013 I started at IKAS Trading in Islamabad as a billing executive. The job was exactly what it sounds like. Raise invoices, reconcile them, chase the ones that had not been paid, and do it again the next day. I did that, and then the two jobs above it, for eight years and nine months. I still run a trading business today. That background is unusual for someone who builds software, and it changes what I build.
What billing teaches you that a specification never will
My first year was spent inside Busy Accounting Software and MYOB. Not evaluating them or writing about them. Using them, every day, for hundreds of transactions, in a business where a mistake meant a customer arguing at the counter or a supplier ringing about a payment. You learn things there that never appear in a requirements document. That the person entering the data is usually busy, often interrupted, and will find the fastest route through your screen whether or not it is the route you designed. That a field marked mandatory will be filled with a full stop if it stands between someone and finishing a sale. That the report management asks for at month end bears little relation to the data anyone was asked to capture during the month. Most business software fails for that kind of reason, not for a technical one. It is not slow or broken. It just asks people to work in a way that does not match how the work happens.
Then sales, which is a different lesson entirely
I was promoted twice at IKAS, to sales and marketing executive and then to manager, running a team of five. Over that period we lifted sales revenue by around 20% through campaigns, retention work and holding the team to daily targets. What that period actually taught me was how much of a trading business runs on relationships that no system records. Which customer will accept a two-day delay and which will go elsewhere. Which supplier will hold stock for you on a phone call. Which account is worth protecting even when the margin looks thin this quarter. Software cannot capture that, and it should not try. What it should do is stop consuming the hours that could be spent on it. Every evening a manager spends reconciling a spreadsheet is an evening not spent on the accounts that keep the business alive.
Half a billion rupees of stock changes how you think
Since June 2022 I have been retail business manager at Star Electric Enterprises in Saddar, Rawalpindi. Billing, receivables, payables and reconciliation across QuickBooks and Tally ERP. Purchasing and vendor negotiation. A team of eight across sales and operations. Inventory worth more than PKR 500 million to audit, replenish and protect. At that scale, small process failures stop being annoyances and start being money. A one per cent discrepancy is five million rupees. Dead stock is not a line on a report, it is capital sitting on a shelf that could have been buying something that moves. One of the more useful things we did there had nothing to do with technology. We introduced a staff incentive to clear dead stock. Inventory turnover improved and, as it turned out, so did morale, because for the first time the team had a reason to care about the slow-moving items rather than avoid them. I mention that because it is the kind of thing a software vendor never suggests. If all you sell is software, every problem is a software problem. Having run the operation, I know that a good half of what looks like a systems failure is a process or an incentive failure, and no amount of code fixes it.
Building for a business I run myself
We eventually implemented billing and inventory software at Star Electric to tighten daily reporting and reduce stock discrepancies. That is on the site as a case study, and it is the piece of work I am asked about most. It is also the only project I have ever done where I was simultaneously the developer, the client and the person who has to live with the result at seven in the evening when the day's cash is being counted. There is no hiding from a bad design decision in that position. If a screen takes too long, I am the one waiting. That experience made me considerably more conservative about what I recommend to other people. Fewer features. Fewer required fields. Reports that match what the owner actually looks at rather than what a dashboard template suggests. And a strong preference for improving what a business already has over replacing it, because the replacement always costs more than anyone estimates, in disruption if not in money.
Why this matters if you are choosing who builds your system
Ask whoever you are speaking to whether they have run the kind of operation they are proposing to automate. Not observed it. Run it, with responsibility for the numbers at the end of the month. Most will say no, and that is not disqualifying on its own. Plenty of good software is built by people who listened carefully. But it does tell you how much of the domain you will have to explain, and how likely they are to push back when you ask for something that will not work in practice. The projects that go wrong are rarely the ones where the developer could not write the code. They are the ones where nobody in the room had ever done the job the software was meant to support.
Related reading
- The dead stock incentive in full, and why the report was the smaller half of the fix: dead stock is the most expensive thing in your warehouse.
- An honest view of the packages I have run the books on: Busy, Tally, QuickBooks or custom.
- If your shop falls in a category that has to report invoices in real time: what FBR POS integration really involves.
- And the payments side of the same counter: what the 92% digital payments figure means for a small shop.
If you run a retail or trading business
Tell me how your day works. Where the numbers come from, where they get retyped, what you check at closing, and what you cannot see that you wish you could. I will tell you honestly which parts are worth building software for and which are a process problem wearing a software costume. That conversation is free and there is no obligation attached to it. Book it at devsioservices.com/contact, or read about the POS and inventory work at devsioservices.com/services/pos-software-development.
