Django developer in Nepal
I build Django backends that are meant to stay up — clean data models, well-shaped APIs, and the unglamorous reliability work that decides whether a product survives its own growth.
What I actually do with Django
I'm Binit Koirala, a co-founder and backend engineer based in Nepal. Most of my Django work now goes into Fasto, the quick-commerce company I co-founded, where I own the backend and the infrastructure it runs on.
Django gets picked for a lot of projects in Nepal because it ships fast. That's true, but it's also how teams end up with a backend that works beautifully at 200 orders a day and falls over at 2,000. The interesting part of the job isn't getting the first version out — it's making the second and third versions possible without a rewrite.
Ten-minute delivery is a backend problem
Fasto promises delivery in ten minutes. That constraint pushes almost every hard decision down into the backend, because a promise measured in minutes leaves no room for a slow query or an ambiguous order state.
The parts of the domain that actually demand care:
- Inventory that reflects reality. Stock has to be accurate per location, not globally. Overselling something you can't deliver in ten minutes isn't a rounding error, it's a broken promise.
- Order state that can't drift. An order moves through placement, picking, dispatch and delivery. Modelling that as an explicit state machine rather than a pile of boolean flags is the difference between a debuggable system and a guessing game.
- Work that shouldn't block a response. Notifications, receipts and downstream syncs belong on a queue. The user is waiting on the order, not on your integrations.
- Reads that stay cheap. Catalogue and availability get hit constantly. Caching those paths deliberately — with a real invalidation story — keeps the database free for the writes that matter.
How I approach a Django codebase
The data model is the architecture
Almost every backend problem I've had to untangle traced back to a data model that encoded an assumption which stopped being true. I spend disproportionate time there first — getting the relationships, constraints and indexes right — because that's the layer that's expensive to change later. Application code is cheap to refactor; production data is not.
APIs shaped for the client that consumes them
I also write the mobile apps, which changes how I design endpoints. When you've had to consume your own chatty API over an unreliable connection, you stop shipping endpoints that need four round-trips to render one screen. That feedback loop is genuinely the most useful thing about working across backend and mobile at the same time.
Boring, observable deploys
A backend is only as good as your ability to ship and watch it. Migrations that run predictably, deploys that are routine rather than an event, and monitoring that surfaces a problem before a customer reports it — that's the DevOps side of the same job, and I don't treat it as somebody else's.
The pattern I keep coming back to: most scaling problems in Nepali startups aren't exotic. They're an unindexed query, a synchronous call that should have been queued, or a data model that made an assumption it shouldn't have. Fixing those is unglamorous and enormously effective.
Stack
- Core: Django, Python, Django REST Framework, PostgreSQL
- Around it: caching, background queues,
Docker, Linux - Delivery: CI/CD pipelines, staged deploys, monitoring and alerting
- Practice: system design, capacity planning, code review, mentoring
Background
Before Fasto I spent several years at Code Himalaya, moving from developer to senior, and led mobile engineering for Sangatha (formerly StretchYo), a US-based habit-building app. I also supervise final-year computing projects at Itahari International College, which keeps me honest about explaining architectural decisions in plain terms rather than jargon.