Business software is what I build for a living now, and a trading counter in Rawalpindi is where I learned what it has to survive. In September 2013, years before I built any software, 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 business software, and it changes what I build. This is what that retail trading experience taught me, and what it means if you're about to pay someone to build a system for your shop or warehouse.
On this page
- What billing teaches you that a specification never will
- Then sales, which is a different lesson entirely
- Half a billion rupees of stock changes how you think
- Building software for a business I run myself
- 9 business software lessons from the counter
- What a trading day looks like, and where software fits
- Software mistakes I see in Pakistani trading businesses
- Questions I ask before I build anything
- What good billing and inventory software does at closing time
- Business software: build, buy or configure
- What to have ready before you talk to anyone
- Why this matters if you are choosing who builds your system
- How that experience shapes the way Devsio works
- Related reading
- If you run a retail or trading business
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, and that retail trading experience is what I lean on most when I design screens now. A few examples.
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 really 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.
Business 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 looks like 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 software 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 the Star Electric POS 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 the business software I recommend to other people. Fewer features. Fewer required fields. Reports that match what the owner really 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.
9 business software lessons from the counter
If I had to hand a trading business owner one page before they spoke to any software house, it would be this one. None of it's clever. All of it came from getting things wrong at a counter first.
I didn't learn any of that from a course. I learnt it from customers arguing at the counter, suppliers ringing about payments, and months where the stock sheet and the shelf didn't agree.
- One. The person entering data is in a hurry. Design every screen for the busiest hour of the day, not a quiet Tuesday morning.
- Two. Every mandatory field you add will be filled with rubbish by someone, eventually. Only make it mandatory if the business breaks without it.
- Three. The report the owner reads at closing time matters more than any dashboard. Build that one first.
- Four. Udhaar, part payments and running balances are normal in Pakistani trade. A system that can't handle them isn't a system for this market.
- Five. Stock that isn't counted regularly is stock you only think you have. The software has to make counting easy, or nobody does it.
- Six. Relationships stay with people. Software should free up their time, not try to replace their judgement.
- Seven. A process problem dressed up as a software problem stays a process problem after you've paid for the software.
- Eight. Improving what you've got is usually cheaper than replacing it, once you count the disruption.
- Nine. If the developer has never closed a day's cash, they'll underestimate how much the small screens matter.
What a trading day looks like, and where software fits
A typical day in an electrical shop in Saddar or a wholesaler in Raja Bazaar runs to a pattern. Stock arrives in the morning and has to be checked against the supplier's bill. Counter sales run all day, some cash, some on credit, some by bank transfer. Dealers ring for rates. Someone chases the receivables. At closing, the cash is counted and the day's book is squared.
Good business software sits quietly inside that pattern. Nobody talks about it. It doesn't add steps. It removes the retyping between the goods received note, the stock register and the ledger. It shows the salesperson the right rate for that customer without a phone call to the owner.
Bad business software adds a new step at every stage, then produces a report nobody asked for. A good one removes a step and says nothing about it. That is the whole test, and it is why I ask to spend a day behind the counter before quoting anyone in trading. Most systems fail on the day, not in the demo. I've seen both, and the difference is rarely the technology. It's whether the person designing it understood the day.
Software mistakes I see in Pakistani trading businesses
Visit enough shops and the same business software mistakes turn up. None of them are unusual, which is exactly why they're worth naming.
Three systems that don't talk
The accounts are in Tally or QuickBooks, stock lives in Excel, and orders come through WhatsApp. Each one is fine on its own. Together they mean someone spends every evening copying numbers between them, and the numbers never quite agree.
Buying for the showroom, not the counter
Owners get shown a polished demo with charts and colours, and buy it. Then the counter staff find it takes six clicks to raise a simple invoice, and they go back to the handwritten bill book. The software's still being paid for. Nobody's using it.
Nobody owns the data
Item names get typed three different ways. Units are mixed: boxes, pieces, coils, metres. Within a year the stock reports are meaningless. No business software can fix that on its own. Someone has to own the item master and keep it clean.
Ignoring tax until it's urgent
Sales tax invoicing and the FBR requirements for some categories of retailer shape what your billing system has to produce. Owners who plan for that when they choose software save themselves a painful migration later. Owners who don't often end up paying twice.
Questions I ask before I build anything
When a trading business owner contacts us, I don't start with features. I start with the same questions I'd have wanted someone to ask me in 2013.
Half the time, the answers point to a configuration fix in the package you already own. That's a good outcome. I'd rather tell you that than sell you a build you don't need.
- Walk me through yesterday, from opening to closing. Where did the numbers come from?
- Where does anything get typed twice?
- What do you check at closing, and how long does it take?
- Which report do you wish you had but never get?
- Who in the shop will use this every day, and how comfortable are they with a computer?
- What happens when the internet or the power goes?
What good billing and inventory software does at closing time
Closing time is where I judge any business software, because that's where I've spent the most tired evenings. If the day doesn't close cleanly, nothing else the software does matters much.
The cash matches, or it tells you why
Good billing and inventory software shows the day's takings split by cash, credit, card and transfer, and it matches what's in the drawer. When it doesn't, it shows you which invoices to check. You shouldn't need a calculator and a register to find a missing five thousand rupees.
Credit is visible, customer by customer
Every credit sale lands against the right customer's running balance the moment it's billed. The owner can see who owes what, and for how long, without asking the accountant to pull a report.
Stock moves with every sale
Each invoice reduces stock on the item that was sold, in the unit it was sold in. When a coil is bought by the coil and sold by the metre, the system copes. That's the detail most imported packages get wrong for our market.
Business software: build, buy or configure
Business software doesn't always mean a custom build. In my experience there are three sensible routes, and the cheapest one that works is the right one.
My retail trading experience makes me lean towards the first two more often than you'd expect from someone who builds software for a living.
- Configure what you've already got. Most packages do more than owners use. A day of setup can remove a week of workarounds.
- Buy a packaged system that fits your trade. For a single shop selling ordinary lines, this is often the answer.
- Build only where your way of trading fights every package: multiple branches, trade credit with named parties, units that change between purchase and sale.
What to have ready before you talk to anyone
You'll get a far better answer, from us or anyone else, if you walk in with these.
That's an hour's work. It usually saves weeks of back and forth, and it tells you quickly whether the person across the table understands business software for a trading counter or just software in general.
- A copy of a typical day's invoices, including a credit sale and a return.
- Your current item list, exported from whatever you use.
- The reports you look at every week, even if they're handwritten.
- A list of the three things that annoy you most about how the day runs now.
Why this matters if you are choosing who builds your system
Ask whoever you are speaking to about business software 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 vendors 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.
How that experience shapes the way Devsio works
We work from an office in G-15 Markaz, Islamabad and a second one at Hathi Chowk in Saddar, Rawalpindi, a few minutes from the kind of shops I've spent my working life in. The team designs and builds everything in-house. Nothing gets handed to a freelancer I've never met.
Every project starts with a discovery conversation about how your day runs, then a fixed-price quote. You can see how we structure that on our pricing page. Fixed price matters to me because I've been the owner on the other side of an open-ended invoice. It's not a comfortable place to be.
And I'll keep pushing for less. Fewer screens, fewer fields, fewer features in version one. That is most of my approach in one line. Business software earns its keep when people use it every day, and people use simple things.
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.
- A plain 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
If you run a retail or trading business and you're weighing up business software, 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 straight 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, read about our custom POS software work, or see how we approach custom software for small businesses. If you're nearby, our software house in Rawalpindi is the easiest place to meet.
