DEV Community: Divyakush Punjabi

Don't fake the rider on the map

Divyakush Punjabi — Sun, 13 Sep 2026 13:35:40 +0000

Open almost any delivery app and watch the tracking screen. An icon edges along a route, a countdown ticks, the status flips to "on the way." A surprising amount of that can be theatre — progress interpolated from a timer, because a moving icon feels better than a still one. On Saturdays, a food delivery platform, I made the opposite call: the tracking screen shows what the server knows, and nothing it doesn't.

Why fake progress is tempting

The honest state of a food order is lumpy. Nothing visible happens for minutes while a kitchen cooks, then several things happen at once. Product instinct says fill the gaps: animate a progress bar, advance the status on a schedule, drop a rider icon near the restaurant the moment the order is accepted.

It works — until the timer and reality disagree. The screen says a rider is on the way and no rider has been assigned. The icon is moving and the food is still on the pass. Now the customer has been told something false by the one screen they trust to be accurate, which does more damage than a still screen ever could. They contact support, and support is looking at a different truth than the customer is.

The rule: render events, not guesses

Saturdays' tracking follows one principle: every change on the tracking screen corresponds to something that actually happened on the server.

Status comes from the state machine. The order moves placed → confirmed → preparing → ready → picked up → out for delivery → delivered, and the screen shows a step only after that transition has committed. No client-side clock advances it.
The rider appears when a rider exists. The rider icon shows up only when the server reports an assignment. Until then, the screen honestly says the order is being prepared.
An ETA is an estimate. It's worth showing — but it's a number, not permission to animate a rider who isn't there.

Making "honest" also feel live

The objection is that an honest screen feels dead. It doesn't have to. The fix is to make the truth arrive fast, not to invent it.

Tracking runs over WebSockets, with Django Channels and Daphne on a Redis channel layer. When an order transitions on the server — the restaurant marks it ready, a rider is assigned, the rider picks it up — the event is pushed to the customer's open connection straight away:

# after the transition has committed
async_to_sync(channel_layer.group_send)(
    f"order.{order.public_id}",
    {"type": "order.update", "status": order.status},
)

(Simplified.)

The screen updates moments after the real event. There's no polling interval to hide behind and no timer to drift out of sync, because the timer never existed. The gaps where nothing changes are real gaps — and "your food is being prepared" is a perfectly good thing to show during them.

Where optimism does belong

This isn't an argument against optimistic UI. When users act on their own data — adding to a cart, saving a preference — updating instantly and reconciling in the background is exactly right, because the user is the source of truth for their own intent.

The line is ownership. Be optimistic about what the user just did. Be strictly honest about what other people and systems are doing — the kitchen, the rider, the payment gateway. Order tracking is entirely the second kind.

The takeaway

A status screen is a promise. Fill it with events the server has committed, deliver those events in real time so honesty never feels slow, and treat estimates as estimates. The screen will be quieter than a faked one — and it will be right every time someone looks at it.

The full order flow behind that screen — the state machine, the rider layer, the realtime stack — is in the case study.

👉 Read it: www.divyakush.com/projects/saturdays

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The last ten metres: verifying a food delivery at the door

Divyakush Punjabi — Sun, 13 Sep 2026 13:25:38 +0000

A food delivery can be flawless for thirty minutes and fail in the last ten metres. The rider marks it delivered at the wrong door. Someone insists it never arrived. A handover gets recorded that didn't happen. On Saturdays — a food delivery platform where riders carry real, paid orders — the handover is verified with a one-time code, and the interesting engineering is in everything around those six digits.

Why the handover needs proof

Nearly every other step of an order produces a system record: the payment settled, the restaurant accepted, the rider was assigned. The handover is the one moment that depends on two people standing at a door, and "delivered" is just a button on the rider's phone. Without proof, a dispute is one person's word against another's — and the platform, which is holding the money, has nothing to decide with.

A handover OTP makes that moment verifiable. The customer has a code, the rider has to enter it, and "delivered" is only recorded when they match.

Six digits is not the security

The obvious objection: six digits is a million possibilities, and a script can try a million things. That's correct, which is why the code on its own isn't the control. The design around it is.

Store a hash, never the code. The OTP is hashed at rest, the same way you'd treat a password. Anyone who reads the database — a leaked backup, an over-privileged query, an internal tool — sees nothing they could hand to a rider.

