DEV Community: siyadhkc

I built a multi-tenant food delivery platform alone. Here's what nobody tells you about that.

siyadhkc — Sun, 17 May 2026 16:40:10 +0000

Four user roles. One payment gateway that lied to me. Three rewrites of the same feature. And a GPS bug that nearly flooded my database. This is the real story behind Savor.

I was tired of building things that felt fake

At some point every developer hits a wall with tutorial projects. You've built the weather app. You've done the blog CRUD. You've cloned Twitter in a weekend. And none of it actually teaches you what it feels like when four different types of users are all touching the same data at the same time, and you have to keep their worlds completely separate.

I wanted something that would break me a little. Something with real business logic, real money, real state synchronization problems. Food delivery checked every single box.

Customers order food. Restaurants fulfill it. Delivery agents pick it up. Admins oversee everything. Four completely different actors, all interacting with overlapping data, all in real time. That's not a tutorial problem — that's a systems problem. I called it Savor.

"Building this was the first time I genuinely didn't know if something would work until I ran it. That was terrifying and that was the point."

These aren't exciting choices. They're correct ones.

Django REST Framework on the backend. React 19 + Vite on the frontend. PostgreSQL. I didn't pick these to be cool. I picked them because the problem needed a mature ORM, ACID-compliant transactions, and a frontend that wouldn't fight me on state management.

Layer	Tech	Why it mattered
Backend	Django 5.1 + DRF	Atomic transactions, battle-tested ORM, signals for cross-model side effects
Frontend	React 19 + Vite	Fast HMR, modern concurrent features
Auth	SimpleJWT + rotation	Silent 60-min access token rotation, 7-day refresh — no mid-session logouts
Database	PostgreSQL	ACID compliance. Nested financial data cannot partially save.
Payments	Razorpay	Localized processing, webhook verification
Media	Cloudinary CDN	Edge delivery. Serving images from Django would be career-ending performance-wise.
Styling	Tailwind CSS 4.0	Zero runtime. Design tokens kept four portals visually coherent.
Animations	Framer Motion	Micro-interactions. A premium feel isn't just design — it's movement.
Mapping	Leaflet.js	Live GPS plotting on the customer tracking view

The one decision I'd revisit: React Context API over Zustand. Context was fine for the scope but I started feeling prop drilling pain by week four. If you're building something this complex, just start with Zustand.

Each portal was its own distinct problem

The customer app was where I started because it's the most tangible — you can see it, click it, feel it. The discovery architecture has two layers: global cuisines (Arabian, South Indian, Desserts) and restaurant-internal categories (Must Try, Specials). Getting that hierarchy right in the serializers took four iterations. The cart was where I first hit real business logic — you can't add items from two different restaurants to the same cart. I built persistent local state that checks restaurant ID on every cart mutation. Sounds simple. It wasn't.

The restaurant partner portal was the one I underestimated the most. I assumed it'd be a dashboard with some CRUD. What I got was the most complex portal in the system. Restaurant owners are power users. The order lifecycle — Pending → Accept → Preparing → Ready for Delivery — cascades into downstream state changes across three other portals simultaneously. I used Django signals for this. Required very careful thinking about idempotency.

The delivery agent interface is the one I'm most proud of technically. Geo-fencing logic is implemented at the queryset manager level, not the view level. A Kochi agent cannot see a Mumbai dispatch — and this isn't a frontend filter someone can bypass with a crafted request. The data simply doesn't exist in the response. Getting the earnings calculation to be atomic and accurate on the Delivered status transition took three rewrites.

The admin console could have been an afterthought. I didn't let it be. With 3,000+ menu items seeded from the Kerala restaurant dataset, server-side pagination was non-negotiable. I implemented cursor-based pagination — offset pagination on PostgreSQL becomes unusably slow past 1,000 rows.

Live demo: food-delivery-seven-bice.vercel.app

The struggles nobody writes about in project writeups

01 — Multi-tenancy took three complete rewrites

The first version filtered at the serializer level. That works until a restaurant owner in tenant A briefly sees an order from tenant B during a race condition. The second version moved filters to the view layer — better, still bypassable. The third version put tenant scoping into the queryset manager. That's where it needed to be from the start. Two full days of debugging a bug that shouldn't have existed if I'd thought it through properly the first time.

02 — Razorpay webhook verification in development is a trap

Webhooks need a publicly accessible endpoint. In development, you don't have one. I spent a full day debugging a signature verification failure that turned out to be a timezone mismatch in how I was constructing the HMAC payload. I ended up building a local webhook simulator specifically for dev testing, stripped out before production. This is not in any Razorpay tutorial I found.

03 — GPS telemetry nearly destroyed my database

