John D

Posted on Mar 12

I Built 75 Browser-Based Tools With Next.js and Zero Backend.

#webdev #javascript #productivity #sideprojects

No waitlists. No accounts. No paywalls. Just tools that work.

I kept running into the same problem: needed a quick text formatter, word counter, or list sorter — and every existing option was bloated, ad-heavy, or demanded an account before it would do anything.

So I built usefmtly.com — a collection of 75 browser-based tools covering text formatting, converters, random generators, list tools, and code utilities. The idea was straightforward: make useful tools that open instantly, solve one problem well, and don't demand an account, a trial, or your data before they do their job.

That meant a few constraints from the start:

no login
no backend dependency for core functionality
no "free trial"
just open the page and use the tool

Everything runs client-side. Nothing leaves your browser.

Here's how I built it, what the stack looks like, and what I learned shipping it this way.

Why 75 Tools?

Partly because I like small utilities, and partly because this kind of product maps really well to search.

The model is simple:

useful tools capture action-oriented intent
long-form guides capture informational intent
internal links connect the two

For example:

a tool targets something like "linkedin text formatter"
a guide targets something like "how to bold text on LinkedIn"

Together they cover both "I need this now" and "I want to understand how this works."

I focused on niches where:

monthly search volume was roughly 1k–500k
keyword difficulty was under 20
existing results were weak, outdated, or overloaded with ads

Then I built the tool, paired it with a guide when it made sense, and moved on.

The Stack

The stack is intentionally minimal.

Next.js 15 + React 19
Static export using output: 'export'. No server, no API routes, no database. Every page is deployed as static HTML.

Tailwind CSS
Shared design system and reusable components. Dark mode by default.

TypeScript
Typed tool registry, typed configs, typed component props. I wanted adding new tools to feel mechanical instead of fragile.

Vercel
Deploy from GitHub on every push.

That's it.

The simplicity is the point: it keeps the site fast, cheap to run, and easy to maintain.

How the Tool System Works

Every tool is registered in a central registry:

{
  slug: 'linkedin-text-formatter',
  name: 'LinkedIn Text Formatter',
  category: 'text-tools',
  description: 'Bold, italic & 20+ Unicode styles for LinkedIn posts.',
  keywords: ['linkedin formatter', 'bold text linkedin'],
  relatedTools: ['fancy-text-generator', 'small-text-generator'],
}

From the registry, the site auto-generates:

the tool page at /tools/[category]/[slug]
sitemap entry
llms.txt
related tools blocks
category hub pages

So adding a new tool usually means:

write the engine logic
add the registry entry
build the client component
write the article content
deploy

I kept it to one Linear ticket per tool, which made the work much easier to manage.

The Article Pattern That Saved Performance

Each tool page includes an embedded SEO article, usually around 400–600 words covering what the tool does, when to use it, and related concepts.

My early mistake was putting the article component inside a 'use client' file.

My early mistake was putting the article component inside a 'use client' file.

The fix was simple: keep the article as a server component and pass it into the interactive client component as a prop.

// page.tsx (server component)
export default function Page() {
  return (
    <FormatterToolClient article={<LinkedInFormatterArticle />} />
  )
}

// FormatterToolClient.tsx ('use client')
export function FormatterToolClient({ article }: { article?: React.ReactNode }) {
  // interactive tool logic here
  return (
    <>
      <ToolUI />
      {article}
    </>
  )
}

That brought Lighthouse back to 100.

The lesson was obvious in hindsight: render content on the server, keep the client boundary only around the interactive bits.

Shipping 75 Tools Without Losing Your Mind

A few things made the project much easier to ship than I expected.

One ticket at a time
Each tool got its own Linear ticket, its own commit, and its own deploy. No giant "tool batch" tasks. That forced me to actually finish things.
Shared components early I built reusable pieces like ToolLayout, ToolCopyButton, ThemeSwitcher, and ToolToggle early. After that, consistency came almost for free.
Keyword research before implementation
Every tool started with keyword validation. If there wasn't search demand, I didn't build it.
Static export as a constraint
Not having a backend removed a lot of tempting shortcuts. Every tool had to be genuinely browser-based.

What's Live

75 tools across 5 categories:

Text tools — LinkedIn formatter, word counter, case converter, glitch text, fancy text, strikethrough, and 20+ more
Converters — Hex/RGB/HSL, temperature, decimal/binary, number to words, Roman numerals
List tools — alphabetical sorter, deduplicator, merge lists, list compare, randomizer
Random generators — colors, names, passwords, UUIDs, animals, countries, emojis
Code tools — JSON/YAML formatter, HTML↔Markdown, CSV↔JSON, JWT decoder, ASCII art

I also added 18 long-form guides around adjacent informational keywords like word count, percentage calculators, lorem ipsum, and JSON formatting.

The Numbers Right Now

The site is still early.

It's launched, indexed in Google Search Console, and now I'm waiting to see how rankings settle over the next few months.

The bet is that 75 tools + 18 guides creates enough topical surface area for organic traffic to compound over time.

We'll see if that plays out.

What I'd Do Differently

A few things are already obvious.

Build the guide layer earlier
I focused on tools first and guides second. In practice, those should have been built in parallel.

Set up rank tracking on day one
I didn't, and now I'm retroactively tracking a large batch of keywords instead of watching them from launch.

Lean into internal linking sooner
Once you have dozens of tools, the structure matters almost as much as the individual pages.

Why I Like This Model

I like products that stay small and useful.

No onboarding.
No "book a demo."
No friction between intent and action.

Just pages that load fast and do one thing well.

For utility sites, that feels like the right tradeoff.

Check It Out

usefmtly.com — free, no account, no ads (for now).

If you've built anything similar — utility sites, SEO-first products, or small tools with a static architecture — I'd love to hear what worked for you.

Built with Next.js 15, React 19, Tailwind, TypeScript, and Vercel. All tools run client-side.

DEV Community