Lock out after repeated wrong entries. This is what actually makes six digits sufficient. A million possibilities is trivial with unlimited attempts and hopeless with a handful. After repeated failures the handover locks, and a locked handover is a signal worth surfacing, not just a counter to reset.

Verify on the server. The rider app submits a guess and the server compares it. The code is never sent to the rider's device to be checked locally, because a check that runs on the client is a check the client can skip.

def verify_handover(order, submitted: str) -> bool:
    otp = order.handover_otp          # hash, attempt count, locked flag
    if otp.locked:
        raise HandoverLocked(order.public_id)
    if not check_code(submitted, otp.code_hash):
        otp.register_failure()        # may lock after repeated misses
        return False
    otp.consume()                     # single use
    order.transition_to("delivered")  # still goes through the state machine
    return True

(A simplified sketch of the flow.)

Look at the last line. A correct code doesn't just set a field — it moves the order through the same state machine as every other transition, so "delivered" still has to be a legal next state.

One OTP system, not two

Saturdays isn't the only product in the order flow: restaurants running the DineGuru POS work the same orders. The easy path would have been an OTP implementation in each product. Two implementations means two hashing choices, two lockout policies, two sets of edge cases — and eventually two different answers to "is this handover valid?"

So there's one OTP system, shared across both. Change the attempt limit or how a lock is cleared, and it changes once, everywhere.

The takeaway

When the weakest moment in a workflow is a human interaction, don't try to make it more trusted — make it verifiable. A short code is enough when it's hashed at rest, rate-limited by lockout, checked on the server and tied into your state machine. The strength comes from the system around the secret, not the length of it.

The rest of the delivery flow — live tracking, the order state machine, doorstep payment collection — is in the case study.

👉 Full case study: Saturdays — Food Delivery Platform

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Integrating two of your own products: draw a real boundary

Divyakush Punjabi — Sun, 13 Sep 2026 13:15:38 +0000

I built two products that need to talk to each other constantly: Saturdays, a food delivery platform, and DineGuru, a restaurant POS. A restaurant running DineGuru has to be able to work its Saturdays orders from the POS it already uses. When you own both codebases, the shortcut is right there — point them at the same database and skip the API. I didn't, and the reasons apply to any two systems you happen to control.

Why "they're both mine" is the trap

Owning both sides removes the social pressure to design an interface. It doesn't remove the engineering need for one. A shared database means:

Every schema change is a two-product deploy. Rename a column in one and the other breaks at runtime.
There is no authority. Either product can write anything, so business rules enforced in one are silently bypassed by the other.
You can't reason about blast radius. A bug in the POS can corrupt delivery data, and nothing in the architecture says it shouldn't be able to.

The day the two products have different release cadences, different teams or different customers, all of that becomes a crisis. Designing the boundary up front is far cheaper.

What the boundary looks like

DineGuru drives day-to-day restaurant operation through a separate, versioned API surface on Saturdays, and the design of that surface is where the real decisions are.

Authenticated by an API key, scoped to one restaurant. The key doesn't identify "DineGuru." It identifies one restaurant — and every request made with it can only see and act on that restaurant's data. There is no endpoint where a key reaches across restaurants, because the scoping is applied before any view logic runs.

Identity is read-only across the boundary. The POS can operate a restaurant's day. It cannot rename the restaurant, and it cannot clear a platform suspension. Those are platform decisions, and the integration surface simply doesn't expose them. A key that operates the day is a very different permission from a key that administers the account.

The same domain rules apply. Orders changed through the POS pass through the same state machine and the same payment gate as orders changed anywhere else. The integration is one more caller of the domain layer, not a side door around it.

Where the key lives

One decision ended up simplifying the whole integration. The API key is stored encrypted on DineGuru's server and used server-to-server. It never reaches a browser.

That's the right security posture on its own, but it had a useful side effect: because no browser ever calls Saturdays with that key, no cross-origin surface had to be opened for the integration. No CORS allowlist for a partner domain, no preflight handling, no chance of a misconfigured origin rule exposing the API to arbitrary sites. The server-to-server design removed a category of configuration rather than securing it.

In the other direction, events flow out through an HMAC-signed webhook relay, so the receiving side can verify a message genuinely came from Saturdays.

The takeaway

