What inspired Deployless? The inspiration came from a side project where I had to create announcements logic which can be operated from admin dashboard. I realized that site announcements are dynamic data, not static code, yet we treat them like core application logic. I wanted a way to decouple "ephemeral UI" (things that appear and disappear) from the core deployment cycle, without sacrificing performance. The Problem We Solved Most existing "announcement" tools were built for non-technical users. They were heavy, slow, and worst of all they broke the site's layout because their global CSS clashed with the application's styles. Deployless was built to solve the "Dev-Tool Paradox": Speed: It had to be faster than a redeploy. Performance: It couldn't bloat the JS bundle. Isolation: It couldn't break the parent site's design. How the Process Evolved My initial approach was a simple JSON fetch. But as I built it, the process evolved into something much more sophisticated: From Centralized to Edge-First: I realized that checking rules (like "only show this on /pricing for mobile users") shouldn't happen on a central server. We moved everything to Cloudflare Workers, bringing the "Evaluation Logic" within 50ms of the user. The JIT Breakthrough: I hated that most widgets load 100KB of "just in case" code. I re-architected Deployless to use Atomic JIT Loading. The initial script is only ~2KB. It only fetches the "Rendering Engine" (bar, popup, or toast) if a targeting rule actually matches. Shadow DOM as a Standard: Early testers complained about CSS leaks. I decided to make Shadow DOM encapsulation a non-negotiable part of the architecture. It was harder to build, but it guarantees that a Deployless widget looks identical on a 2010 WordPress site and a 2024 Next.js app.

Deployless

Ship site announcements in 150ms without a redeploy.

Ship site announcements in 150ms without a redeploy.