Kothay.app - Field Sales Tracking Software for Bangladesh

Built for the Field, Not the Office

Kothay.app is field sales tracking software for the people who spend their working day outdoors. A salesman leaves in the morning with a route to cover, walks or rides between shops in Dhaka traffic or along a rural road, checks in at each one, takes orders, records what did not sell and heads to the next. Kothay is the Android app in his pocket that records all of it, and the web dashboard where his manager sees the day as it happens rather than hearing about it a week later.

THESOFTKING delivered the whole platform: consultancy and product planning, UI/UX design, the Bangla-first Android application, the web dashboard and backend, the servers and network it runs on inside Bangladesh, and the ongoing support that has kept it live since launch. Three to four people over eight months, for distributors, FMCG and pharmaceutical companies, delivery businesses and field service teams whose revenue depends on knowing where their people actually are.

The Challenge: Everything Happens Somewhere With Bad Signal

Most sales software is designed for someone sitting at a desk on office wifi. Kothay had to work for someone standing outside a shop in a district town, on a mid-range Android phone, on prepaid mobile data, at the edge of a mobile cell, in the middle of a working day that has another twenty shops left in it. Every assumption that makes software comfortable to build was unavailable.

The load is relentless in a way desk software never is. A tracking app is not sending a request when a user decides to do something; it is reporting position continuously, for every rep, for the entire working day. Multiply that by a customer's whole field team and the platform is absorbing a constant stream of small writes from thousands of phones on unreliable connections, where each one still has to feel instant to the person holding it.

And the product only has value if the data is believed. A manager buying salesman tracking software is buying confidence that a check-in at a shop means somebody was at that shop. The moment that confidence goes, the subscription is worthless no matter how good the reports look.

Infrastructure: Hosted in Bangladesh, Peered on BDIX

Every user of Kothay is in Bangladesh. Hosting the platform anywhere else means every location ping, every check-in and every order placed by a rep in a district town leaves the country, crosses international transit, and comes back. That round trip is paid on every single request, all day, by every phone in the field.

So Kothay runs on our own hardware and our own network inside Bangladesh, peered on BDIX, the national internet exchange. Traffic between a rep on a Bangladeshi mobile network and the servers stays domestic: it reaches the exchange and comes back without ever touching an international route. On a good office connection the difference is a technical detail. On a congested mobile connection at the edge of coverage, where the app is already fighting for every packet, it is the difference between a check-in that registers while the rep is still standing at the shop door and one he has to stare at and retry.

Owning the hardware and the network rather than renting capacity abroad also means the platform's performance is something THESOFTKING can actually fix. When a customer in Rangpur says the app feels slow, the path between that phone and the database is one we operate end to end, not a support ticket with a hosting provider on another continent. We specified it, we built it, and we run it: monitoring, capacity, backups and releases.

The Android App: A Full Working Day on One Battery

The naive way to build location tracking is to ask the phone for its position every few seconds and upload each fix. It works perfectly in testing and fails completely in the field: the battery is flat by early afternoon and the rep has burned through prepaid data he often pays for himself. An app that does that does not get uninstalled by the company. It gets switched off by the person carrying it, which is worse, because the manager keeps paying for data he is no longer getting.

Kothay uses adaptive polling instead. The app varies how often it asks for a position based on what is actually happening: frequent fixes while a rep is moving between shops, far fewer while he is stationary inside one, because a phone that has not moved in twenty minutes has nothing new to report. Geo-fences do the rest of the work. Rather than polling continuously to work out whether someone has arrived somewhere, the app registers zones around the shops on a route and reacts when one is crossed, so arrival and departure are events the operating system reports rather than something the app has to keep checking for.

The effect compounds. Fewer fixes means less GPS radio time, which is most of the battery cost; fewer fixes also means fewer uploads, which is most of the data cost. The result is an app that a rep can leave running from morning to evening without thinking about it, which is the only version of this product that works, because a tracking app that people want to switch off tracks nothing.

Keeping the Data Honest

Every salesman tracking product in the world has the same adversary, and it is not a hacker. It is a rep who would rather report a shop visit than make one. Mock location apps are a free download and a single toggle in developer options, and if they work, the entire product collapses: the manager is looking at a dashboard of visits that never happened, making decisions on it, and paying a subscription for the privilege.

Kothay treats spoofing as a first-class problem rather than an edge case. The app checks whether a position came from a real satellite fix or was injected by another application, and location data that does not hold up is flagged rather than silently accepted. The same information that makes the product useful also makes tampering visible: a genuine day in the field has a shape to it, with travel time between shops and time spent inside them, and fabricated positions tend not to fit that shape.

As with any anti-abuse problem, this is an ongoing arms race rather than a solved one, and it is treated that way. What matters commercially is that a manager can trust the dashboard enough to act on it, and that a rep knows the numbers he is measured against are the same numbers everyone else is measured against.

Offline by Default

Connectivity in the field is not a binary. A rep does not go offline and come back; he moves through patchy coverage all day, losing signal inside a building and regaining it on the street. So the app never treats the network as a precondition for work. Check-ins and orders are captured on the device and queued, and the queue drains as soon as a usable connection returns. From the rep's side, nothing about taking an order changes based on whether there is signal, which is the only behaviour that makes sense to someone with a shopkeeper waiting in front of him.

The genuinely hard part of offline work is conflict: what happens when the price a rep quoted this afternoon is not the price the system holds by the time his order syncs. The answer here came from the business rather than the code. Distributors change prices at night, not in the middle of a selling day, and a manager enters them in the evening for the following morning. So the app pulls a fresh catalogue and price list at the start of each day and works from it, and by the time prices move again the day's orders are already in. Conflicts are not resolved cleverly so much as designed out, by building the sync cycle around the rhythm the business already runs on.

Bangla First

The app is bilingual, and Bangla is not the translation. It is the default, because the person using the Android app all day is a field salesman in Bangladesh, and asking him to work in his second language while standing in front of a customer is a tax on every interaction. English is there for the office side, where managers and owners often prefer it, and both are first-class rather than one being a fallback.

Designing Bangla-first is a real constraint rather than a switch. Bengali script sets differently from Latin, strings run longer, and a layout that looks balanced in English will break in Bangla if the translation is bolted on at the end. Building it in from the start meant the interface a rep uses is genuinely his, not an English product with a language toggle.