Integrate your own systems the way you'd integrate a stranger's: a versioned contract, credentials scoped to the smallest unit that makes sense, identity and administration kept off the operational surface, and every request routed through the same rules as everyone else. It's more work on day one, and dramatically less on the day the two products stop moving in lockstep.

How that integration fits into the rest of the platform is covered in the case study.

👉 See it: www.divyakush.com/projects/saturdays

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Your primary key shouldn't be in the URL

Divyakush Punjabi — Sun, 13 Sep 2026 13:05:36 +0000

Open an order confirmation in a lot of apps and the URL ends in something like /orders/48213. That number tells a stranger more than you'd think: roughly how many orders you've taken, how fast you're growing, and — if a single authorization check is ever missing — exactly which URLs to try next. On Saturdays, a food delivery platform, the IDs that leave the server are never the ones the database uses internally.

What an auto-increment ID leaks

A sequential integer primary key is a great internal identifier: compact, fast to index, naturally ordered. It is a poor external one, for three reasons:

It's a business metric. Place one order on Monday and another on Friday, then subtract. You now know the platform's weekly order volume. Competitors do exactly this.
It's a map. If /orders/48213 is yours, /orders/48212 is someone else's. An attacker doesn't have to guess anything.
It turns one bug into a breach. An endpoint that forgets to check ownership — an IDOR, one of the most common web vulnerabilities there is — goes from "exploitable if you happen to find an ID" to "download every order by counting."

Two identifiers, two jobs

The fix is to stop making one column serve two audiences:

class Order(models.Model):
    id = models.BigAutoField(primary_key=True)      # internal: joins, indexes
    public_id = models.UUIDField(
        default=uuid.uuid4, unique=True, editable=False
    )                                               # external: URLs, APIs, events

The integer stays inside the database, doing what it's good at. Every URL, API response, event payload and webhook uses public_id. A random UUID says nothing about volume, has no neighbour, and can't be enumerated.

This is not access control

It's worth being blunt about the limit, because this is exactly where teams talk themselves into a mistake: an unguessable ID is not a permission check. URLs get shared, logged, pasted into support tickets and saved in browser history. If knowing an order's UUID is enough to read it, you haven't fixed the vulnerability — you've hidden it.

Every lookup still has to be scoped to the caller: this order belongs to this customer, this restaurant, this rider's assignment. The public ID is defence in depth. When the ownership check is correct, it changes nothing. When one is ever missing, it turns a catastrophic, enumerable leak into a narrow, hard-to-exploit one.

Doing it without regret

A few details make the pattern cheap to live with:

Add it early. Retrofitting a public ID onto a table that outside systems already reference means migrating every consumer. On day one it's a single field.
Index it. unique=True gives you the index, so lookups by public ID stay fast.
Never expose both. An API that returns id and public_id has undone the whole point. Serializers should simply leave the internal key out.

The takeaway

Separate the identifier your database needs from the identifier the world sees. It costs one column and removes a whole class of information leak — as long as you remember it's the second lock on the door, never the only one.

More of the design decisions behind the platform — the data model, the payment path, the POS integration — are in the case study.

👉 Read the case study: Saturdays — Food Delivery Platform

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The maintenance switch that can't lock you out

Divyakush Punjabi — Sun, 13 Sep 2026 12:55:35 +0000

Every live platform needs a way to stop taking orders — a payment provider incident, a bad deploy, a data migration you don't want customers writing through. On Saturdays, a food delivery platform taking real payments, that's a single flag. Building it took an afternoon. Getting right the one detail most implementations get wrong took longer.

The mechanism is small on purpose

A kill switch should be boring, because the moment you need it is the moment you have the least patience for cleverness. The whole thing is:

One config flag, read at request time, flippable without a deploy.
One middleware, mounted ahead of every view, that checks it.
One response: a structured 503 Service Unavailable with a Retry-After header.

class MaintenanceMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        if platform_paused() and not is_exempt(request.path):
            return JsonResponse(
                {"code": "maintenance", "detail": "Temporarily unavailable"},
                status=503,
                headers={"Retry-After": "120"},
            )
        return self.get_response(request)

(A simplified sketch of the shape, not the production file.)

Each choice there is deliberate. Middleware, not a decorator, because a decorator is opt-in per view, and the one view someone forgets is the one that keeps taking orders. 503, not 500 or 200, because clients, load balancers and crawlers all read 503 as "temporary, come back later" — and Retry-After tells them when. Structured JSON, because the frontend needs to render a maintenance screen, not a generic error toast.

