Real builds, real numbers
Not quote snippets. These are the full stories of what we built, how it was architected, what it cost, and what happened after launch.
A production OCPP 1.6-J charging management system running 40+ chargers across 2 cities at 99.7% uptime. Go WebSocket gateway, Laravel billing, Razorpay, and automatic GST invoices.
OCPP is the protocol that lets a charger from one manufacturer talk to management software from another, and getting it right is most of the work. A charger holds a WebSocket open for weeks, drops off mid-session, and reconnects expecting the backend to remember exactly where it was. The interesting part of this build is not the dashboard, it is the state machine underneath it: what happens to a running session when the network goes, how a meter reading that arrives late is reconciled against an invoice already issued, and how billing stays correct when the hardware disagrees with the server about how much energy moved.
Read the case studyOur own managed hosting platform in a single Mumbai region, billed in rupees. It carries 80% of our client WordPress sites and runs PlugEV's whole production stack.
This one is unusual because we are the client. It started as internal infrastructure, which means it is the only project on this list where we carry the pager and pay the bill, and that changes the decisions. Everything sits in a single Mumbai region because latency to Indian users mattered more than multi-region marketing copy. Billing is in rupees because a dollar invoice with a forex markup is a real cost to an Indian business and an annoyance to its accountant. If you want to know what we actually believe about hosting rather than what we would sell you, this is the page.
Read the case studyA free utility suite where image and PDF work runs in the browser through WebAssembly, so files never leave the device. No account, no upload limit, no paywall, built as public proof of the performance standard we sell.
The technically interesting decision here is that the image and PDF work runs in the browser through WebAssembly rather than on a server. Nothing is uploaded, so there is no queue, no storage cost, no size limit worth enforcing and, more to the point, no copy of your document on our infrastructure. That constraint made the build harder and the product better. It is also the reason this exists at all: it is a public, free, permanently available argument for the performance standard we sell, which is more persuasive than a claim on a services page.
Read the case studyA storefront, a customer app, and a driver app built in 12 weeks that took a Delhi NCR kirana from about 30 WhatsApp orders a day to 120 to 180, with route-optimised deliveries.
A single kirana in Delhi NCR taking orders over WhatsApp, where the actual bottleneck was never the ordering. It was one person reading messages, writing addresses onto paper, and sending a rider out in whatever order the notes happened to be stacked. Three apps in twelve weeks: a storefront, a customer app, and a driver app with route optimisation. The lesson worth taking from it is that the software that moved the number was the driver app, which the brief did not originally ask for, because that is where the day was actually being lost.
Read the case studyThese started exactly where you are now
Each of these began with someone describing a problem and asking what it would cost. That is still the whole first step, and it takes about ten minutes.