Kothay

Kothay means “where” in Bangla, and the product is that question asked all day: where is the field team, did they reach the shop they were supposed to reach, and did the visit turn into an order. I worked on it as a full-stack developer, across the Laravel API and the React Native app that field staff actually hold.

Every constraint that shaped this product came from the same place. Not the manager reading reports in an office in Dhaka, but a sales rep on a motorbike with a cheap Android phone, patchy coverage, and a hundred shops to cover this week.

The person using it does not have an email address

Most software assumes an email address is free. For a field sales rep in Bangladesh it is not: there is no work account, personal email may not exist, and a forgotten password reset that arrives by email is a support call that ends the working day.

Enlarge

So the identity is the phone number, the credential is a PIN, and the convenience is the fingerprint reader the phone already has. Accounts are created by a manager rather than by self-signup, which quietly settles a lot of questions: who owns the account, who can reset it, and what happens when someone leaves. The app runs in Bangla and English, and shop names in the database arrive in both, sometimes in the same list.

A working day is hundreds of GPS points

The location history for one staff member on one day in the product shows 429 recorded points between a 12:05am check-in and an 8:01pm check-out. Multiply that by a distribution team and the tracking table is the busiest thing in the database, which makes it the first thing to get the design attention.

Enlarge

Two flags on each point do most of the work. One says the point was captured while the phone had no network, which matters because the alternative is a gap in the trail that looks like someone stopped working. The other says the point fell outside the assigned zone. The app keeps recording either way and syncs when coverage returns, so the timeline gets filled in rather than lost.

The thing nobody warns you about is that GPS lies politely. It bounces off buildings, drifts indoors, and reports a rep as fifty metres inside the neighbouring block. So a single point is never evidence of anything. Sequences are.

A geofence is a claim about the world

Territory in Kothay is a zone, drawn on a map either as a circle or as a polygon of coordinate points, and named after the place it actually is: Motijheel, Uttara Sector 11, Mirpur Shewrapara, a road in Dhaka 1205. Staff are assigned to zones, shops belong to zones, and every visit and every order gets resolved against the boundary.

Enlarge

Those two badges are where the engineering meets the human problem. “Outside the zone” is a true statement about geometry and a loaded statement about a person. A rep can be legitimately outside their zone: a customer moved, a delivery got reassigned, the boundary was drawn carelessly in the first place. The right design records the fact plainly, shows the manager the coordinates and the time, and stops there. It does not decide guilt in a badge colour.

The unglamorous half is the editor. Someone has to draw twenty-five zones over a city, and they are doing it on a laptop between other jobs, so drawing has to tolerate being wrong: add a point, drag it, delete the shape, confirm before anything is disabled. Zone geometry that is painful to correct becomes zone geometry nobody corrects.

Maps are metered, so the plan meters them too

Google Maps Platform bills per load. Kothay sells for 199 taka per staff member per month, which is roughly one and a half US dollars, and that number has to cover hosting, storage, support and the maps. So the subscription plan states the map budget openly: a fixed number of map views per staff per month, a cap on zones, and a cap on coordinate points per zone.

I have not seen many products put a vendor quota on the pricing page, and I came to like it. It turns an invisible cost into a product rule, and it forces the right engineering: do not open an interactive map when a static image answers the question, do not re-render a trail a manager is not looking at, and treat “show me the live map” as a deliberate action rather than a page decoration. The alternative is a beautiful dashboard that loses money on every customer who uses it.

An order is a document that has to survive a bad network

The point of all the tracking is the order. A rep standing in a shop picks products from a catalogue, in the units the trade actually uses, kilograms and pieces, gets a total, and submits. The order then moves through pending, processing, dispatched and delivered, and everyone involved gets a notification and a printable memo with a QR code on it.

Enlarge

Two details in that screen took real thought. The first is the stock availability flag: a rep in a shop cannot see the warehouse, so an order can be taken for something that ran out an hour ago. Blocking the order is wrong, because the sale is real and the shopkeeper is standing there. Recording it and flagging it is right, because someone in the office can then decide.

The second is that an order carries where it was taken. Not as surveillance theatre, but because the order and the visit are the same event, and a sales figure that cannot be tied back to a shop and a time is the kind of number that starts arguments nobody can settle.

Plan versus actual, and the honesty of numbers

The report a manager reads is a beat plan compared against a day: should visit twelve shops, visited twelve shops, ten orders. That comparison is the most useful thing the product produces, because it is the one number pair that turns tracking into a conversation about workload rather than a conversation about trust.

Enlarge

That last point is the one I would carry into any product like this. The demo data on the activity screen shows more break time than work time, which is either a rep having an unusual day or a check-out that never happened. Both readings are ordinary. Software that reports durations without letting someone correct the record is not measuring work, it is generating disputes.

What building it taught me

Design for the worst device and the worst network on the team, not the average one. Every decision that looked like a compromise for cheap Android phones and patchy coverage, PIN sign-in, offline capture, static maps instead of live ones, made the product better for everybody, including the manager on office wifi.

Put your metered costs in the product, not in a spreadsheet you check quarterly. And when you build software that watches where people are, write the ambiguity into the data model. A point that knows it was captured offline, and an order that knows it was taken outside the zone, are the difference between a record a person can explain and a number they have to argue with.