The part that actually matters: what's exempt

A middleware that blocks everything has an obvious flaw. If the admin API that flips the flag sits behind it, turning maintenance on removes your ability to turn it off. You've built a door that locks from the outside with the key still inside.

So the switch needs an exemption list — and the discipline is keeping it narrow:

The admin control API, so the switch that turned maintenance on can turn it off.
Health checks, so your infrastructure doesn't conclude the service is dead and start restarting it mid-incident.
Schema docs — read-only, harmless, and useful while you're debugging.

That's it. Every extra path on that list is a hole in the switch. "Just exempt the partner API too" sounds reasonable right up until the incident is in the partner integration.

Why narrow beats clever

The temptation is to make the switch granular: pause checkout but not browsing, pause one city, pause one restaurant. Some of that is genuinely useful — Saturdays' operator console has separate restaurant holds with different blast radius. But those are operational tools. The platform switch is an emergency brake, and an emergency brake with ten settings is one you'll misconfigure under pressure.

Keep the brake binary and the exemptions minimal. Put the nuance in separate, clearly named controls.

The takeaway

When you build any control that can take a system offline, design the "how do I undo this" path first, and make sure the thing it controls can't affect it. Then keep the list of things that bypass the control as short as you can defend.

The operator console, the restaurant holds, and the rest of how the platform is run day to day are covered in the case study.

👉 Full write-up: www.divyakush.com/projects/saturdays

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The interface can hide a button. It can't stop a request.

Divyakush Punjabi — Sun, 13 Sep 2026 12:45:33 +0000

Every web app eventually ships the same bug: the frontend correctly greys out an option, and someone sends the request anyway. A discount that shouldn't apply, a delivery window that's closed, a price from a stale cached menu. The UI did its job. The system didn't. On Saturdays — a food delivery platform with a customer app, a restaurant surface, a rider layer and an operator console all hitting one backend — I settled this with one rule, applied everywhere.

A disabled button is a suggestion

It's worth being precise about what the client is. Your React app is one of many things that can call your API. So is curl. So are the browser's dev tools, an old cached build, a request retried by a flaky network — and, in Saturdays' case, an entirely separate product: the DineGuru restaurant POS, which talks to the same backend over its own integration.

Anything the frontend enforces, every one of those other callers skips. Client-side validation is for the person using the screen: fast feedback, fewer wasted round trips. It is not a control. An interface can only ever hide an option; it cannot stop a request.

The rule

The line I drew is simple enough to apply without a meeting:

If getting it wrong costs money or misleads a customer, the server decides and the client is told.

In practice that put a specific list of decisions in the domain layer rather than the interface:

Prices and taxes — computed from the order, never read from the request.
Payment amounts — the endpoint takes an order id, not a number.
Charge waivers — such as the dine-in charge waiver — decided by server rules, not a checkbox.
Rider-assignment signals — the customer sees a rider when the server has one, not when a timer guesses.
Delivery-time limits — enforced where the order is created, not merely where it's displayed.

One implementation per decision

The rule only holds if each decision is made in exactly one place. Saturdays is sixteen Django domain apps, and the failure mode in a codebase that size isn't "nobody validates." It's three slightly different validations in three views, drifting apart one bug fix at a time.

So each decision lives in a service module that every caller goes through — the customer checkout, the partner portal, the POS integration, the payment webhook. When a tax rule changes, it changes once, and every path that reaches it gets the new behaviour on the same deploy.

The frontend doesn't become dumb in this model. It still validates with typed schemas at the boundary, still renders sensible defaults, still hides what doesn't apply. It just stops being the thing anyone relies on for correctness.

The takeaway

Sort your rules into two piles. UX rules — formatting, hints, what's shown — belong in the client, where they make the product feel fast. Business rules — anything a malicious, stale or automated caller could exploit — belong on the server, in one place, called by everyone. The test isn't "does my app ever send a bad request?" It's "what happens when something that isn't my app does?"

How that plays out across the whole platform — the order state machine, the payment gate, the POS boundary — is in the case study.

👉 Case study: Saturdays, a food delivery platform

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Never trust a payment webhook on its first word

Divyakush Punjabi — Sun, 13 Sep 2026 12:35:32 +0000

