What 26 small tools taught us about scope

Technology · 2026-06-24 · 7 min read · 1575 words

By ESPYCRUX, Studio

Smart Tools Today is twenty-six utilities that each do exactly one thing, run entirely in your browser, and ask nothing of you. Here is what that constraint rules out, why "runs in your browser" is a promise worth checking, and what we learned about deciding a thing is worth building.

There is a version of every small utility on the web that is worse than it needs to be. You search for a JSON formatter, land on a page carrying four adverts and a cookie banner, paste in something from work, and a spinner appears — because your data has just been sent to a server to be formatted. Then you are asked to sign up to format more than three times a day.

None of that is necessary. Formatting JSON is a task a browser can do instantly, locally, for free. The signup exists to capture you; the server round-trip exists because that is how the site was built, not because the work requires it.

Smart Tools Today — the tools property in our network, built by Gagan Sahu, who joined the studio after it had started — is twenty-six tools that refuse all of it. Twenty-six, nine categories, no accounts, nothing uploaded.

The constraint, and why it is three constraints

Everything on the site runs client-side. The site puts it plainly:

Your data stays on your device. We never collect, store, or transmit your input.

That is one rule doing three jobs at once, and it is worth separating them because most people assume only the first.

It is a principle. A JSON formatter has no business seeing your JSON. The document you paste in is frequently something from work — a config, an API response, a payload with a customer's details in it. A tool that does not receive it cannot leak it, cannot be subpoenaed for it, and cannot change its privacy policy about it later. The strongest privacy guarantee is not a promise of good behaviour, it is an architecture with nothing to behave badly with.

It is simplicity. No server means no accounts, no sessions, no database, no rate limiting, no password resets, no migrations, no on-call. An enormous amount of what makes software expensive to run is the machinery around holding other people's data. Refuse the data and most of that machinery becomes unnecessary.

It is cost. Static pages are close to free to serve, and stay close to free if a tool is suddenly popular. A server-backed tool that gets shared widely presents you with a bill; a client-side one presents you with nothing. That is what makes "∞ uses per day" a sentence we can actually write, rather than a limit waiting to be introduced when it gets expensive.

The three reinforce each other, which is why the rule has held across twenty-six tools. Any one of them alone might have bent.

How to check a claim like that

You should not take our word for it, and you should not take anyone else's either. "Private" and "secure" appear on the marketing pages of tools that upload everything you give them.

The check takes fifteen seconds:

1. Open the tool.
2. Open your browser's developer tools, Network tab.
3. Use the tool — paste something in, hit the button.
4. Watch whether a request goes out.

If the tool works and the Network tab stays quiet, the work happened on your machine. If a request fires with your input in the body, it did not. There is no way to fake this, and it is the only privacy claim on the web you can verify yourself in a few seconds.

A second check, for the properly suspicious: turn off your network entirely and reload. A genuinely client-side tool still works offline once loaded. A server-backed one does not.

We would rather people ran that check than trusted the sentence.

Twenty-six tools, nine categories

The interesting thing about that table is the Calculator row. A developer-tools site would not normally carry a BMI calculator or an EMI calculator — those are not developer tools at all.

They are there because the constraint, not the audience, defines the site. Anything that is a self-contained calculation on data the user already has belongs here. A loan repayment is exactly as suited to running in a browser as a hash is. Once we stopped asking "is this a developer tool?" and started asking "can this run entirely on the visitor's machine?", the catalogue got both larger and more coherent.

What one job actually means

"Does one thing" is easy to say and hard to hold. The pressure is always toward one more feature, because each individual addition is small and defensible.

The test we settled on: can the tool be understood without being explained? A visitor lands on the page, sees an input and an output, and knows what to do. No modes, no settings panel, no tabs — because the moment a tool has three modes, someone has to work out which mode they want, and you have added a decision to a task that had none.

That has consequences you feel later:

One page per tool. Not a single application with a tool picker. It means the URL is the tool, which means it can be bookmarked, shared and searched for directly — someone searching for "unix timestamp converter" should land on a converter, not on a homepage they then have to navigate.

No shared state between tools. Nothing is remembered. That sounds like a loss and is mostly a relief: no preferences to migrate, no stale settings producing confusing output, and no reason for anything to persist between visits.

Fast because there is nothing to load. The site claims "instant results" and the reason is structural rather than clever — there is no server to wait for, and each page carries only what that tool needs. Speed here is a consequence of scope, not an optimisation applied afterwards.

How something becomes a tool

We do not have a framework for this, and having spent some time trying to invent one, I do not think a framework would be an improvement.

New tools come out of discussion — someone hits a need, mentions it, and we work out together whether it belongs. The useful part is not the decision procedure, it is the two questions the discussion always ends up at:

1. Can it run entirely in the browser? If not, it does not go on this site. Not "could we make it work with a small backend" — the constraint is the product, and the first exception would end it.
2. Would you use it more than once? A tool nobody returns to is a demo. Twenty-six tools people come back to is a site; twenty-six clever one-offs is a portfolio piece.

Everything else — how popular the search term is, whether a competitor has one — turns out not to predict much.

Nothing was a waste

The honest answer to "which tool was a waste of time?" is that none of them were, and I want to be precise about why, because it sounds like a dodge.

Each tool is small. The cost of building one that turns out to be unpopular is a few hours, and that is genuinely the whole downside — there is nothing to maintain, no server accruing cost, no users depending on it, no migration to perform. An unpopular client-side tool sits there costing nothing.

This is the part people underestimate about small scope. It does not just make things cheap to build; it makes them cheap to be wrong about. A tool that gets ten visits a month is not a failure, because it never demanded anything to justify. Compare that to a feature inside a large application, where an unused feature still has to be tested, migrated and worked around by everyone maintaining the code near it.

Low stakes per unit is what lets you have twenty-six of something. If each one had to earn its place, there would be six, and four of the six would be the obvious ones everybody already has.

Where it stops

Being straight about the limits.

A client-side-only site cannot do anything genuinely collaborative. No saved workspaces, no sharing a formatted document by link, no history across devices. Those are real features that real people want, and every one of them requires exactly the thing we have refused.

It also cannot do anything that needs a secret. No tool here can call a paid API on your behalf, because the key would have to ship to the browser, where it is not a secret. That rules out a whole family of otherwise obvious utilities.

And discoverability is harder. Twenty-six separate pages with no accounts means no email list, no retention loop, no way to tell anyone a twenty-seventh tool exists. You get whatever search and word of mouth bring you. That is the trade for not collecting anything: you cannot contact people you deliberately know nothing about.

We think it is the right trade. But it is a trade, and a site that tells you it is all upside is selling you something.

Smart Tools Today is at smarttoolstoday.com — 26 tools, no signup, no tracking. Built by Gagan Sahu.

Tags: scope, privacy, client-side

ESPYCRUX — ESPYCRUX is a small product studio based in India, building focused web applications and writing about the engineering behind them. Articles are written by whoever did the work, and published under the studio name. Reach the studio at admin@espycrux.com.