David Oduse

When a video plays normally inside a browser, most of the underlying delivery system remains invisible. A user sees a video player, presses play, and the browser takes care of everything else. Behind that simple interface, the application may retrieve a playlist, request encryption keys, download hundreds or thousands of media segments, decrypt those segments, feed them into a MediaSource object, and finally present the resulting stream through the HTML video element. I recently had to investigate exactly this kind of setup on a custom learning management system. I had permission to download the course videos, but the LMS did not provide an obvious download option. Instead of trying to guess where the original video file lived, I wanted to understand how the browser itself received and played the media. The investigation eventually uncovered a conventional HTTP Live Streaming pipeline built around an M3U8 playlist, AES-128 segment encryption, MPEG-TS media segments, Bunny CDN deliver...

Monesize Engage is a multi-tenant sales engine and CRM platform. The product is designed to help organizations manage prospecting, outbound campaigns, pipeline management, and customer relationships from a single shared workspace. The goal from the beginning was not to build another feature-complete enterprise CRM that nobody uses. It was to build something lean, deliberate, and production-ready from the first release. This post documents the engineering decisions made while building the backend. Not the happy path decisions where everything was obvious from the start, but the real ones where constraints forced choices, where the wrong thing was built first and had to be corrected, and where the architecture had to reflect the product's actual requirements rather than what felt elegant in isolation. The backend is built on Node.js, TypeScript, Express, Prisma, and PostgreSQL. It runs on Monesize's virtual machines with Redis for job queuing. Every decision in this post traces b...

Remote desktop tools like TeamViewer, AnyDesk, and RustDesk are products that most developers use without thinking about what makes them work. I decided to build one from scratch for an on-demand client. The result is Remota, a remote access tool that lets a controller view and control a participant's Windows desktop directly from a browser, with no account required, no installation on the controller side, and a native Rust application handling the heavy lifting on the participant side. This article documents the full technical journey: the architecture decisions, the protocols involved, the problems encountered, and the specific solutions that made it work. Why Build This Existing remote desktop tools are heavyweight, require accounts, often have licensing restrictions for commercial use, and do not give you control over the infrastructure. The goal was a lightweight tool where a controller could share a link, a participant could click it, and a live remote desktop session would b...