DEV Community: Divyakush Punjabi

A warning one minute early beats a perfect post-mortem

Divyakush Punjabi — Thu, 13 Aug 2026 15:27:55 +0000

After a rockfall, you can reconstruct exactly what happened. That analysis is worth almost nothing to the people who were standing there.

The entire value in hazard detection is on the front of the event, not the back. A crude warning a minute early can clear a slope; a flawless explanation an hour late is a report. So the problem isn't understanding a rockfall — it's seeing it coming.

The trouble is that no single sensor is trustworthy on its own. Displacement, vibration, moisture — each is noisy, each throws false alarms. But if you fused those streams into one model that weighs them together, the noise starts to cancel and a real pattern rises out of it: this combination, trending this way, means move.

That's what I engineered into an AI and IoT rockfall prediction system — a multi-sensor fusion pipeline feeding a real-time hazard model, built to raise the alarm before the slope moves rather than to explain it afterward. It was shortlisted at Smart India Hackathon 2025.

Prevention systems are judged by their lead time, not their hindsight. Design for the warning, not the write-up.

More ML and IoT projects → www.divyakush.com

Multi-tenancy is a promise you keep in the database

Divyakush Punjabi — Thu, 13 Aug 2026 15:22:24 +0000

In a multi-tenant app, "don't show tenant A's data to tenant B" isn't a feature you build. It's a promise you can never break, even once.

The danger is that tenancy usually lives as a filter you remember to add — a WHERE clause on every query. Which means it also lives as the one query where a tired engineer forgets it, and that single omission is a data breach, not a bug ticket.

If tenant scoping were enforced server-side by default — part of how data access works, not something each endpoint opts into — then forgetting wouldn't be catastrophic, because there'd be nothing to forget. Isolation becomes a property of the system instead of a discipline you hope everyone maintains.

That's the spine of DineGuru, a multi-tenant restaurant operations platform — a FastAPI modular monolith over PostgreSQL with nine domain modules, where tenancy is scoped on the server rather than trusted to each query. The boring, centralized version is the safe version.

Any guarantee you enforce by convention will eventually be violated by convention. Push it down into the layer where it can't be skipped.

More backend and SaaS work → www.divyakush.com

A dumb protocol is a feature, not a compromise

Divyakush Punjabi — Thu, 13 Aug 2026 15:16:52 +0000

When your software has to talk to hardware, the clever protocol is the one you'll regret at 2am.

It's tempting to design a rich, structured message format between your host and your device — length headers, framing, the works. Then something misbehaves on the wire, and now you're decoding your own cleverness with an oscilloscope instead of fixing the actual bug.

If the two sides spoke in something almost insultingly simple — a flat map where one byte means one action — you could watch the entire conversation in a serial monitor and understand it at a glance. Adding a new device becomes: pick the next number. Debugging becomes: read the byte.

That's the choice I made in HomeSense, where the host classifies a spoken command and sends a single-byte opcode down the serial line to an Arduino, which reads it and flips the right pin. Trivial to trace, trivial to extend, and boring in the best possible way.

"Boring and debuggable" beats "elegant and opaque" almost every time a wire is involved. Save your cleverness for the problem that actually needs it.

More embedded and IoT builds → www.divyakush.com

Your ML accuracy might be quietly cheating

Divyakush Punjabi — Thu, 13 Aug 2026 15:11:21 +0000

If your model predicts sequences and you evaluated it on a random split, your accuracy number is probably lying to you.

Here's the leak. You shuffle your data and carve out a random test set. But if behavior unfolds over time, a random split drops future events into the training set and past events into the test set. Your model gets to peek at what comes later, then gets graded on what came before. The score looks fantastic and means very little.

If instead you split on time — train on the past, test strictly on the future, the way the model will actually be used — the number drops. And that lower number is the honest one. It's the only one that tells you whether the thing will work in production.

I held that line building a sequential recommender: evaluated on a temporal, leave-last-out split so nothing from the future ever leaked backward, with a simpler baseline kept alongside so every claim was measured against something real.

An unflattering metric you trust beats a beautiful one you can't. When a result looks too good, suspect your split before you celebrate.

More ML notes and projects → www.divyakush.com

Hardware doesn't get a second frame

Divyakush Punjabi — Thu, 13 Aug 2026 15:10:22 +0000

