Rojit Pokharel — known online as @rojeets — is a Full-Stack Web Developer and System Architect from Kathmandu, Nepal. He publishes code under @rojeets on GitHub and GitLab, writes on Medium and Hashnode, and releases open-source packages such as @rojeets/git-stats.

Is Rojit Pokharel a web and web app developer in Kathmandu, Nepal?

Yes. Rojit Pokharel is a Full-Stack Web Developer and System Architect based in Kathmandu, Nepal, specializing in production web applications, e-commerce platforms, SaaS products, and API development using Laravel, Django, React, and Next.js.

What kind of websites and web apps does Rojit build?

Custom web applications, e-commerce and multi-vendor marketplaces, restaurant management SaaS, insurance claim platforms, travel booking systems, API services, and server monitoring tools.

Which technologies does Rojit Pokharel specialize in?

Laravel and PHP for the backend, React and Next.js for the frontend, Django for Python projects, and MySQL or PostgreSQL for databases. He also handles server setup with Nginx, Docker, and Linux.

How do I hire a web developer in Kathmandu?

Reach out through the contact page or email info@rojitpokharel.com.np. Rojit is open to freelance projects and full-time opportunities and typically responds within 24 hours.

Does Rojit work with clients outside Nepal?

Yes. While based in Kathmandu, Nepal, he works with local and international clients, communicating in English and delivering production-grade applications.

Live Orders· 2025

Restaurant Management SaaS

Multi-restaurant SaaS platform with real-time kitchen display via Laravel Reverb, multi-gateway payment integration (Khalti, eSewa, Stripe), and full admin panels for menu, orders, and staff management.

Technical case study by Rojit Pokharel — Full-Stack Web Developer & System Architect, Kathmandu, Nepal

LaravelFilamentReverbLivewireMySQLStripe

Stack diagram

Frontend

Livewire

Application

LaravelFilament

Real-time

Reverb

Payments

Stripe

Data

MySQL

Client / Problem

›Restaurant chains managing multiple outlets struggled with scattered order channels, manual kitchen coordination, and inconsistent payment handling.
›Orders placed at a counter or online had to be verbally relayed to the kitchen, causing delays, mistakes, and no audit trail.
›Owners had no central view of menus, staff, or revenue across outlets, and no way to reconcile payments across Khalti, eSewa, and Stripe.
›An off-the-shelf POS did not fit Nepal's payment landscape or the operational flow of multi-outlet restaurant chains.

Client: Restaurant chains and multi-outlet food businesses in Nepal

My Role

›Full-stack developer responsible for the complete Laravel SaaS build — database schema, API layer, real-time kitchen system, payment abstraction, and Filament admin panels.
›Designed the multi-tenant architecture and the payment gateway abstraction layer.

Architecture

›Multi-tenant SaaS with database-level isolation — each restaurant gets its own schema so queries stay fast and tenant data stays clean as the platform scales.
›Laravel backend with Livewire for reactive admin interactions and Laravel Reverb (WebSockets) for real-time order push.
›Queue workers process payments and notifications asynchronously so the HTTP request cycle stays responsive.
›Filament v5 admin panels give owners menu, order, staff, and analytics management without custom dashboard work.

Database Design

›Schema designed around tenants: restaurants, branches, menus, menu modifiers, orders, order items, payments, staff, and roles.
›Database-level tenant isolation using separate schemas per restaurant rather than a shared-table tenant_id pattern.
›Indexed order and payment tables for the high-write workload of a live kitchen ordering system.
›Order items and modifiers normalized to keep kitchen ticket generation fast and reporting accurate.

API Architecture

›RESTful JSON API for the frontend and mobile-facing flows, with Laravel form request validation on every endpoint.
›Payment gateway abstraction pattern routes a charge to Khalti, eSewa, or Stripe based on restaurant region and configuration.
›Webhook endpoints reconcile payment statuses asynchronously, with retry logic and idempotent processing to prevent double charges.

Code

Payment gateway routing based on restaurant region

$gateway = match($restaurant->region) {
    'nepal' => $restaurant->payment_method === 'khalti'
        ? new KhaltiGateway()
        : new eSewaGateway(),
    default => new StripeGateway(),
};

$gateway->charge($order->total, $order->paymentMeta());

Authentication

›Laravel Sanctum token authentication for API clients.
›Role-based access via Spatie Permissions — owner, manager, and staff roles scoped within the tenant schema.
›Filament Shield secures the admin panels so staff only see the resources their role allows.

Real-time Systems

›Laravel Reverb WebSocket server pushes new orders to kitchen display screens the moment an order is placed — no polling, no page refreshes.
›Order status updates (received, preparing, ready, served) broadcast to the kitchen display and owner dashboard in real time.
›Connection management handles reconnects and missed events so the kitchen display never silently misses an order.

Payment Architecture

›Multi-gateway integration supporting Khalti, eSewa, and Stripe in one payment abstraction layer.
›Region-based gateway routing: Nepal-based restaurants use Khalti/eSewa, international use Stripe.
›Webhook reconciliation with automatic retries and idempotency keys to keep financial records accurate.

Deployment

›Production deployment with Docker Compose — Nginx, PHP-FPM, MySQL, Redis, and the Reverb WebSocket server as separate services.
›Certbot SSL via Nginx, Supervisor-managed queue workers, and PM2 where Node services were involved.
›Environment-based configuration across staging and production.

Performance Optimization

›Database-level tenant isolation kept multi-restaurant queries fast even as tenants grew.
›Queue workers offloaded payment processing and notifications from the request cycle.
›Real-time WebSockets replaced polling, cutting unnecessary HTTP traffic for kitchen displays.

Problems Encountered

›Reconciling payments across three gateways with different webhook payloads and retry semantics.
›Keeping kitchen display screens in sync during brief network disconnects.
›Designing a tenant model that scales without leaking data between restaurants.

How I Solved Them

›Built a gateway adapter per provider and a normalization layer so the rest of the app sees one payment interface; added idempotency keys for webhook reconciliation.
›Implemented reconnection and catch-up logic in the Reverb client so missed events are re-synced on reconnect.
›Chose database-level tenant isolation with middleware that locks every query to the active restaurant schema.

Results

›Runs in production for multiple restaurant chains, handling daily orders and staff coordination.
›The real-time kitchen display cut average order-to-preparation time by eliminating the lag between POS and kitchen.
›Owners get a single dashboard across outlets and reconciled multi-gateway payments.

Lessons Learned

›Real-time features belong on the critical path for any restaurant operation — milliseconds matter in a kitchen.
›Payment abstraction must be built before the second gateway is integrated, not after.
›Tenant isolation choices made at schema design time are the most expensive decision to reverse later.

Want a production system like this?

I build production web applications end-to-end. Let's discuss your project.

Get in Touch

Restaurant Management SaaS

Production Web Applications: Six Real-World Projects That Deliver Results

Payment Gateway Integration in Nepal: eSewa, Khalti, ConnectIPS & International

Read the Answers

Want a production system like this?