Start with the work, not the feature list.
I go looking for the repeated handoff, the state nobody wrote down, and the exact moment someone stops trusting the record and reaches for their phone instead.
Backend systems · Products people actually run · Kochi, India
Somebody hands me a mess of spreadsheets, WhatsApp threads and half-remembered rules. I hand back software that holds the day together. Domain, backend, interface, launch, and the awkward week after launch. I stay for all of it.
Engineer the whole useful path.
Engineering practice
The work I enjoy sits between a product question and a system that has to keep its promises.
I go looking for the repeated handoff, the state nobody wrote down, and the exact moment someone stops trusting the record and reaches for their phone instead.
Domain models, permissions, state transitions and failure modes should make the system easier to explain to the person running it. If it takes a diagram to defend, the model is wrong.
Go when the service needs to be small and fast. Flutter when one codebase has to reach every screen. TypeScript for the web. Swift when it should feel native on a Mac. No loyalty, only fit.
A clean backend that never meets a user is a hobby. Quality shows up after contact with product behaviour, deployment, and a Tuesday afternoon with bad connectivity.
Selected decisions
A technology list says what I have touched. These examples say more: the constraint, the engineering concern, and where the result can be inspected.
Built around an offline-ready desktop client that syncs when the connection returns, with event history and auditable business-day snapshots so staff can trace how a number became the number.
↗Donors pay the organisation directly over UPI. Hibah never touches the funds. It structures the rest: reference verification, contribution state, team roles and reminders, so the ledger holds up without a payment gateway in the middle.
↗A small Go package. Enqueue tasks, process them with a pool of workers, decide exactly how failures get another go. Nothing else.
↗Selected work
The operating system for Indian fuel stations. Shifts, nozzles, cash, stock, credit and reports, finally in one record.
Product · Backend · DesktopRecurring giving with a clear trail, from a donor's first enrollment link to the thank-you note.
Product · Data · WorkflowA native macOS theme engine. Change one colour scheme and every developer tool on your machine follows.
Swift · Native toolingA Raycast audio player for the Quran. Pick a reciter, set a verse range, loop it, and keep listening offline.
TypeScript · RaycastPool money with people you trust, and let everyone see where it went. Built for organisers and members alike.
TypeScript · ProductTechnical range
I move across layers when the product requires it, with backend systems as the center of gravity.
Domain modeling that survives the second customer. APIs, concurrent processing, event-driven workflows, and auth that says no to the right people.
PostgreSQL, MongoDB, Neo4j, Redis. Audit histories, ledgers, and the operational state everyone forgets to model until it goes missing.
Docker, Kubernetes, cloud platforms, clients that stay in sync. Deployment, and then the part that matters: what the system does once real people are on it.
Go for the backbone. TypeScript for the web. Dart and Flutter across platforms. Swift for the Mac. Python and SQL for everything in between.
Experience
Current
HCL Cloud Native Labs
By day I build cloud-native backend systems at HCL. Nights and weekends go to my own products, native tools and open source, because the best way to learn what a system needs is to be the one who gets the 11pm bug report.
Backend systems and the shape of a service
Fuzzy problem in, shipped path out
Go
Flutter, TypeScript, Swift, cloud
Away from the architecture diagram
Every fuel station, charity and money-pool runs on handoffs, records and the same fifty decisions made again and again. That is where software earns its keep, and where most of it quietly fails. I bring a designer's eye to backend work and a backend engineer's suspicion to product decisions. Based in Kochi. Two bachelor's degrees, in Commerce and Theology, which explains why I care about both the ledger and the people trusting it.
Start a conversation