A payment webhook is, structurally, a stranger sending your server a POST that says "this person paid." If your handler believes it, anyone who can reach that URL can mark orders as paid. In Saturdays, where PhonePe settles real money for food orders, the webhook handler is the most defensive code in the system — and every step in it exists because the step before it isn't enough.

The handler most tutorials give you

def payment_webhook(request):
    data = json.loads(request.body)
    order = Order.objects.get(id=data["order_id"])
    if data["status"] == "SUCCESS":
        order.mark_paid()

Count the assumptions: that the request came from the gateway, that the body wasn't altered, that SUCCESS means the money actually arrived, that the amount matches the order, that this event hasn't already been processed, and that nothing else is changing this order at the same moment. Every one of those is a separate way to lose money.

Five steps, in this order

1. Log the raw body before you parse it. Not the parsed dict — the bytes. When a gateway disputes what it sent, or a parser throws on a malformed payload, the raw body is the only evidence you'll have. It costs one write and saves every investigation.

2. Verify authentication. Confirm the request really came from the gateway, using whatever the provider signs or authenticates with. A request that fails this isn't "a failed payment." It isn't a payment event at all.

3. Ask the gateway yourself. Even an authentic webhook is a notification, not a ledger. Saturdays independently re-reads the payment status from the gateway's status API — and does it outside any database transaction, because a network call can take seconds, and holding a row lock across it turns one slow response into a queue of blocked requests.

4. Lock, then re-check. Only after that independent confirmation does the handler lock the order row and look again under the lock. Webhooks retry and can arrive concurrently, so the state you read before locking may already be stale. The re-check is what turns a duplicate delivery into a harmless no-op instead of a second fulfilment.

5. Compare the amount — and fail loudly. The confirmed amount is checked against the order's own stored total. A mismatch doesn't quietly succeed, and it doesn't silently fail either: it's flagged for manual review, because a payment that doesn't match its order is exactly the case a human needs to see.

The rules underneath the sequence

Two principles hold those steps together:

The client never supplies the amount. The endpoint that starts a payment takes an order id and computes the figure from the order's immutable total. The webhook then verifies against that same number. Nowhere in the flow is a price accepted from outside.
No lock is ever held across a network call. Confirm first, lock second. The same discipline covers refunds, which commit their pending state before the gateway call goes out — so a crash mid-refund leaves a record that something was attempted, not a mystery.

The takeaway

Treat every inbound payment event as a claim to verify, not a fact to record. Keep the evidence, authenticate the sender, confirm with the source of truth, serialize the write, and make the mismatch case visible. None of it is clever. All of it is the difference between a checkout that works in a demo and one you can leave running with real money in it.

The full payment path, and the order state machine it gates, are in the case study.

👉 See the build: www.divyakush.com/projects/saturdays

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The notification that fired before the rollback

Divyakush Punjabi — Sun, 13 Sep 2026 12:25:31 +0000

Here is a bug that passes every test you'll write for it. A customer's order is confirmed, the restaurant gets a "new order" ping, and a moment later the transaction that confirmed it rolls back. The restaurant is now cooking food for an order that doesn't exist. Nothing crashed. Two things that were supposed to happen together simply didn't. Building Saturdays, a food delivery platform where one order is shared by a customer, a restaurant, a rider and the platform itself, this was the class of bug I most wanted to make impossible.

Two writes pretending to be one

The naive version looks correct:

with transaction.atomic():
    order.confirm()
    order.save()
    notify_restaurant(order)   # HTTP call, queue publish, websocket push...

It reads like one unit of work. It isn't. The database write is transactional; the notification is not. They fail independently, and every combination is a production incident:

Notify succeeds, commit fails. The restaurant hears about an order the database never kept.
Commit succeeds, notify fails. The order is confirmed and nobody who has to act on it knows.
Notify fires while the transaction is still open. A consumer reacting to the event reads the row and sees the old state.

Moving the call after the atomic() block fixes the first case and leaves the second fully in place. There is no ordering of two independent operations that makes them atomic. You have to turn them into one.

Write the intent, not the effect

The transactional outbox does exactly that. Instead of sending the event, you record it — in a table, in the same transaction as the state change that caused it:

with transaction.atomic():
    order.confirm()
    order.save()
    OutboxEvent.objects.create(
        kind="order.confirmed",
        payload={"order": str(order.public_id)},
    )