Software gets to retry. A traffic signal at rush hour does not.

Most of us build in a world with a safety net — a request fails, you try again, nobody notices. Move down to hardware controlling something physical and that net disappears. The signal has to make the right decision this cycle, in real time, every time, because there is no "please refresh."

So imagine signal timing that adapts to actual traffic on the silicon itself — reading demand and adjusting green time cycle by cycle, with no processor, no operating system, and no network call in the loop. Determinism stops being a nice-to-have and becomes the whole point: the logic does exactly one thing, exactly on time.

That's what I implemented as an FPGA-based adaptive traffic controller in Verilog — real-time signal timing that adjusts to demand to improve throughput, running entirely in hardware. Writing for an FPGA rewires how you think: you're not writing instructions that execute in sequence, you're describing circuits that all exist at once.

It's a useful discipline to borrow even in software. When you can't retry, you're forced to actually get it right — and that constraint makes better engineers.

More hardware and systems work → www.divyakush.com

The commerce bug that charges you twice — and how to kill it

Divyakush Punjabi — Thu, 13 Aug 2026 14:42:50 +0000

The most frightening bug in commerce isn't a payment that fails. It's a payment that succeeds twice.

Networks are unreliable, so clients retry. A customer taps "Pay," the response gets lost on the way back, the app tries again — and now you've charged them twice for one order. The naive fix is to hope it doesn't happen. It happens.

Imagine instead that every payment attempt carried a unique idempotency key, and the server promised: the first time I see this key I do the work; every time after, I return the same result without doing it again. Suddenly a retry is safe. The client can fire the same request ten times over a flaky connection and the customer is charged exactly once.

That guarantee sat at the center of the checkout I built for Saturdays, a marketplace taking real orders through two payment gateways. The same idempotency key rides along the whole path, so a retried tap can never become a double charge — the reliability of the ordering-to-payment flow was the entire engineering priority.

Idempotency isn't a payments trick; it's how you make any operation safe to repeat. The moment retries exist in your system — and they always do — it stops being optional.

More backend and systems write-ups → www.divyakush.com

Two payment gateways, one button the customer never questions

Divyakush Punjabi — Thu, 13 Aug 2026 14:37:19 +0000

A customer should never be able to tell how many payment providers sit behind your checkout button.

Cards and India-native UPI are completely different animals — different flows, different states, different ways to fail. The lazy version exposes that mess to the user: pick your provider, learn our plumbing, good luck. The result is hesitation, and hesitation at the payment step is a lost order.

If both rails felt like one button — same interface, same confidence, the differences handled quietly underneath — you'd lose nobody to confusion. The complexity doesn't disappear; it just moves to where it belongs, out of the customer's way.

That's what I did shipping Saturdays, a food-ordering marketplace running live payments through both Stripe and PhonePe. They're integrated behind a single, unified checkout, with each provider's states handled deliberately rather than optimistically — because the payment step is the one part of the product a customer cannot forgive getting wrong.

The principle is older than payments: absorb complexity on behalf of your user. Every messy branch you handle internally is a decision they don't have to make.

More of what I ship → www.divyakush.com

For a servo, a cloud round-trip is a lifetime

Divyakush Punjabi — Thu, 13 Aug 2026 14:31:48 +0000

Send a camera frame to the cloud, run detection, send a command back — and by the time your servo moves, the person has already walked out of frame.

We treat latency like a number to optimize later. For anything that touches the physical world, it's a design constraint you decide up front. A few hundred milliseconds is invisible in a web request and an eternity for a motor trying to track a moving target.

If the intelligence lived next to the sensor instead of in a datacenter, the loop would close in real time. Detect, decide, actuate — all local, no network in the critical path. The cloud is still useful, just not for the part that has to happen now.

That's the architecture behind Netra: an ESP32-CAM streams frames into a local YOLOv8 pipeline that drives pan-tilt servos over MQTT, so tracking reacts immediately instead of waiting on a round-trip. The dashboard and heavier analytics can live elsewhere — the reflex can't.

Draw the boundary first: what has a physical consequence stays at the edge; what's inherently remote can be remote. Get that line right and everything downstream gets simpler.

More edge and systems work → www.divyakush.com

You can't build intuition for something you can't see

Divyakush Punjabi — Thu, 13 Aug 2026 14:26:16 +0000