Early testing: delivery agents broadcast coordinates on every geolocation API event. The browser's watchPosition fires multiple times per second. At 10 concurrent test agents, that was hundreds of database writes per minute for a field that only needs to update every few seconds. I added a frontend debounce and a backend timestamp guard that rejects updates more frequent than 3 seconds. The database survived. My nerves less so.

04 — CSS across four portals with four different visual languages

The customer app is warm and premium. The delivery interface is utilitarian and fast. The admin console is dense and data-heavy. The partner portal is somewhere between all three. Tailwind's design token system helped, but by week three the tokens were drifting in ways that required a full audit to fix. CSS architecture is genuinely hard at scale and nobody talks about the multi-portal version of this problem.

05 — The cart constraint bug that appeared in production and nowhere else

Cart state was using localStorage with a restaurant ID key. In production, the Vercel edge occasionally delivered a cached app version mid-session with a stale cart key. The constraint check passed because the key comparison was against an old restaurant ID. Never reproduced locally. Fixed by adding a session-scoped cart version hash alongside the restaurant ID. The worst kind of bug: requires production traffic to surface.

The one decision that saved the whole system

Early on I had a choice: enforce multi-tenancy at the UI layer or the data layer. The UI layer is easier — you just filter what you show. The data layer is harder — you modify how querysets are constructed at the model level so filtered-out data is never even fetched.

I chose the data layer. Every restaurant-scoped query goes through a custom queryset manager that injects the tenant ID before the SQL hits PostgreSQL. Bypassing tenant isolation requires compromising the Django application layer itself — not just crafting a request with different parameters.

For financial data, I used @transaction.atomic everywhere that touched nested profile updates. A restaurant's payout configuration and platform commission rate update in a single atomic operation. Either both succeed or neither does. This is not optional when you're dealing with money.

"The architecture that survives isn't the one that looks cleanest in a diagram. It's the one that fails gracefully when things go wrong — and they will go wrong."

You only understand failure modes by creating them

You can read about multi-tenancy. You can read about JWT rotation. You can understand atomic transactions in the abstract. But there's a kind of understanding you only get from tracing a data leakage bug through four layers of abstraction at 11pm, finding the one queryset that forgot to filter by restaurant_id, and sitting with the fact that your first two architectural decisions were wrong.

Building Savor taught me that system design isn't about choosing the right technologies. It's about understanding the failure modes of every interface between them. The Razorpay integration fails if my webhook handler is slow. GPS tracking floods my database if the frontend isn't debounced. Multi-tenant isolation breaks if I filter at the wrong layer. None of these are things you learn by reading. You learn them by breaking them, badly, and having to fix it.

If you're in the middle of a solo project right now and it feels like the complexity is winning — it probably is, temporarily. That's what week three feels like. The tangle is the work. Push through it.

Live demo: food-delivery-seven-bice.vercel.app

Backend API: food-delivery-backend-c4pe.onrender.com/api

Github: food-delivery-github

Postman collection at backend/postman.json — all auth rotation, order status, and multi-tenant profile endpoints pre-configured.

I built a JSON CLI tool with Bun and TypeScript — here's what actually happened

siyadhkc — Mon, 11 May 2026 01:31:57 +0000

I wanted a tool that could flatten JSON, filter it, colorize output, and fetch from a URL — all from
the terminal. Something between jq and gron but with a cleaner, more intuitive API. So I built
jray. This is the honest post-mortem of how it went.

GitHub: github.com/siyadhkc/jray
Website:siyadhkc.github.io/Jray

Why I built it

Every time I'm debugging an API response or poking around some nested config file, I reach for jq.
And every time, I spend the first five minutes googling the syntax again. jq is powerful — genuinely
— but it's its own language, and unless you're writing complex transformations daily, that overhead
adds up.

gron is the other tool I kept coming back to. It flattens JSON into greppable dot-notation, which
is exactly what you want when you're trying to find where a deeply nested key lives. But gron is
read-only. You can't filter and get structured output back. You can't fetch from a URL. The color
situation is nonexistent.

So I scoped out what I actually needed:

Flatten JSON to dot-notation paths (a.b.c = value) so I can see structure at a glance
Filter by key pattern without learning a query language
Fetch directly from a URL so I don't have to curl | jray every time
Color output by default on TTY
Fast enough that it doesn't feel like overhead when I'm in the middle of something

Bun was the obvious runtime choice. Fast cold start, native TypeScript support, a built-in test
runner, and bun build --compile that bundles everything into a single self-contained binary. No
Node.js version headaches, no separate install step for the runtime.

How it's structured

I kept the architecture intentionally flat. No frameworks, minimal dependencies. The core logic is
split into focused modules:

