The latest articles on DEV Community by ARITRA SARKAR (@aritrasarkar). https://dev.to/aritrasarkar https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1048198%2F8c8a1fb7-63e5-40b2-9f7c-21add3964b8d.png https://dev.to/aritrasarkar en ARITRA SARKAR Fri, 10 Jul 2026 13:58:24 +0000 https://dev.to/aritrasarkar/im-building-a-video-platform-alone-heres-the-stack-that-makes-it-possible-1nbd https://dev.to/aritrasarkar/im-building-a-video-platform-alone-heres-the-stack-that-makes-it-possible-1nbd <p>Video infrastructure has a reputation for needing a funded team — ballooning storage costs, transcoding pipelines, uploads that die at 90%.</p> <p>A few years ago that reputation was earned. It isn't anymore.</p> <p>Here's the actual stack running <strong><a href="https://seamlift.com" rel="noopener noreferrer">SeamLift</a></strong>, what each piece solves, and what I deliberately didn't use.</p> <h2> Storage — Cloudflare R2 </h2> <p>The silent killer in video isn't storage, it's egress. Every view means bandwidth leaving your bucket. On S3, that bill scales with your success — a horrible incentive to build on.</p> <p>R2 charges zero egress. You pay to store the file, not to have it watched.</p> <blockquote> <p><strong>Why not S3?</strong> Egress.<br> <strong>Why not Backblaze or Wasabi?</strong> I didn't run an exhaustive bake-off — I already trust Cloudflare and run other things there, so consolidating beat chasing a marginally cheaper bucket.</p> </blockquote> <h2> Transcoding — Modal </h2> <p>Uploads arrive in every codec imaginable and need normalizing with FFmpeg. That's heavy, bursty compute: a lot of CPU for ninety seconds, then nothing. Running a 24/7 server for that is waste.</p> <p>Modal spins up a container on demand, runs the job, and disappears. I pay for the seconds I actually transcode.</p> <blockquote> <p><strong>Why not Lambda?</strong> The 15-minute and payload ceilings bite on large files.<br> <strong>Why not a dedicated video service?</strong> Modal got me shipping faster. Cost optimization is a problem I've earned the right to have later.</p> </blockquote> <h2> Uploads — The TUS Protocol </h2> <p>Video files are big and real-world networks are flaky. A 2GB upload that dies at 90% on hotel wifi is a rage-quit. TUS makes uploads resumable — a dropped connection picks up where it left off instead of starting over.</p> <p>For a tool editors use to send large files, that's not a nice-to-have. It's the product.</p> <blockquote> <p><strong>Why not S3 multipart?</strong> It can be made resumable too. I went with TUS because it's an open protocol built for exactly this, with mature client libraries, and it isn't welded to one storage vendor.</p> </blockquote> <h2> Hosting — Vercel + Railway </h2> <p>Frontend on Vercel: easiest path, and free at my current scale.</p> <p>Backend on Railway because, in my opinion, it scales with usage instead of charging a fixed slab of compute and RAM whether I use it or not.</p> <h2> Why Not Just Buy a Managed Video API? </h2> <p>Mux, Cloudflare Stream, and api.video are all genuinely good options — the obvious "just buy it" path for a solo founder.</p> <p>I chose to assemble primitives instead, for two reasons: <strong>cost</strong>, and because I wanted to actually understand and own the thing I'm building on.</p> <h2> The Takeaway </h2> <p>None of these are exotic. That's the point.</p> <p>One person can now build what genuinely needed a team five years ago, because the hard parts are managed primitives you can rent by the second.</p> <p>The job isn't building the hard infrastructure anymore. It's knowing which piece solves which problem — and wiring them together well.</p> webdev cloudflare video saas ARITRA SARKAR Tue, 30 Jun 2026 03:35:49 +0000 https://dev.to/aritrasarkar/my-serverless-database-was-billing-me-like-it-never-slept-ffc https://dev.to/aritrasarkar/my-serverless-database-was-billing-me-like-it-never-slept-ffc <p>My "serverless" database was billing me like it never slept.</p> <p>Neon has this great feature called scale-to-zero. Your Postgres compute suspends when it's idle, so you only pay for the queries you actually run. For a pre-revenue product, that should cost a few cents a month.</p> <p>Mine ran 24/7. The compute never once scaled to zero.</p> <p>The culprit wasn't my app logic. It was my database driver.</p> <p>I was using postgres-js, which holds a persistent connection open to the database. From Neon's side, an open connection looks like activity, so it never suspended. It just stayed awake and kept quietly billing me.</p> <p>The fix was basically one conceptual change: switch to @neondatabase/serverless, the HTTP driver.</p> <p>Instead of a long-lived connection, every query becomes a stateless one-shot HTTP request. The query fires, the connection closes, and the compute is free to suspend.</p> <p>Scale-to-zero finally worked.</p> <p>The lesson I keep relearning as a solo founder: "serverless" is a property of your whole stack, not a checkbox on one service. One persistent connection upstream and the whole cost model breaks.</p> neondb postgres serverless infrastructure