DEV Community: Dhruv malaviya

I analyzed 30 winning dropshipping products. 7 patterns they all share.

Dhruv malaviya — Fri, 26 Jun 2026 09:15:30 +0000

Looked at 30 products running Meta + TikTok ads
profitably. 7 patterns every single one had:

PRICE: $25-$65
Below = thin margins. Above = harder impulse.

BUNDLE OPTIONS
"Buy 2 save 10% / Buy 3 save 15%" — every store had
this. None were single-product only.

VISUAL HOOK IN 3 SECONDS
Unique design, specific problem solved, or "wow factor."
Generic products failed.

REAL REVIEWS WITH PHOTOS
Not 5-star spam. Real, mixed reviews. Even negatives
build trust.

SHIPPING TIME ON PDP
Every store disclosed it directly. None hid it in FAQ.

STICKY ADD-TO-CART ON MOBILE
All 30 had it. If your Add to Cart scrolls off-screen
on mobile, you're losing sales.

POST-PURCHASE UPSELL
"Add this for $X" / subscription / bulk refill.
This is where AOV lives.

WHAT THEY DIDN'T HAVE

Live chat (only 4/30)
Exit-intent popups (only 2/30)
Countdown timers (only 3/30)
Countdown timers (only 3/30 — most had REAL shipping urgency instead)
Multiple payment options visible on PDP (most just had Shopify default)

The "guru tactics" aren't what winning stores use.

3 QUICK WINS

Pick products with visual hooks
Bundle by default
Fix PDP before scaling ads

Why I Switched to Krova.cloud - Better Security, No Overselling, 40% Cheaper

Dhruv malaviya — Thu, 11 Jun 2026 06:44:15 +0000

Hey Devs 👋

Tired of paying premium prices for oversold, shared-kernel cloud infrastructure? Same. Let me introduce you to Krova.cloud — here's why it caught my attention:

🔐 No Shared Kernel Each VM (called a Cube) runs its own isolated kernel via Firecracker microVM technology - same tech behind AWS Lambda. No shared kernel = no cross-tenant risk. Real isolation, not container-level illusions.

🌐 No Public IP Exposure Your Cube doesn't sit naked on the internet.

💾 Backups Done Right

✅ RAID 1 mirrored disks - drive failure won't kill your server
✅ Snapshots built-in - not a paid add-on
✅ Backups stored on separate redundant storage
📊 RAM & Disk - Sold 1:1 Most providers thin-provision their hardware and oversell it. Krova sells every GB of RAM and disk 1:1 with actual hardware. What you pay for is genuinely yours. No noisy neighbors. No surprise slowdowns.

💸 Price? 40%+ cheaper than AWS Lightsail, DigitalOcean & Vultr. Per-hour billing. No hidden fees. Custom-sized VMs - no forced bundles.

Free $5 credits to start - no credit card needed 👉 krova.cloud 🙌

Krova: a security-first “VPS” where your server has no public IP by default

Dhruv malaviya — Thu, 11 Jun 2026 05:19:33 +0000

Most “I got hacked” (or “why is this box getting hammered?”) stories I’ve seen start with the same default: every server gets a public IP.

I’ve been working on Krova — cloud compute that flips that default.

The 4 ideas (quick)
1) No public IP per server by default
A Krova “Cube” (server) lives on a private NAT’d network. There isn’t a public IP sitting out there waiting to get scanned.

2) No shared kernel
Each Cube runs as a Firecracker microVM with its own kernel - not shared-kernel containers.

3) Snapshots + restore/rollback
Built-in snapshots so “snapshot before upgrade → rollback if needed” is a normal workflow.

4) 1:1 RAM + disk (no overselling)
If you provision 4GB RAM + 40GB disk, that’s reserved 1:1 on the host (no thin-provisioning surprises).

What “using it” looks like
1) Create a Cube (pick vCPU/RAM/disk) and SSH in as root.
2) Deploy normally (systemd, Docker, packages -
3) Expose only what you need:

attach api.yourdomain.com → port 8080 (HTTPS)
open SSH (or Postgres) via a TCP mapping, allowlisted to your IP/VPN 4) Snapshot before risky changes. Restore if it breaks.

If you’re curious, the site is here:
https://krova.cloud/

I’d love feedback from folks who run infra:

Is “no public IP by default” a win, or does it break too many real-world workflows?
What would you want to see from snapshots/backups before trusting a newer provider?

Why I built my cloud platform on micro-VMs instead of containers (a security story)

Dhruv malaviya — Wed, 03 Jun 2026 07:55:21 +0000

Containers are great until you remember they all share one kernel. For a lot of workloads that's fine. But the moment you're running untrusted code, multi-tenant jobs, or anything you wouldn't want leaking into its neighbours, a single kernel exploit is the whole game. That worry is exactly why I made an early architecture call for my platform, Krova krova: no shared-kernel containers.

Enter Firecracker
Firecracker is the open-source micro-VM monitor AWS built to run Lambda and Fargate. Each instance is a real hardware-virtualized VM (KVM under the hood) with its own kernel, but it boots in around 125ms and carries almost none of the weight of a traditional VM. You get the isolation boundary of a VM with something close to the start-up feel of a container.

That trade-off is perfect for security-minded, ephemeral work:

Hypervisor-level isolation. Tenants are separated at the virtualization boundary, not by namespaces over a shared kernel.
Tiny attack surface. Firecracker deliberately ships a minimal device model, far less exposed than a full VM stack.

How Krova uses it

Every machine on Krova (a "Cube") is its own Firecracker micro-VM with its own kernel. They get private internal networking rather than a public IP each, ingress is explicit port mapping, and you can sleep or destroy a Cube the instant you're done. So "run something untrusted, then make it vanish" is the default path, not a thing you bolt on.

And because they boot in about a second and keep their disk between sleeps, the security model doesn't cost you convenience, which is usually the part that makes people skip isolation in the first place.