flatten.ts — recursive flatten and unflatten. Takes a nested object and produces a map of dot-notation paths to primitive values. Unflatten goes the other direction.
filter.ts — glob-style pattern matching on the flattened keys. user.* gives you everything under user, **.id matches any id at any depth.
color.ts — ANSI color output. Keys in one color, values type-aware (strings, numbers, booleans each get their own).
fetch.ts — thin wrapper around Bun.fetch that handles the request, checks content type, and pipes the response into the flatten pipeline.
cli.ts — argument parsing and wiring. Reads from stdin, a file path, or a URL depending on what flags you pass.

The whole thing compiles down to a single binary:

bun build ./src/cli.ts --compile --outfile jray

No runtime dependency on Bun after that. You ship the binary, it works.

The problems I actually ran into

npm name conflict

First thing I did after writing the initial working version was try to publish as jray. Already
taken — and not squatted. An actual published package with actual users. So I had to switch to a
scoped package: @siyadkc/jray.

That sounds like a small change but it cascades. The README, the install command in all the
examples, the binary name in package.json, the GitHub Actions publish step, the Dev.to article
draft I'd already half-written — all of it needed updating. It also changes how users install it
slightly, since scoped packages require the @ prefix. Not a dealbreaker, but check npm before you
name your CLI.

Package size bloat

My first publish was heavier than it needed to be. Bun's compiled binary includes the runtime,
which is expected and fine. But the npm package itself had no files field, so it was packaging
everything — source maps, test files, the node_modules from dev, local configs. None of that
belongs in a published package.

Fix was straightforward:

"files": ["dist/", "README.md"]

That single field cut the published package weight significantly. Always define files. The npm
registry doesn't know what's dev and what's production unless you tell it.

Windows compatibility

I had a postinstall script that ran chmod +x on the binary. Works perfectly on Linux and macOS.
On Windows it throws and the install fails. I wrapped it in a try-catch and updated the docs to note
that Windows users should either run the binary path directly or use WSL. Not the cleanest solution,
but honest about the platform situation. Full Windows support is on the roadmap.

GitHub Actions for CI and publishing

The pipeline itself wasn't complicated — install Bun, run tests, publish to npm on a version tag.
But there's one specific thing that tripped me up: not using --frozen-lockfile in CI.

Without it, bun install in CI can silently update the lockfile, which means your CI might be
testing against different dependency versions than what you developed against. Always use:

- uses: oven-sh/setup-bun@v1
  with:
    bun-version: latest
- run: bun install --frozen-lockfile
- run: bun test

Publishing to npm from Actions requires setting NPM_TOKEN as a repository secret and passing it
through to the publish step. Once that's wired, releases are a tag push away.

What it actually does

# Install
bun add -g @siyadkc/jray

# Flatten JSON from stdin
echo '{"user":{"name":"Eliot","age":24}}' | jray
# user.name = "Eliot"
# user.age = 24

# Flatten a local file
jray data.json

# Filter by key pattern
jray --filter "user.*" data.json
# user.name = "Eliot"
# user.age = 24

# Fetch from a URL and flatten
jray --fetch https://api.example.com/users/1

# Disable color (for piping into other tools)
jray --no-color data.json

The filter uses glob-style matching against the full dot-path of each key. So user.* matches one
level under user, while **.id would match any id at any depth in the document. It's
intentionally simpler than jq's filter syntax — the goal is something you can remember without
looking it up.

Where it sits vs the competition

gron is the closest thing and the most direct comparison. It also flattens to dot-notation and
it's what made me realize there was a gap to fill. But gron has no color output, no URL fetching,
and no NDJSON streaming support. jray has all three.

jq is in a different category. It's a transformation tool — you write expressions, you reshape
data, you do complex operations. jray is an inspection tool. You throw data at it and you
understand the structure immediately. They're complementary more than they're competing.

fx is another one that comes up. Interactive, powerful, but it's a TUI. If you're in a script or
piping between tools, you don't want a TUI. jray is designed to be pipeline-friendly from the
start.

The longer-term vision is broader than just JSON. Supporting YAML and TOML with the same flatten
and filter interface makes it a universal structured-data CLI. There's also TOON (Token Oriented
Object Notation), which is an emerging format that's genuinely useful for LLM developer workflows
since it's optimized for tokenization. That's a real differentiator if the format gets traction.

The launch

Published to npm, wrote this article, posted on X . Also shared in the Bun
Discord since the community there is small enough that people actually read it.

The GitHub Pages site is live. It's getting redesigned right now — moving toward a flatter, more
minimal aesthetic with an interactive playground section where you can paste JSON directly in the
browser and see the flatten and filter output in real time. No install required to try it. That
single feature will probably do more for adoption than any amount of posting.

