DEV Community: Charles Kariuki

From 47 to 75 Commits: How a Single _headers File Broke My Brain (and My App) for 8 Hours

Charles Kariuki — Wed, 24 Jun 2026 11:05:36 +0000

The 8-Hour "Please Work" Marathon

We’ve all been there. You have a vision. You want to build a completely free, local-first, privacy-respecting PWA toolkit (NeatKit). Everything is running smoothly until you decide to implement client-side video processing using ffmpeg.wasm.

Suddenly, you are slapped in the face by browser security rules, SharedArrayBuffer requirements, and Cross-Origin Isolation blockades.

Yesterday, my repo was sitting at a comfortable 47 commits. Today? 75 commits.

By commit #65, my commit messages literally just said "please please work."

Grasping at Straws (and breaking my own site)

When you're 6 hours deep into a web worker security issue, you start losing your mind. I questioned everything I knew about how Cloudflare handles routing, headers, and workers. I convinced myself that my entire deployment pipeline was fundamentally broken.

In a moment of pure desperation, I did the unthinkable: I deleted the deployment files on Cloudflare entirely to rebuild from scratch.

For 30 terrifying minutes, the live production site was a completely empty void. No tools. No layout. Just blank space.

The Twist Ending

After tearing down the infrastructure and treating the codebase like a crime scene, the culprit wasn't a massive structural flaw. It was a configuration issue inside the _headers file the entire time.

Cloudflare Pages handles headers brilliantly, but if your syntax or placement is even slightly off when trying to pass strict Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP) rules, the browser tab silently sandboxes your workers into oblivion.

My 2 Big Takeaways From the Trenches:

Local-first WASM has strict boundaries: Client-side processing means ultimate privacy, but it also means dealing with strict browser sandboxing. For heavy files, cloud servers win. For small, quick utility trims, local WASM is amazing—but you have to play by the browser's origin rules.
Walk away sooner: If I had stepped away at commit #55 instead of nuking my environment, I probably would have found the file syntax error in 10 minutes instead of 3 hours.

The site is finally back up, the video trimmer is fully functional for short clips, and I am going to sleep for a week.

Check out the final, working product here: NeatKit

45 Commits Later: Turning my browser-based utility suite into a fully offline PWA (with client-side video editing)

Charles Kariuki — Tue, 23 Jun 2026 07:23:53 +0000

The Core Concept

A few weeks ago, I launched NeatKit—a suite of free web utilities aimed at solving a common frustration: having to upload sensitive files (like PDFs, images, and now videos) to random cloud servers just to perform basic tasks like compressing or trimming.

From day one, the architecture was 100% client-side. The browser does all the heavy lifting using local processing power. But yesterday, after crossing the 45-commit mark on the repo, I finally took the architecture to its logical conclusion: NeatKit is now an officially installable Progressive Web App (PWA) that works completely offline.

Why Local-First + PWA is a Game Changer for Utility Tools

Most online file converters follow a traditional client-server model:

You upload a 50MB video file.
The server processes it (and keeps your data in a cache somewhere).
You download the processed file.

This model is slow, terrible for data privacy, and burns through internet bandwidth. By leveraging modern browser APIs and WebAssembly, NeatKit bypasses the server entirely.

By upgrading the platform to a PWA with aggressive service worker caching, you can now literally turn off your Wi-Fi, open the app, and it will still compress your videos or merge your PDFs perfectly.

What’s New in the App?

Along with the PWA upgrade, I just shipped three new intensive, browser-based video tools that run entirely client-side:

Video Compressor: Shrink mp4/webm files directly in your tab without burning upload data bundles.
Video Trimmer: Fast, frame-accurate cuts using local browser processing.
Video to GIF: Convert clips into high-quality GIFs instantly without watermarks.

Because it happens locally, a 100MB video uses 0MB of internet data to process. You only use data to load the website the very first time.

Lessons Learned & Challenges

Setting up the service workers to handle heavy media processing assets offline was a massive headache. Ensuring that the caching strategies didn't choke when dealing with large file buffers in the browser tab required a lot of trial and error (hence the jump to 45 commits!).

I’m currently mapping out the next phase of development. If you are a developer who hates clunky, ad-ridden web tools, I’d love for you to test this out.

Try installing the PWA, kicking your device into airplane mode, and seeing if you can break it.

I’m wide open to critiques on the architecture, UI improvements, or suggestions on what utility tool I should build client-side next!

Check it out here: neatkitapp.com

How I Built a Suite of 16 Web Utilities with Zero Backend and $0 Hosting Costs

Charles Kariuki — Sun, 21 Jun 2026 15:13:13 +0000

We've all been there. You need to quickly compress a JPEG, split a PDF, or convert an ID card image to a document format. You Google it, click the first link, and immediately get hit with:

A mandatory account signup.
A premium paywall because your file is 1MB over their "free tier" limit.
The uneasy feeling of uploading a sensitive personal document to a random, opaque cloud server just for a 2-second processing task.

I'm a software engineering student, and frankly, I got tired of it. Modern browsers are incredibly powerful, yet we still route basic byte-manipulation tasks through external servers.
So, I decided to build an alternative: NeatKit — a zero-bloat web hub with 16 essential tools that run 100% client-side. No signups, no limits, and absolutely nothing leaves your machine.

The Core Architecture: Why No Backend?
The design philosophy behind NeatKit is simple: Your browser is the server. By eliminating a backend entirely, I solved two massive problems at once:

Privacy: User data never leaves their device. If you inspect the Network tab in DevTools while running a heavy PDF merge or compression, you'll see exactly zero outbound data packets containing your files.
Infrastructure Costs: Since the user's CPU handles all the heavy lifting, my hosting bill is exactly $0. The site scales infinitely without me needing to worry about server clusters, memory leaks, or execution timeouts.

The Tech Stack (Squeezing the Browser)
To keep things lightning fast, I kept the foundational stack as close to the metal as possible:

Vanilla JavaScript & TailwindCSS: I wanted near-instant initial page loads. No massive framework overhead, just highly optimized script modules loaded as needed.
HTML5 Canvas API: This does the heavy lifting for all image processing tools. When you drop an image into the compressor, JavaScript paints it to an offscreen canvas, samples the pixel data, and recalculates the compression ratios locally.
pdf-lib: For handling PDF creation, splitting, merging, and compression. It allows NeatKit to manipulate document structures directly in-memory as binary arrays (Uint8Array), rendering new, optimized blobs in milliseconds.

🛠️ What's Under the Hood Right Now?
I've rolled out 16 utilities so far, broken down into a few categories:

Document Tools: PDF Compressor (just shipped today!), PDF Merge & Split, Image to PDF convertor, and an "ID Card to PDF" converter (great for printing/compliance)
Image Handling: Client-side image compressor, format converters, and SVG tools.
Dev Utilities: Base64 encoder/decoder, QR code generator, and hex-to-RGB color converters.

Lessons Learned & What's Next
Building this completely solo taught me a massive lesson about asset optimization and cross-browser quirks—especially handling high-resolution image rendering on mobile browsers where RAM allocation is tightly throttled.

The project is live at neatkitapp.com.

Since this is a fresh launch, I’d love for the Dev.to community to check it out. Please, absolutely roast the UI, try to break the performance, or let me know what essential daily tool you think I should add to the suite next!