Somewhere in Kathmandu, one insurance company's entire accounting platform runs on code that one person is responsible for — frontend, backend, database, and the 2am pager when something disagrees with reality. That person is Nimesh Regmi. Next.js and React out front, ASP.NET Core and SQL Server holding the numbers together underneath, and no "backend team" to blame things on. Freelance work runs in parallel: Flutter apps, Django APIs, and multi-tenant SaaS architecture for founders who\'d rather hire one engineer who finishes things than five who are still deciding on a project management tool.
Cross-platform iOS and Android apps in Flutter and Dart, with BLoC-based state management for anything past the toy-app stage — because "just use setState everywhere" is a decision you only make once.
APIs and data layers in Django/Python or ASP.NET Core, relational schema design in PostgreSQL or SQL Server, background jobs via Celery, and multi-tenant isolation done properly with row-level security — not a WHERE tenant_id = ? clause someone will eventually forget to add.
Turning a messy real-world process — billing, complaints, tenant onboarding, who's allowed to see what — into an actual data model and module breakdown before anyone touches a keyboard. The same rigor that goes into an SRS/BRD for a live production system, applied before your project becomes one.
Tell me what the system needs to do and where it can't bend. A short async exchange usually reveals whether this is a good fit — much faster than a call that starts with "so, tell me about your company."
For anything past a quick fix, a short written note comes before code: data model, module boundaries, and which trade-offs are being made on purpose rather than by accident.
Work ships in small, testable pieces instead of one dramatic reveal at the end. Course corrections happen in week one, not in the "final review" meeting where everyone quietly panics.
You get the code, a plain-English summary of the decisions behind it, and enough context that another engineer — or future-you at 2am — can pick it up without needing a debrief call first.
Yes — though "hire" makes it sound more formal than it is. In practice it means: you describe the app, we agree on scope, and it gets built in evenings, weekends, or as a focused short-term engagement, depending on size. No agency layer, no account manager relaying messages between you and "the dev team." I am the dev team.
Anything where "just hire one person who can do the whole thing" sounds appealing — a mobile app that needs a real backend behind it, a multi-tenant SaaS MVP, an internal tool that needs actual data modeling instead of a spreadsheet wearing a UI. If your project currently requires a frontend team, a backend team, and a Slack channel just to keep them talking to each other, that gap is exactly what gets removed.
Both — for different reasons, like owning a bicycle and a car. Django and Python are the default for new APIs and anything that benefits from moving fast without stepping on rakes. ASP.NET Core comes out for existing .NET environments, which happens to be the daily driver on a production insurance accounting platform — the kind of system where "move fast and break things" is not a slogan anyone wants to hear.
By day: sole developer on a core accounting platform for an insurance company — Next.js and React up front, ASP.NET Core and SQL Server holding the numbers together in the back, and exactly zero other engineers to pass the pager to. By night and weekend: a multi-tenant hostel management ERP spec for Nepal's student housing market, and a Python port of an open-source Google Maps scraper that used to be Go and occasionally still has opinions about that.
With a short written brief, not a 45-minute call to establish that yes, you do in fact want a website. Tell me what the system needs to do, who's using it, and any constraints that already exist. From there: a scoped estimate, and for anything nontrivial, a short architecture note before a single line of code gets written — the same discipline used on production systems where guessing is not a viable strategy.
Kathmandu runs on GMT+5:45 — a time zone so specific it looks like a typo, but the upshot is that today's work is usually done before your Monday morning coffee finishes brewing. Communication defaults to written specs and structured PR descriptions rather than meetings, mostly because "can we hop on a quick call" and "quick" have never once appeared in the same sentence truthfully.