What I'd do differently

I'd define the files field before the first publish, not after. I'd also check npm for name
conflicts before I was emotionally attached to the name. And I'd set up the CI pipeline before
the first push to main so I wasn't debugging GitHub Actions at the same time I was trying to
ship.

The architecture decisions held up fine. Bun was the right call. The modular structure meant I
could add fetch.ts and color.ts without touching the core flatten logic. That's about as much
as you can ask from a first project's structure.

Try it

bun add -g @siyadkc/jray

GitHub: github.com/siyadhkc/jray

If you're working on something similar with Bun, or you have opinions on the filter API design,
drop a comment. Always curious how other people are solving the same problems.

This is my first article writing on this platform so if i made any narration mistake or anything feel free to tell me, i will improve my writing skill and the way of telling this
-- let's get connected --

From Hardware to Hacking: How Understanding Systems Changed My Approach to Security

siyadhkc — Wed, 15 Apr 2026 15:56:13 +0000

Introduction

I didn’t start my journey in cybersecurity. I started with hardware and networking, learning how systems actually function at a low level — how machines communicate, how configurations impact behavior, and how failures happen.

The Shift to Development

Later, I moved into development, working with Python and full-stack technologies. Building applications helped me understand how software is structured, but it also revealed something important:

Most applications are not built with security as a priority.

The Turning Point

This realization pushed me toward cybersecurity, specifically:

Web application security
API security
Cloud platforms (AWS, Azure, GCP)

Instead of just building systems, I began analyzing how they can be exploited.

A Different Way of Thinking

The biggest shift was in mindset:

From:
“How do I build this system?”

To:
“How can this system fail or be attacked?”

This dual perspective — builder and attacker — is critical in modern cybersecurity.

What’s Next

I’ll be sharing:

Practical security insights
Real-world learning experiences
Breakdowns of vulnerabilities and misconfigurations

If you’re interested in understanding systems deeply — not just building them, but also testing their limits — follow along.

I built a modern alternative to gron using Bun and TypeScript

siyadhkc — Sun, 12 Apr 2026 17:16:36 +0000

The problem

Working with JSON in the terminal is painful. jq is powerful
but requires learning a whole query language. grep works but
matches values too — not just paths.

For example if I search for "name" in my JSON:

grep matches json.user.name ✅ (correct)
grep also matches json.bio = "my name is Alice" ❌ (wrong)

So I built jray.

What jray does

jray flattens any JSON into one line per value:

$ jray data.json
json.organization.name = "Acme Corporation"
json.users[0].name = "Alice Pemberton"
json.users[0].role = "admin"
json.users[0].active = true
json.billing.plan = "enterprise"

Now you can grep it, awk it, pipe it — using tools you already know.

Four commands that cover everything

# Flatten with color output
jray data.json

# Fetch a URL directly — no curl needed
jray https://jsonplaceholder.typicode.com/users/1

# Filter by path only (never matches values)
jray data.json --filter "billing"

# Extract any subtree as clean JSON
jray data.json --select "billing"

# Print just the values
jray data.json --values

# Reconstruct original JSON
jray data.json | jray --ungron

The comparison with existing tools

Feature	jray	jq	gron
Flatten to lines	✅	❌	✅
Reconstruct JSON	✅	❌	✅
Filter by path	✅	✅	❌
Extract subtree	✅	✅	❌
Fetch from URLs	✅	❌	✅
Color output	✅	✅	✅
No query language	✅	❌	✅
TypeScript / modern	✅	❌	❌

What I learned building it

This was my first open source CLI tool. Key lessons:

1. Separate your CLI from your logic
cli.ts handles only I/O — reading files, printing output.
flatten.ts, filter.ts etc. know nothing about terminals.
This makes everything testable in isolation.

2. Use unknown not any in TypeScript
JSON is dynamic but that doesn't mean any. Using unknown
forces you to check types before using values — much safer.

3. Recursive functions are perfect for JSON
JSON is a tree. Walking a tree with recursion is the
cleanest pattern — each call handles one node and
delegates children back to itself.

4. Bun is genuinely fast and simple
Native TypeScript, built-in fetch, fast startup.
For a CLI tool, Bun is a great choice.

5. The README matters as much as the code
Nobody uses a tool they can't understand in 30 seconds.
Writing clear examples with real output is as important
as writing the code itself.

Install and try it

npm install -g @siyadkc/jray

Then:

jray https://jsonplaceholder.typicode.com/users/1

GitHub: github.com/siyadhkc/Jray

for more info Website: https://siyadhkc.github.io/Jray/

This is my first open source tool. Feedback on the code
quality is very welcome — especially from experienced
TypeScript developers!