Now the question "did we tell the restaurant?" has the same answer as "did the order get confirmed?" — because both are rows in one commit. Either both exist or neither does.

A separate worker drains the table and does the actual delivery. In Saturdays that's a scheduled Celery task, and it's where all the unglamorous reliability lives:

Attempt counts. Every delivery try is recorded, so a flaky receiver is visible instead of silent.
Backoff. A failing destination is retried on a widening interval, not hammered in a loop.
Dead-lettering. After enough failures the event is parked for a human — not dropped, and not retried forever.

What you're really buying

The outbox doesn't make delivery instant, and it doesn't make it exactly-once. What it gives you is a guarantee that matters more: no event is ever sent for a state that didn't commit, and no committed state change is ever silently left unannounced. The cost is a few seconds of delay. The alternative is a class of inconsistency you can't reproduce on your laptop and can't explain to a restaurant owner.

It does push one responsibility onto the receiving side. Because a retry can deliver an event twice, consumers should be idempotent — handling the same order.confirmed a second time must be a no-op. That's a far easier property to build than distributed atomicity, and it's the right trade.

The takeaway

Any time you see a database write and a network call in the same function, ask what happens if exactly one of them succeeds. If the answer is "someone acts on something that isn't true," the call doesn't belong there. Record the intent inside the transaction; deliver it afterwards.

The rest of how Saturdays keeps four kinds of user in agreement about one order — the state machine, the payment path, the POS integration — is written up in the case study.

👉 Read it: Saturdays — Food Delivery Platform

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

A completed foundation is a starting point, not a finish line

Divyakush Punjabi — Sun, 23 Aug 2026 18:59:10 +0000

Completing a formal education in a field isn't the end of learning it — in something moving as fast as AI, it's barely the start. Having my Major in Artificial Intelligence conferred at IIT Ropar by Prof. Sudarshan Iyengar, and then spending a long conversation afterwards about what the field leaves open for the future, crystallized that for me. I wrote about it in this reflection.

A completed foundation is a starting point, not a finish line

There's a temptation to treat a credential as an arrival — the learning is done, the box is checked. In a field like AI, that mindset ages badly within months. The real value of a rigorous foundation isn't that it's complete; it's that it gives you the depth to keep learning the field intelligently as it changes.

The conversation after the ceremony was, fittingly, not about what had been settled but about what the field leaves open — the unanswered parts, the direction of travel. That's the right frame for finishing any serious education: less "I now know this" and more "I'm now equipped to keep understanding this as it evolves."

What completion actually signals

Depth enables adaptation. A formal grounding is what lets you absorb the next development in a field with judgment instead of hype — you can tell what's genuinely new from what's repackaged.
The best practitioners stay curious. A conversation about open problems, at the moment of completion, is the healthy posture — the field's frontier matters more than its settled core.
Learning is a permanent posture. Finishing a demanding program is best understood as building the capacity to keep going, not permission to stop.

The takeaway

Having the AI major conferred was a real milestone — but the most valuable thing I carried out of it was the orientation toward what comes next: treating a completed foundation as the platform for continuous learning in a field that will keep changing. The credential is the floor, not the ceiling.

The full account, including that conversation, is on the page below.

👉 Read it: www.divyakush.com/insights/iit-ropar-complete

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The underrated professional trait: seeing a long thing through

Divyakush Punjabi — Sun, 23 Aug 2026 18:53:39 +0000

Eighteen months is a long time to hold a commitment when the finish line is that far out and nothing forces you to keep going. Standing outside the hall in Rupnagar before the ceremony — in front of the banner for the Major in Artificial Intelligence, eighteen months after the first module opened — was a moment about one deeply underrated professional trait: the ability to see a long thing through. I set it down in this note.

Long commitments are where most people fall off

Short bursts of intensity are common. Sustained commitment across many months, especially alongside everything else demanding your attention, is rare — and it's exactly what meaningful work requires. The interesting parts of a long program are the start and the end; the middle is just showing up, repeatedly, when novelty has worn off and no one is watching.

Reaching the convocation for an eighteen-month AI major wasn't a single achievement so much as the sum of a hundred unremarkable days of continuing. That's the part worth respecting: not the ceremony, but the consistency that earned it.

What seeing a long thing through teaches

