Why I built SnapTools and what I'd do differently

SnapTools was born out of frustration. I found myself constantly switching between ten different websites just to format JSON, encode URLs, or compress images. Building a single, unified web app for these tasks seemed like the obvious solution.

Architecture Decisions

I decided to keep the architecture as simple as possible. No heavy frameworks initially, just pure JavaScript utility functions. This allowed the app to be blazingly fast and fully offline-capable once cached.

What changed

As the toolset grew, maintaining individual scripts became challenging. I learned the value of a modular component system and strict separation of concerns, even in a "simple" utility app.

Good tools get out of the user's way. The interface should disappear, leaving only the functionality.

What I would do differently

If I were to rebuild SnapTools today, I would invest earlier in a robust testing suite for the core utility functions. Edge cases in user input are endless, and catching them manually is unsustainable.