Tech Lead at Duleko: What's Live and What's Next
As Tech Lead of Duleko, a bilingual local skills marketplace for Nepal, I own the platform end to end. Here's what's live today - guest browsing, typo-tolerant distance search, price negotiation, per-person call privacy and a native Android build - the one rule every screen is held to, and what we're building next.
I'm the Tech Lead of Duleko, a local skills marketplace for Nepal that connects people who need work done with electricians, plumbers, tutors, drivers, farm hands and anyone else nearby with a skill to offer. We're a small team: Sunil K. Chaudhary is the founder, Dipendra Chaudhary coordinates community and communications, and I own the platform end to end - the web app, the native Android build, the database, and every technical decision and release. I've written before about how Duleko enforces its work lifecycle inside Postgres. This post steps back to cover what's live today, the one rule every screen has to pass, and what's next.
The one rule every screen is held to
Duleko's mission page states it plainly: if someone who isn't technical can't use and understand Duleko, it doesn't matter how well we build. In most communities in Nepal, finding a worker - or finding work - still happens by asking around. The people we're building for are often on phones, on slow connections, and more comfortable in Nepali than English. So the app is bilingual from day one, mobile-first, free to join and free to browse, and every technical decision below starts from that rule rather than from what would be interesting to build.
Look first, sign up later
A signup wall is the fastest way to lose someone who just wants to see whether there's a plumber nearby. So guests can browse the whole public directory - skills, worker profiles, reviews and certificates - without an account. The line is drawn in the database, not the UI: guests get read access to public tables, while phone numbers, messages, work requests, friendships and bids stay restricted to signed-in users. The moment a guest tries to call, message or request work, the app asks them to sign in, and nothing private was ever reachable before that.
There are also no separate worker and employer accounts. Everyone has one profile; adding a skill makes you findable as a worker, and anyone can request work from anyone. One fewer decision to explain at signup.
Search that forgives 'plumbr'
The first version of search had a real bug: it matched names, bios and localities, but never skill names, so searching 'plumber' returned nothing useful. The rewrite is skill-aware and typo-tolerant, using Postgres's pg_trgm similarity on top of a plain substring match, so 'plumbr' still finds plumbers. Results sort by distance, because the nearest available person is usually the one you want.
Skills themselves are open-ended. There's a catalogue of common ones, but anyone can type a skill we don't have a chip for yet, and free-typed skills are just as searchable. A worker can also attach their own rate to each skill, like 'Rs. 100 / switch', so the price conversation starts before the first message.
Agreeing on a price, and on a day
A work request can carry a price, and while it's pending both sides can go back and forth on it: the employer opens, the worker counters or accepts, and so on. Whoever did not make the latest offer is the only one who can answer it - enforced in the database, so nobody can bid twice in a row. Accepting the request locks in the current price.
Once a job is confirmed it books the worker's whole day on their availability calendar. But plenty of jobs are a morning's work, so if a job is marked done before 10 AM Nepal time, the rest of the day opens back up and the worker can be booked again instead of being locked out until midnight.
Privacy people can actually control
Every person chooses who can call them: everyone, only people they've had an accepted job with (the default), friends only, or nobody. That setting decides who can see their phone number, and therefore who gets a working Call button. Chat stays open so people can ask a question before committing, but a message containing a phone number is rejected - otherwise the call setting would be one copy-paste away from meaningless.
Location is private by design. Instead of sharing the phone's GPS, each person picks a work area once on a map, and that exact point sits in a table only they can read. Other members see the middle of its ~1 km square (a shop or workshop can opt in to its exact spot), guests only see how many people are in each ~5 km area, and the other side of an accepted job can open the exact place while the job is active. And trust signals like the verified badge and staff roles live in their own tables, apart from the profile row, so nobody can grant themselves a badge through the ordinary 'edit my profile' path.
The badge itself now means something checkable. To get verified, a member sends a photo of their citizenship certificate, national ID card, driving licence or passport. The photos sit in a private storage bucket that only the owner and staff can open, through links that expire after 10 minutes, and staff approving an ID is the only way the badge gets added - the app can't write it at all. Changing your name removes it until the new name is checked, because the badge vouches for the name on the ID.
A real Android app from the same codebase
Duleko is a React 19 and TypeScript web app, and Capacitor wraps that same codebase into a native Android app on Google Play, so there's one product to maintain rather than two. Native details are where it stops feeling like a website: alerts land in the notification bar without a push service, the unread count shows as a badge on the launcher icon, the app and store icons carry the Nepali wordmark, the header and tab bar sit correctly around Android's system bars, and Google sign-in opens in a Chrome Custom Tab, because Google refuses to sign anyone in inside a WebView.
A few smaller things exist because of who uses the app. Anyone can download their profile as a shareable card with their photo, skills and a QR code, carrying the line 'Your skills. Our community.' - useful where a lot of work still gets found through WhatsApp groups and word of mouth. And every new member gets one welcome alert, by email too if they joined with one, that walks through the two things worth doing first: complete your profile, then get verified. Sunil's account and mine stay open to chat with, so a question still reaches a person on the team.
What's next
Since this post first went up, much of the original list has shipped: a job board where you post what you need and workers send offers, the map, payment details, Duleko's monthly fee billed by Nepali month, Android alerts in the notification bar, joining with a mobile number, and ID checks behind the verified badge. What's still deliberately not built:
- SMS codes for mobile sign-in. You can now join and sign in with a Nepali mobile number and a 6-digit PIN, but there's no SMS check yet, so sign-up refuses easy PINs and leans on rate limits. Pointing the sign-in hook at an SMS provider turns codes on.
- Payments through Khalti and eSewa. Members can list their bank, eSewa and Khalti accounts, but money still moves directly between the two people, and Duleko never holds or guarantees it. Integrated payments would change that, so it gets built with the same care as everything else that handles trust.
- Web push notifications. The Android app now shows alerts without any push service, but the website still alerts only in-app, by email and by opt-in SMS, and each SMS costs money.
- More districts. Kapilvastu, Rupandehi, Dang, Kathmandu and Lalitpur have full municipality lists today, and every other district accepts free text. Growing that list follows where the community actually grows.
Duleko's database has 64 migrations so far, and most of them exist because a real person hit a real problem - a search that found nothing, a worker locked out of a day that was mostly free, a phone number shared around a privacy setting. Being Tech Lead here has mostly meant saying no to features that would be interesting to build and yes to the ones that make the app clearer for someone who should never have to think about the technology underneath. That will stay the rule for everything on the list above.
