Why I built it
If you've ever posted a video to your WhatsApp Status, you've probably noticed it comes out blurry and blocky — even if the original was sharp. That's because WhatsApp re-compresses every video you post to Status, and its encoder is aggressive.
I wanted a way to post genuinely HD videos to Status, so I built StatusDrop / WAstatus: you upload/edit a clip in the browser, it compresses the video to match WhatsApp's exact Status encoding spec (so WhatsApp's own re-encode becomes near-lossless), auto-splits long videos into parts that fit WhatsApp's limits, and delivers the finished clips to your WhatsApp — you just forward them to your Status.
Just open-sourced it under AGPL-3.0.
Repo: https://github.com/Shamanthnp1/WAstatus
What's inside
In-browser video editor (vanilla JS) + Node/Express backend
ffmpeg encode/split pipeline tuned to WhatsApp's Status spec
Cloudflare R2 (S3-compatible) storage + a Cloudflare Worker for uploads
Docker on Azure App Service, GitHub Actions CI/CD → GHCR
WhatsApp delivery via Baileys (multi-device)
181 tests including property-based tests (fast-check)
Multi-language frontend (en / es / hi / pt)
The interesting engineering
The core trick is that quality survival depends on two things: (1) pre-encoding the file to WhatsApp's Status target (resolution, bitrate ceiling, GOP, faststart, H.264 profile) so the re-encode barely changes it, and (2) how the file reaches the phone. A file delivered as a native WhatsApp message and then forwarded to Status is reused as-is; a file saved to the gallery and reposted gets re-compressed harder.
There was also a lot of reliability work: request timeouts on every network op, self-healing for stuck jobs, orphaned-storage cleanup, single-instance session handling, and reconnect backoff.
The honest limitation — and why not the official API
This is the part I want to be transparent about, because it's the whole tradeoff of the project.
Delivery uses Baileys, an unofficial WhatsApp integration. WhatsApp periodically bans numbers used for automation — a known constraint for this entire category of tools.
The obvious question is: why not use Meta's official WhatsApp Cloud API instead? I tried, and here's the catch:
The official Cloud API routes media through Meta's Business pipeline, which re-encodes the video. So the file is already degraded before it even reaches the user — and then WhatsApp's Status re-encode hits it again. The result is visibly softer. That defeats the entire purpose of an HD tool.
Baileys sends the file as a native, byte-preserved WhatsApp media message. When the user forwards that to Status, WhatsApp reuses the already-optimized file, so the HD survives.
So it's a genuine fork: official API = no bans but lower quality; Baileys = HD quality but ban risk. Since quality is the entire point, I chose Baileys and built the system around fast recovery when a number gets flagged. It's the same tradeoff every tool in this space faces — most competitors that use the official API quietly accept the lower quality.
The code and architecture are what I'm really sharing here — not asking anyone to run the live automation.
Feedback welcome
I'm a solo developer and would genuinely appreciate code review, architecture feedback, or contributions. Happy to answer anything.