You can memorize that quicksort is O(n log n) and still have no feel for why it falls apart on an already-sorted array.

A textbook flattens an algorithm into pseudocode and a Big-O label. But an algorithm is a sequence of decisions unfolding over time, and that's precisely the dimension the page throws away. The label tells you the cost; it doesn't let you feel it.

Now imagine you could watch it. Two sorts racing on the same data, comparison and swap counters ticking live. An AVL tree rebalancing itself mid-insertion. A complexity curve bending upward as you drag the input size higher. The moment a concept clicks is almost always the moment you see it move.

That's why I built AlgoVerse, a browser-based platform that renders data structures and algorithms as animated, step-through scenes at 60fps. The hard part wasn't the algorithms — those are well understood. It was decoupling the computation from the rendering so big inputs never freeze the UI and you can scrub the speed from a crawl to a blur.

Good learning tools don't dumb the idea down. They remove the friction between you and the moment it becomes obvious.

See what else I've built → www.divyakush.com

The stop-word that quietly breaks every voice smart-home

Divyakush Punjabi — Thu, 13 Aug 2026 14:20:45 +0000

Every NLP tutorial tells you to strip stop-words. Do that in a voice-controlled home and you just deleted the command.

Standard English stop-word lists throw away tiny, "meaningless" words — including on, off, and all. In ordinary text they're noise. In "turn on light two" they are the entire instruction. Filter them out and "turn on" and "turn off" collapse to the same tokens, so every light command becomes a coin flip.

Picture the fix from the outside: nobody would ever guess it. You'd stare at a system that transcribes speech perfectly and still toggles the wrong switch, because the bug isn't in the microphone or the model — it's in a default someone imported without reading.

The whole repair is one line: remove on, off, and all from the stop-word set before you filter. That's it. I leaned on this in HomeSense, a voice assistant that turns speech into physical actions — NLTK classifies the intent locally, then sends a single byte down a serial line to an Arduino.

The broader point: your libraries encode someone else's assumptions. When you know your domain better than the default does, override it — and the smallest override can be the thing the whole system depends on.

More of my projects and write-ups → www.divyakush.com

Recommenders throw away your single most useful signal: order

Divyakush Punjabi — Thu, 13 Aug 2026 14:15:14 +0000

Most recommendation engines look at everything you've ever liked and quietly ignore the one thing that matters most: the order you liked it in.

Think about what your last action says versus a random one from a year ago. If you just finished part two of a trilogy, the next thing you want is obvious to a human and invisible to a system that treats your history as an unordered bag of items.

So imagine a model that reads your history as a sequence — that learns which past actions predict the next one, the way a language model learns which words predict the next word. Cold-start gets easier. "You watched these in this order, last night" becomes a real signal instead of noise.

That's what I built with a self-attention sequential recommender — a SASRec transformer in PyTorch, trained across movies and music. It attends over your interaction history and predicts what comes next, and on a proper held-out split it lands well above the matrix-factorization baseline I kept next to it for honesty.

If your domain has any time structure at all — and almost all of them do — switching from a set-based model to a sequence-based one is the biggest single lever you're probably not pulling.

I write up the things I build → www.divyakush.com

The 'do nothing' zone that made my camera track smoothly

Divyakush Punjabi — Thu, 13 Aug 2026 14:09:43 +0000

The first version of my auto-tracking camera shook like it was nervous.

Here's the trap. You tell a camera to keep a person centered, so the obvious rule is: if they're not dead-center, move toward them. But "dead-center" is never exactly true — there's always a pixel or two of error — so the servos chase noise forever and the whole rig vibrates.

If you could teach the camera the difference between off and close enough, it would stop fighting itself. And if the correction scaled with how far off the target actually was — a gentle nudge when they're nearly centered, a fast sweep when they're at the edge — motion would look smooth instead of snapping and overshooting.

That's the whole fix, and it's exactly how I built Netra, an edge-AI camera that follows a person on its own: proportional control for the speed, and a 12% dead zone in the middle where the servos simply do nothing. Two rules from control theory did more for tracking quality than any amount of model tuning.

The lesson generalizes past cameras: a system that reacts to every tiny error is a system that never settles. Sometimes the smartest thing your code can do is ignore small differences on purpose.

More things I've built and written about → www.divyakush.com