LOKESH RAVI
Backend Engineer·Bengaluru, India
I build things end to end.
I'm a backend engineer with 3+ years at early-stage startups, where I've built products from the ground up and taken them all the way to production.
- 3+ yrs
- Building production software
- Full-stack
- Backend-first, with product development across the stack
- AI + SaaS
- Agents, chatbots, commerce and SaaS platforms
About
A bit about me
I'm a backend engineer with 3+ years of experience at early-stage startups, where I've had the opportunity to build products from the ground up and take them all the way to production.
Backend is my core strength, but my work doesn't stop there. I've worked across APIs, databases, payments, SaaS workflows, integrations, and frontend when the product needed it. I've also built AI-powered features, including NER-based agents and conversational chatbots.
What I enjoy most is taking a problem, understanding what needs to be built, and figuring out how to make the whole thing work, rather than writing the code for one part of it.
Based in
Bengaluru, India
Currently
Backend Engineer
RangeNow
Education
B.E., Computer Science
K S Institute of Technology
2018 — 2022
Why hire me
What I bring to a team
I come from early-stage startups, where the job is never just writing the code you're handed. You have to understand the business, decide how things should be built, move quickly, and take responsibility when something breaks. Each of these is something I've had to do in production.
I've built a product from scratch
I've taken a product from an empty repository to production, rather than building features inside a system someone else designed.
That meant a commerce platform with merchant onboarding, billing, payment flows, conversation state management, and the infrastructure to keep it running for real merchants.
I start with the problem, not the code
Good backend engineering starts before the code. I make sure I understand what the business needs, what rules the system has to enforce, and what the product is trying to achieve before deciding how to implement it.
From there I translate that into APIs, services, data models, and boundaries that can still change shape as the product grows.
I make slow things fast
When a system is slow I don't assume the obvious component is the culprit. I trace the request path, work out where the time is actually going, and change the execution flow where it matters.
Restructuring how route candidates were filtered before the expensive scoring pass cut response time by roughly 55%.
I keep things working when others don't
Most systems depend on services you don't control. Route planning needs external terrain and weather data, and a single trip estimate can require several upstream calls.
Rather than running them in sequence, I use concurrent execution with bounded parallelism, so independent calls proceed together without unbounded concurrency overwhelming either my service or the provider.
I plan for what happens when things break
The happy path is the easy part. I plan for retries, duplicate requests, and partial failures while the system is being designed.
In payment flows that meant idempotent writes, verifying captures instead of trusting the response, and reconciling transactions that never settled. A retried request should never become a financial or data-integrity problem.
I take things all the way
Working in early-stage startups taught me to move quickly without losing sight of the bigger picture, and to work closely with product and business teams to turn priorities into practical technical decisions.
My responsibility doesn't stop at the merge: I stay with a service through shipping, monitoring it in production, and improving it as the product grows.
Experience
Where I've done it
Three years across two startups and an internal-tools team, mostly owning the service rather than a piece of it.
RangeNowCurrent
Oct 2025 — PresentBackend Engineer
EV charging and trip planning. I handle route planning and the payment flow that runs through it.
Recent work: physics-based range estimation
Route planning is moving from a distance model to a physics model, so the range we quote reflects the actual car on the actual road.
- The estimate combines the vehicle's physical attributes with terrain and weather data, rather than treating range as a flat number per kilometre.
- Energy spent climbing is computed from road gradient, and energy recovered on the descent is modelled through regenerative braking, so a hilly route no longer reads the same as a flat one.
- Terrain and weather come from third-party APIs. Those calls run concurrently with bounded parallelism, keeping response time predictable when an upstream provider slows down.
- Built the route planning service that selects charging stops for a trip anywhere in India and returns realistic arrival estimates.
- Cut response time by roughly 55% by restructuring how candidate stations are filtered before the expensive scoring pass.
- Designed and shipped the payment and refund system, with idempotent writes so a retried request cannot refund the same booking twice.
- Made stations from separate charging networks usable in one app through OCPI, including operators that describe the same physical site incompatibly.
- Reduced the cost of keeping station data current by predicting likely amenities instead of polling every field, and reindexing only changed records.
- Node.js
- TypeScript
- PostgreSQL
- Redis
- Algolia
- GCP
- OCPI
Versalence Infocomm
May 2024 — Sep 2025Backend Engineer
Built a commerce platform that ran entirely inside WhatsApp, along with the billing behind it.
- Built the platform from an empty repository: customers browsed, ordered, and booked appointments without leaving a chat thread.
- Backed each conversation with a state machine tracking exactly where the customer stood.
- Designed the payment layer with duplicate-charge prevention, settlement verification instead of trusting callbacks, and a reconciliation pass for the rest.
- Automated Meta client onboarding so a new merchant could go live without anyone hand-configuring their number.
- Delivered a FastAPI system covering the tender lifecycle from submission through award.
- Node.js
- Express
- FastAPI
- MySQL
- MongoDB
- Meta API
- Botpress
- n8n
Critical AI
Jan 2023 — May 2024Software Engineer
Internal tooling for HR and legal operations.
- Replaced a reimbursement process running on email and spreadsheets with a Flask portal that encoded the approval chain, removing roughly 35% of the manual handling.
- Automated generation of the recurring documents the legal and HR teams produced by hand each week.
- Flask
- MySQL
- MongoDB
Projects
Things I built to understand something
Mostly systems work, built to understand something properly rather than to ship a product.
Qualifies inbound leads over chat, scores them, and hands the conversation to a rep the moment one is needed.
- A single agent loop written directly against the model's tool-use API, without LangChain. Free-text messages are normalised into structured filters passed to fixed tool signatures.
- Scoring and rep assignment are deterministic Python, never model calls, so any lead's placement can be explained and audited.
- Human takeover streams over Server-Sent Events. The agent stops responding the instant a rep replies.
- A Celery beat job finds leads quiet past 48 hours, drafts a follow-up, and routes it to the assigned rep to approve or edit.
- Property search is parameterised SQL against indexed Postgres. pgvector is reserved for the document knowledge base, since similarity search is the wrong tool for filtering on price.
- Python
- FastAPI
- PostgreSQL
- pgvector
- Celery
- Redis
- Next.js
- Docker
Dynamo-DB
A working implementation of the Dynamo paper, in Go.
A masterless distributed key-value store covering the core of the paper: consistent hashing, quorum replication, hinted handoff, and vector clocks.
- A consistent-hash ring with roughly 150 virtual nodes per physical node, so adding a machine relocates one arc of keys. 500 keys across 3 nodes distribute 183/162/155, within about 9% of even.
- Any node coordinates any request against the key's preference list. No primary to forward to, so losing one replica never makes a key unwritable.
- Quorum reads and writes across N replicas, with R + W > N validated at config load. A config that cannot guarantee overlap fails at startup instead of serving stale reads.
- Hinted handoff and sloppy quorum keep writes available during failure, holding a copy on a live stand-in until the replica recovers.
- Vector clocks on every value, compared before overwriting, surviving WAL replay after a crash.
- Go
- BadgerDB
- Gin
- Zerolog
- Docker
Connection Manager
A WebSocket server built for clients that read slower than you write.
A concurrent WebSocket server in Go, written to handle backpressure properly.
- Separate read and write goroutines per connection, so one slow client cannot block others.
- A weighted job queue at 3:1 high-to-low, keeping heartbeats from being starved behind application traffic.
- Outbound sends never block: a 100-message buffer per client, dropping beyond it rather than stalling the server.
- Clean shutdown on SIGINT and SIGTERM, draining in-flight jobs before closing the worker pool.
- Go
- WebSocket
Travel Blog
An early full-stack build, kept here for the record.
A blogging platform with Google OAuth, JWT sessions, and a React client on an Express API.
- React
- Node.js
- Express
- MongoDB
- Redux Toolkit
Skills
What I reach for
Grouped by what it does, not by how well I know it. Everything here has been used on something that shipped.
Languages
- Python
- TypeScript
- Go
- JavaScript
Backend
- FastAPI
- Node.js
- Express
- NestJS
- Flask
- Celery
Data
- PostgreSQL
- Redis
- MongoDB
- MySQL
- pgvector
- Algolia
Infrastructure
- GCP
- Docker
- Pub/Sub
- Cloud Tasks
- Cloud Scheduler
Integrations
- OCPI
- WhatsApp Business API
- Google Maps
- Botpress
AI features
- Tool-calling agents
- NER
- Chatbots
- RAG
- pgvector
Frontend
- React
- Next.js
- Redux Toolkit
Blog
Things I've written up
Usually the result of having to learn something the slow way.
Indexing in SQL
What an index actually is on disk, when the query planner will ignore the one you added, and what it costs on every write.
More at medium.com/@lokeshrk89
Contact
Get in touch
Open to backend and distributed systems roles, with particular interest in payments, infrastructure, and platform teams.
If you have a problem in that shape, or you just want to talk through something in this page, email is the fastest way to reach me and I always reply.
lokeshrk89@gmail.com- GitHub
- github.com/loki4514
- linkedin.com/in/lokesh-r
- Medium
- medium.com/@lokeshrk89
- Phone
- 6363978748