Consistency outperforms intensity. A steady standard held over eighteen months beats bursts of effort that don't last. Careers are built on the former.
The middle is the real test. Anyone can be motivated at the beginning and the end. The professional trait that matters is continuing through the unglamorous middle.
Completion compounds credibility. Finishing a long, demanding commitment is evidence — to yourself and others — that you can be trusted with the next one.

The takeaway

The convocation marked eighteen months of not stopping. I've come to believe that the capacity to sustain a commitment over a long horizon — to keep a standard through the quiet middle stretch — is one of the most valuable and least visible professional traits there is. It's what turns intention into a track record.

The full note, taken outside the hall that day, is on the page below.

👉 Read it: www.divyakush.com/insights/iit-ropar-convocation

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

End-to-end ownership is a different discipline from building a part

Divyakush Punjabi — Sun, 23 Aug 2026 18:48:08 +0000

Being shortlisted out of more than 400 teams at Smart India Hackathon 2025 came down to one thing more than any other: owning a system end to end. Not a component, not a slice — the whole architecture of an AI and IoT rockfall early-warning system, from the sensors in the field to the model to the alert. I wrote about what that scale of ownership taught me in this reflection.

End-to-end ownership is a different discipline

There's a large gap between building a part well and being responsible for a whole system working. When you own the architecture end to end, no interface is someone else's problem — the sensors, the data pipeline, the model, and the way a warning finally reaches a human all have to fit together, and every seam between them is yours.

Architecting the rockfall system across AI and IoT meant thinking about the entire chain: how noisy field data becomes a trustworthy signal, how the model's output becomes an actionable alert, how the pieces hold together under real conditions. Standing out among 400+ teams wasn't about one clever part — it was about the whole thing cohering.

What owning a full system teaches

The seams are the system. Individual components are the easy part; making them integrate reliably across two very different domains — machine learning and physical hardware — is where the real engineering lives.
You design for the whole outcome. End-to-end ownership forces you to keep the actual goal in view — an early warning someone can act on — rather than optimizing a piece in isolation.
National selection rewards coherence. Being shortlisted at that scale reflects a system that works as a whole, which is a higher bar than any single impressive module.

The takeaway

Architecting a system end to end, across AI and IoT, taught me to think in whole outcomes and to treat the integration between parts as the core of the work rather than an afterthought. That systems-level ownership — being accountable for the entire chain, not a link in it — is exactly the capability serious engineering organizations are built around.

The full account of the system and the selection is on the page below.

👉 Read it: www.divyakush.com/insights/smart-india-hack

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Finishing is a skill, and it is rarer than starting

Divyakush Punjabi — Sun, 23 Aug 2026 18:42:36 +0000

There's a half of engineering nobody photographs: the hour every deliverable is finally filed, every document is complete, and the unglamorous work of finishing is actually done. It's not the demo or the award — it's the closeout. I marked that exact hour for my FPGA hardware project in this note, because that quiet moment is where a lot of real professional value lives.

Finishing is a skill, and it's rarer than starting

Starting is easy and exciting. Finishing — filing every deliverable, closing every loose end, meeting every requirement of a submission down to the last item — is neither, which is exactly why it separates people. Plenty of promising work never gets fully delivered because the last, tedious ten percent is where energy runs out.

The hour the submissions went in wasn't glamorous, but it represented something professional work runs on: follow-through. The discipline to take a project all the way to genuinely complete, not just "basically working," is one of the most reliable markers of someone you can trust with real responsibility.

What the closeout teaches

Done means done, including the paperwork. In any serious setting, a deliverable isn't complete until every requirement around it is met — documentation, formatting, the lot. Treating that as part of the work, not an afterthought, is professionalism.
The last ten percent is the test. Anyone can carry a project through the interesting middle. Carrying it through the boring, exacting end is where reliability is proven.
Quiet consistency compounds. The moments nobody photographs — the diligent closeouts — are what build a reputation over time, far more than the visible highlights.

The takeaway

I've learned to respect the unglamorous half of engineering as much as the visible half. Shipping isn't the moment of the demo; it's the moment every last deliverable is genuinely filed and the thing is complete. Being the person who reliably reaches that moment is worth more, professionally, than being the person with the flashiest start.

The full note, taken outside the lab that hour, is on the page below.

👉 Read it: www.divyakush.com/insights/submissions-closed

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub