John Barbagallo

Before writing a line of code professionally, I was an Army Sergeant, a cell tower technician, and a lineman. The career pivot happened in 2017 — built a couple of Shopify stores for myself, learned HTML and enough JavaScript to be dangerous, and found that the problem-solving instinct that served me in the field translated directly to debugging front-end issues at 2am.

From there: freelanced on Upwork, built contractor sites through Level10, and eventually joined Guardian Recovery Network managing and optimizing 15+ web assets. Over that stretch I accumulated real exposure to hosting, DNS, PHP, SQL, UX/UI, and the kind of performance work that forces you to actually understand what the browser is doing — not just what the framework abstracts away.

SplitForge came out of a specific frustration: the data tools I needed for client work all required uploading files to servers I didn't control. For a healthcare client's CSV, that's not acceptable. Client-side processing wasn't the obvious choice — it was the only acceptable one. The browser performance work I'd done previously made the Web Worker architecture feel natural. The rest was iteration.

SplitForge started as a weekend project to solve a specific problem: splitting a 2GB CSV file that Excel refused to open and every online tool required uploading. The first version was a single tool. It worked. Then a second problem appeared, then a third.

What started as one tool is now 27 production tools handling CSV splitting, merging, deduplication, Excel repair, data masking, format conversion, and more — all running entirely in the browser, with no server involvement at any step.

The benchmark that proved the architecture could scale: 2 million rows processed in seconds, in a browser tab, on commodity hardware. That's when it became clear SplitForge wasn't just a workaround — it was a better approach.

Why Privacy Has to Be the Foundation

Honest Context