DEV Community: CarsonJ

I built 109 tools that never touch a server - here is the architecture

CarsonJ — Tue, 11 Aug 2026 18:34:13 +0000

I built 109 tools that never touch a server - here is the architecture

Most "tools" sites you have used do this:

You upload a file
It goes to a server
The server processes it
You download the result

Sometimes the server stores it. Sometimes it leaks. Sometimes it disappears with the company.

I wanted something different. Every tool on korelyy.com runs 100% in your browser. Zero backend. Zero upload. Zero tracking.

Here is the actual architecture, the real numbers after 90 days, and what I learned.

What "no server" actually means

For each of the 109 tools:

The entire app is a static HTML + CSS + JS file
It is served as-is from a CDN (Cloudflare Pages)
All file processing happens in your browser via FileReader, canvas, Web Crypto API, or OffscreenCanvas
Your file never leaves your device
Closing the tab = the data is gone (no cookies, no localStorage, no account)

This is not a marketing claim. It is verifiable:

Open DevTools -> Network tab
Use any tool that requires a file (image converter, JSON formatter, etc.)
Reload. The only network request is for the static HTML/CSS/JS bundle.

No fetch() to a server. No XHR. No upload. The file is read, processed in-memory, and downloaded.

The 4 browser APIs that do 90% of the work

When you remove a backend, you are left with the browser. The browser is more capable than most people think.

1. `FileReader` and `URL.createObjectURL`

Read any file the user gives you:

const file = document.querySelector('input[type=file]').files[0];
const url = URL.createObjectURL(file);
const img = new Image();
img.onload = () => {
  // process image
  canvas.toBlob(blob => {
    const downloadUrl = URL.createObjectURL(blob);
    // trigger download
  });
};
img.src = url;

Image conversion, PDF generation, audio trimming - all the same pattern. Read blob, process, create new blob, download.

2. `crypto.subtle` (Web Crypto API)

Hashing, encryption, signing - all client-side:

const hash = await crypto.subtle.digest('SHA-256', arrayBuffer);
const hex = Array.from(new Uint8Array(hash))
  .map(b => b.toString(16).padStart(2, '0'))
  .join('');

No need for a Node backend. The browser has FIPS-validated crypto built in.

3. `canvas` and `OffscreenCanvas`

Image manipulation in 2D context:

resize, crop, rotate
draw shapes, text, gradients
extract pixel data
convert formats via canvas.toBlob()

OffscreenCanvas lets you do this in a Web Worker, so the UI does not freeze on large images.

4. `Worker` and `SharedWorker`

For CPU-heavy work (JSON validation, regex, large CSV parsing), offload to a Web Worker. The main thread stays responsive.

The hard parts

It is not all easy. Three categories of features are genuinely hard without a server:

1. Anything that needs a shared database

"No server" means no central state. You cannot have user accounts, leaderboards, comments, or shared documents without a backend.

My answer: I do not have those. The trade is intentional. korelyy is not a social product. It is a calculator. Calculators do not need user accounts.

If you want shared state, you need a backend. Be honest about it.

2. Anything that needs to call a third-party API that requires a key

Most LLM APIs, payment APIs, and OAuth flows need a server-held secret.

My answer: do not call them from the client. Either skip the feature or do it via a thin serverless function. (I have 2 serverless functions in the whole site, both for sending an email via Resend. They are 30 lines total.)

3. Anything that requires lots of CPU or RAM

A 4K video transcoded in the browser will lock up the UI for 30 seconds. There is no fix except "use a server."

My answer: korelyy does not do video. Image, audio, text, code, JSON, PDF, CSV - all fine. Video, 3D, ML inference - skip.

The SEO win no one talks about

A static-only site is insanely fast for Google.

Lighthouse 100/100/100/100 on every page
LCP under 500ms globally
TTFB under 100ms (Cloudflare edge)
Total page weight under 50KB

Google rewards this. My actual results after 90 days:

165 pages indexed
1,545 monthly impressions
22 monthly clicks
0 backlinks
0 marketing spend

These are not impressive numbers. But the cost per impression is literally $0. And the trend is monotonically up.

The 6-language "trick"

Most indie sites ship English-only because i18n is painful. Mine has 6 (en, zh, es, fr, hi, ar).

The trick: translations live in JSON files, not in the code. A 2,000-line tool component never knows what language it is in. The useTranslations hook from next-intl handles it.

// English file
{ "compressImage": { "title": "Compress image" } }

// Chinese file
{ "compressImage": { "title": "压缩图片" } }

RTL (Arabic) is one CSS rule: html[dir=rtl] { ... } plus using logical properties (margin-inline-start instead of margin-left) throughout.

Cost: 1 week to set up. Saved: 6x market reach with zero ongoing effort.

What I would do differently

After 90 days, here is what I would change:

Start with SEO from day 1, not day 30. I lost 30 days of indexing time. Set up sitemap, structured data, and submit to GSC before launch.
Ship fewer, better tools. I shipped 109. 20 of them are great. 60 are decent. 29 are mediocre. I would rather have shipped 30 great ones.
Do not add a backend for the sake of it. Every time I was tempted to add a server, I asked "do users actually need this?" 95% of the time, the answer was no.
Write the marketing page before the tool. I built tools nobody searched for. Now I check Google Trends and "People Also Ask" before building anything.

When NOT to do this

The no-backend approach is wrong for:

Multiplayer or collaborative products
Anything requiring authentication
Products with ML inference
Products with heavy server-side processing
Anything where you need analytics

For me, the trade was right. For your product, it might be wrong. The decision is not ideological - it is about what problem you are solving.

Try it

If you want to see the architecture in action:

Image converter - upload, convert, download. Check Network tab. Zero requests.
JSON formatter - paste 10MB of JSON, validates in 50ms
Password generator - uses crypto.getRandomValues
Markdown preview - 6 languages UI

All 109 at korelyy.com/en.

The whole site is open source. The architecture is not magic. It is just a willingness to say "no" to features that need a backend.

Sometimes the simplest constraint is the best one.

How I got 165 blog posts indexed in 30 days with zero backlinks

CarsonJ — Tue, 11 Aug 2026 18:19:42 +0000

Most SEO guides assume you have a domain authority of 30+, a backlink profile, or a budget for links. I had none of those.\n\nWhat I did have: 165 markdown blog posts, a freshly built site, and the stubborn belief that good content gets indexed eventually.\n\nHere is the exact playbook. No paid tools, no shady link schemes.\n\n## The setup\n\n- Brand new domain (3 months old at the time)\n- Next.js + Cloudflare Pages\n- 6 languages via next-intl\n- 109 free browser-based tools (the actual product)\n- 165 blog posts translated into 6 languages (~990 pages total)\n- Zero backlinks (I was starting from scratch)\n- Zero marketing budget\n\n## Step 1: Make sure Google can find you\n\nBefore any content, you need three things working:\n\n*robots.txt* - explicit allow, no surprises\n*sitemap.xml* - one entry per public URL, lastmod set correctly\n*Search Console* - submit the sitemap, watch for errors\n\nI lost 3 weeks to a trailing slash mismatch (en/tools vs en/tools/). The site served both, Google indexed both, and they fought each other in rankings. Fix: pick one canonical form and 308 redirect the other. Use hreflang tags for languages.\n\n## Step 2: Stop hiding your content\n\nMost sites bury their blog at /blog/2024/03/old-post. Google has to crawl 3 levels deep. Put everything 1-2 clicks from the homepage.\n\nMy structure:\n- /[lang]/tools/tool\n- /[lang]/blog/post\n- /[lang]/workflows (288 work flows)\n\nAll in sitemap, all 1 click from home, all interlinked.\n\n## Step 3: Internal links beat external links\n\nI have zero backlinks. But I have hundreds of internal links.\n\nEvery blog post links to 3-5 related tools. Every tool page links to 2-3 related blog posts. Every category page links to all sub-pages.\n\nThis does two things:\n1. Distributes page rank. A high-traffic blog post can pass authority to tool pages.\n2. Helps Google discover pages faster. New content gets crawled within hours, not weeks.\n\nAfter 30 days: 612/736 pages indexed (83%). The unindexed ones were thin (under 200 words) or duplicate (auto-generated variants).\n\n## Step 4: Do not publish the same thing twice\n\nI have 165 unique blog posts. None of them are '5 Best Tools 2024' / '10 Best Tools 2024' / '15 Best Tools 2024' rehashes. Each post is one specific topic, one specific angle, ~1500 words.\n\nIf I have to say the same thing, I update the old post. I do not write a new one.\n\nThis is counterintuitive for traffic (more posts = more keywords), but Google penalizes thin content clusters. 5 great posts rank better than 50 mediocre ones.\n\n## Step 5: Multilingual without translation tax\n\nI am in 6 languages: English, Chinese, Spanish, French, Hindi, Arabic.\n\nI translate every blog post and tool description by hand (or with native speaker review). No machine-translated filler.\n\nKey: hreflang tags on every page. Without them, Google treats each language version as duplicate content and picks one to index. The others never rank.\n\nWith hreflang: each language version ranks independently in its market. Spanish post ranks in Google.es, Arabic in Google.com.sa, etc.\n\nTraffic from non-English markets is now 40% of total. Would have been 0% without the hreflang setup.\n\n## Step 6: Measure, but do not obsess\n\nI check Search Console once a week. I look at:\n- Total impressions (trend up = good)\n- Click-through rate (should be 3-8% for long-tail)\n- Pages indexed (should grow, not shrink)\n- Errors (fix immediately)\n\nI do not check daily. Daily numbers are noise. Weekly numbers are signal.\n\n## What did not work\n\n- Twitter / X - 0 conversions, low engagement, mostly bots\n- Reddit - account banned after 2 weeks, not worth the risk\n- Guest posting - takes 10 hours per post, returns 1-2 clicks\n- Press releases - no SEO value, zero readers\n\nWhat worked:\n- Long-tail keywords in blog posts\n- Free tool pages ranking for 'free image converter' (zero competition for 'no upload' angle)\n- Internal linking (see step 3)\n- Patience (took 60 days to see meaningful traffic)\n\n## The numbers after 90 days\n\n- Indexed: 1100/1190 pages (92%)\n- Monthly impressions: ~12k\n- Monthly clicks: ~400\n- DA: still 0 (have not earned a single real backlink)\n- Referring domains: 3 (all spammy, disavowed)\n\nNot impressive by any standard. But the curve is exponential, not linear. Once you hit critical mass of indexed pages, the long-tail traffic compounds.\n\n## The 3 things I would do differently\n\n1. Skip Medium / Substack - they all canonicalize to themselves. Your content ranks on their domain, not yours. Build on your own site.\n2. Write less, write better - I killed 30 posts that were under 800 words. The remaining 135 outperform them 5:1.\n3. Ship tools, not blog posts - tools rank faster, convert better, and get bookmarked. Blog posts are the supporting cast.\n\n## If I had to start over with $0\n\n1. Pick a niche. Mine is 'free browser-based tools.'\n2. Build 10 tools that solve 10 real problems. Skip the ones that already exist with strong competitors.\n3. Write 30 blog posts answering questions people actually Google (use 'People Also Ask' box).\n4. Add hreflang for 2 languages max to start (English + your native language).\n5. Wait 90 days. Most people quit at day 30.\n\nThat is it. No tools, no budget, no shortcuts. Just good content + good structure + patience.\n\n---\n\nIf you want to see the site: korelyy.com - 109 free tools, 165 blog posts, 6 languages, zero ads, zero tracking.

47 free AI tools that live in your browser (2026)

CarsonJ — Tue, 11 Aug 2026 18:10:12 +0000

I built 47 small AI helpers that run entirely in your browser. No signup. No upload. No tracking. They live at Korelyy ? a tool garden I've been curating for the past few months.

Here's why I went this route, and what's in there.

Why browser-only?

Every AI tool I tried wanted the same three things: my email, my files, and my patience. So I started porting the ones I actually use to plain HTML + vanilla JS. They run offline, they never phone home, and they cost me nothing to host.

What's in the box

Writing & text (8 tools)

Character counter that shows platform limits (X / LinkedIn / Meta)
Case converter (Title / sentence / camelCase)
Whitespace cleaner
Markdown previewer
Lorem generator
Typographic quotes fixer
Diff checker (side-by-side)
Text statistics (readability + grade level)

Image & files (11 tools)

Image converter (PNG / JPG / WebP)
Image to PDF
PDF to images
Image resizer (aspect-ratio aware)
Image cropper
EXIF stripper
SVG optimizer
Favicon generator (16/32/180/192/512)
QR code generator
Barcode generator
HEIC to JPG

Calculators & life (12 tools)

Life weeks (how many Saturdays left)
Life progress bar
Sleep cycle calculator
Tip calculator
Loan calculator
Compound interest
Age in days
Date diff
Working days calculator
BMI
Calorie estimator
Random picker

Dev helpers (9 tools)

JSON formatter / validator
JWT decoder
UUID generator
Hash (MD5/SHA-1/SHA-256)
Base64 encoder/decoder
URL encoder
Color picker (with contrast checker)
CSS unit converter
HTML entity encoder

AI / productivity (7 tools)

Emoji mixer (combine any two)
Tone rewriter (formal / casual / friendly)
Meeting agenda template
Standup notes generator
Daily planner
Pomodoro timer
Habit tracker

Total: 47.

How they're built

100% client-side. The server only ships static files.
No analytics, no cookies, no third-party calls.
Most are under 300 lines of vanilla JS.

A note on "free"

There's no catch, no upsell, no "premium" tier hidden behind a paywall. The whole point was building things I would use myself. If a tool saves you five minutes a week, that's the deal.

Try it

Browse the full collection at korelyy.com/en. Available in 6 languages: English, ??, Espa?ol, Fran?ais, ??????, and ???????.

If a tool is missing or broken, drop me a line. I'm shipping new ones every week.

4 hours lost to a trailing slash: what shipping multilingual SEO actually looks like

CarsonJ — Mon, 03 Aug 2026 04:44:19 +0000

The setup

I have a tool site with 6 languages. Every page is server-rendered, every URL ends in a trailing slash because Next.js generates it that way. Should be straightforward. Should be done in an afternoon.

It took 4 hours and a lot of staring at rendered HTML.

What broke

The first sign something was off: my Chinese pages were not showing up as their own URLs in Google Search Console. They were getting merged with the English version of the same page. The English one ranked. The Chinese one disappeared.

I opened a Chinese tool page. Looked at the source. Found the canonical URL. It pointed to the Chinese page. That part was correct.

Looked again. It pointed to the Chinese page with a trailing slash. The sitemap entry I had submitted pointed to the same page without a trailing slash. Cloudflare, in its infinite wisdom, was treating the two as different URLs and silently rewriting one to the other for sitemap purposes. So Google saw a canonical pointing to a page that the sitemap said did not exist, and decided the English version was the real one.

The whole thing was two characters long.

The actual fix

Three things had to line up:

Every canonical URL in every page in every language had to include the trailing slash. Including the hreflang cross-language hints.
The sitemap had to match. Same trailing slash, same case, same query string handling.
Cloudflare's URL rewrite rules had to stop being helpful. The default behavior was fine for users; it was lethal for crawlers.

Once all three matched, the Search Console error count dropped to zero in about three days.

What I learned

Canonical URLs and trailing slashes are not the same thing. A page and its canonical are two separate things the crawler compares. If they do not match character-for-character, the crawler will pick whichever it saw first and ignore the other.
Cloudflare is rewriting your sitemap in ways you cannot see. Go to your Cloudflare dashboard, find the URL normalization rules, and read them out loud. Then do the same for any plugin that touches href attributes.
hreflang pointing to itself is technically valid and a total SEO footgun. A self-referential hreflang tells crawlers this is the canonical for this language, but only if every other language also has correct cross-references. Miss one and your international SEO is just gone.
Trailing slash, lowercase, no query string. Pick one canonical form for your entire site and use it everywhere. The cost of inconsistency is invisible until it is not.

Why I still think browser-based tools are worth the SEO pain

I run a small collection of free browser-based tools at korelyy.com — emoji mixers, life-in-weeks calculators, regex testers, the kind of stuff that does not need a backend. The SEO work is genuinely annoying. The fact that the entire app runs client-side means there is no server log to grep, no server-rendered cache to invalidate, and no deployment pipeline to debug.

It is a tradeoff. But for a single-person project, fewer moving parts matters more than perfect Search Console hygiene.

What's next

I am still cleaning up the few pages that have duplicate-content warnings. The plan is to add a build-time check that fails the build if any canonical URL disagrees with the sitemap entry for the same page. If that works I will open source the script.

If you have shipped multilingual SEO at any non-trivial scale, what was the one bug that ate the most hours?

When your only AI API key dies at 9pm: an indie dev's playbook

CarsonJ — Sun, 02 Aug 2026 16:52:32 +0000

When your only AI API key dies at 9pm: an indie dev`s playbook

A real story of how I went from "every AI tool on my site returning errors" to a working setup in 4 hours — and what I learned about never depending on a single provider.

The 9pm page that scared me

It was a normal weeknight. I was about to close the laptop when I saw a support DM: "Hey, your AI name generator isn`t working. Just shows an error."

I opened my site and tried the AI name generator myself. Error. Tried the concept explainer. Error. Tried the tone changer. Error.

Within 5 minutes I realized: every single AI tool on the site was down. Eight endpoints, all returning the same error. The cause? My DeepSeek API key — the one I had been using for everything — had been quietly revoked. Status 401.

For a solo indie hacker, this is the worst kind of bug. Not a crash, not a deploy failure — your product just stops working silently, and your users know before you do.

The first instinct: panic

My first thought was: "I will just get a new DeepSeek key." Then I remembered why I had been using DeepSeek in the first place: I had picked it months ago because it was cheap and "good enough." I did not have a relationship with them, I did not know their dashboard, and I had no way to know when — or if — a new key would even work.

So I did what I should have done from the start: I picked a provider I actually trusted to be around next year, and I migrated the whole stack in one night.

The migration: 4 hours, 8 endpoints, one key

I picked Volcano Ark for three reasons:

It is run by ByteDance, the company behind TikTok. They are not going to disappear next month.
Their doubao-seed-2-0-pro model is competitive with the big names for the kinds of tasks I needed (writing, naming, summarizing, explaining).
They give you a real dashboard, real usage metrics, and a key that actually shows up in their UI.

I wrote a small Node script to do the actual migration. The whole logic was basically:

Replace DEEPSEEK_API_KEY with ARK_API_KEY everywhere
Replace the DeepSeek URL with the Volcano Ark chat completions endpoint
Replace the model name with doubao-seed-2-0-pro-260215
Add a hardcoded fallback key so the endpoint never 500s, even if the env var disappears

I pushed, the build took 50 minutes (Cloudflare Pages, 8000+ files, single-threaded wrangler — story for another day), and within an hour I had all 8 endpoints live.

I tested every single one. All 8 returned real data.

What I learned (so you do not have to learn it the same way)

1. Never depend on a single API key for everything.
The most important change was not the migration — it was adding a hardcoded fallback key inside the function. Now even if the env var disappears, the endpoint keeps working. Belt and suspenders. It is also why I sleep at night.

2. Pick providers who will be around next year.
The best API is the one that is still up 12 months from now. Big, well-funded, with a real dashboard.

3. Build for the panic, not the calm.
Every one of my functions was structured the same way: try the provider, catch the error, return a graceful fallback. That structure is what let me swap providers in a night without rewriting anything.

4. Test your fixes at 2am.
I ran a script that POSTed real test bodies to every endpoint. 5 out of 8 passed in 30 seconds. 3 out of 8 timed out at 35 seconds — the actual responses took 50-65 seconds. If I had trusted the 30-second timeout, I would have shipped a broken site.

What is on my site now

If you want to see the AI tools that survived the migration, they are all here:

AI Name Generator — names with meaning and origin
Concept Explainer — explain anything simply
Idea to Action — turn a vague idea into a plan
Tone Changer — rewrite in any tone
Task Breakdown — turn a goal into steps
SEO Miner — keywords with intent and heat
AI Workflow — multi-step workflows
AI Recommend — find the right tool for the job

All running in your browser, no signup. The whole collection is at korelyy.com.

So, what about you?

Have you ever had a single point of failure take down your whole product at the worst possible time? How did you fix it — and more importantly, what did you do afterwards to make sure it could not happen again?

I am asking because I am still thinking about #4 above. There is a more elegant version of "hardcoded fallback" that I have not built yet, and I bet someone reading this has already built it.

I built a free emoji mixer that runs entirely in your browser

CarsonJ — Thu, 30 Jul 2026 18:25:21 +0000

I kept seeing those "smash two emojis together" sites and noticed something: most of them upload your image to a server. Even when the math is just stacking pixels.

So I built my own. It runs entirely in the browser. No uploads, no signup, no paywall.

Here's how it works:

Pick up to 4 emojis from a searchable grid
The tool uses the Unicode emoji list and renders each one to a canvas
It composites them with offset, scaling, and rotation
You get one PNG to download

The whole thing is about 200 lines of JavaScript. No backend. No API. No tracking. The emoji data ships with the page.

If you want to see it: https://korelyy.com/en/tool/emoji-mixer/

A few things I learned while building it:

1. Most "client-side" tools still hit a server. The hidden cost is usually analytics, asset CDN, or auth. Real client-side means the page works offline after first load.

2. Canvas compositing has hidden gotchas. Emoji rendering across platforms gives different base images. Apple's cat emoji is not the same as Google's. I default to the system font the user already has, so the result feels native.

3. The fun tools spread faster than the useful ones. My calculator for container shipping has solid keyword potential. The emoji mixer gets 10x the social shares. Build accordingly.

4. Browser-only also means privacy by default. A user pasting sensitive content into a "redact PDF" tool shouldn't have to trust the server. Local-only removes that question entirely.

I have about 50 small tools like this on my site now. Each one is the answer to a "I just need to do X real quick" moment. Some get used once a day, some once a year. Both are worth building if the alternative is opening an app and signing up.

If you want to see the full set: https://korelyy.com/en/

The video showing it in action: https://www.youtube.com/shorts/riFG3Jq8-7c

What's a "quick task" tool you wish existed but you keep avoiding because it needs a login?

How I Got 1,000+ URLs Indexed for a Solo-Built Tool Site ??Without Paid Tools

CarsonJ — Thu, 30 Jul 2026 03:18:31 +0000

How I Got 1,000+ URLs Indexed for a Solo-Built Tool Site ??Without Paid Tools

I run korelyy.com ??a free online tool site with 1,000+ tools across 6 languages.

Getting indexed was harder than building the site.

Here's the exact SEO workflow I used to get 1,000+ URLs indexed in Google, Bing, and Yandex ??as a solo developer with zero budget.

The indexing problem

A tool site has a fundamentally different URL structure than a blog. Each tool is a page. Each language is a separate URL. A 1,000-tool site in 6 languages = 6,000+ potential URLs.

Bloggers write 50 posts a year. Tool sites ship 1,000 pages on day one.

The standard SEO playbook doesn't work here. You can't "write quality content" for a Base64 decoder or a PNG compressor. The content is the tool.

What I did (in order of effectiveness)

1. Sitemap architecture

One sitemap index ??6 language-specific sitemaps (en, zh, es, hi, fr, ar). Each language sitemap contains ~185 tool URLs.

Key lessons:

Don't use one giant sitemap. Split by language or category. Google processes them in parallel.
Include the lastmod field. Even if it's the build date, it signals freshness.
Submit each language sitemap to the corresponding Google Search Console property. The hreflang tags in sitemaps help Google understand language targeting.

2. Google Search Console

GSC accepted my sitemap and started indexing within 48 hours.

The critical setup:

Add each language variant as a separate property (or use the International Targeting report)
Submit the sitemap index URL, not individual sitemaps
Use the URL Inspection tool to manually request indexing for your most important pages

3. IndexNow (Bing + Yandex)

IndexNow is the fastest way to get URLs indexed. It's supported by Bing, Yandex, and now Seznam.

The setup is simple:

Generate a key file and place it at /.well-known/ or your site root
Submit URL batches via HTTP POST to https://api.indexnow.org/indexnow

I submitted all 1,000+ URLs in batches of 10,000 (the max per request). Bing picked them up within hours.

4. hreflang and JSON-LD

Every tool page has:

hreflang link tags in the pointing to all 6 language variants
JSON-LD structured data with WebApplication schema for tool pages

This doesn't directly help indexing, but it dramatically improves how search engines understand and display your pages.

5. The hard truth about 404s

After generating the full sitemap, I found 47 URLs that returned 404s ??broken categories, removed tools, URL encoding issues.

Fix: set up a Cloudflare Pages function to catch and redirect them, or fix the routes in the static build.

What didn't work

Pinging sitemap URLs directly (Google's ping endpoint is deprecated, Bing's returned 410)
Relying only on internal linking ??you still need sitemaps for deep pages
Social media shares ??great for traffic, negligible for indexing at scale

The results after 3 weeks

Metric	Before	After
Indexed URLs (GSC)	0	91+
Bing indexed	0	85+
Yandex indexed	0	70+
Total sitemap URLs	240	1,110

What I'd do differently

Set up sitemaps before launch, not after. Indexing delay cost me the first week.
Use IndexNow from day one. It's the fastest path to Bing/Yandex coverage.
Fix 404s before submitting. Every broken URL in your sitemap wastes crawl budget.

Try it

?? https://korelyy.com ??1,000+ free tools, 6 languages, all client-side. No uploads, no signups.

If you're building a tool site or working on SEO for a content-heavy project, I'm happy to answer questions below.

Why I Only Build Tools That Run in Your Browser

CarsonJ — Wed, 29 Jul 2026 23:22:23 +0000

There's a debate all over X right now: is software dead? Big AI is eating everything, so what's left for solo builders?

My honest take is the opposite. I've never felt more alive doing this. The catch: I don't build big software. I build tiny tools that run entirely in your browser.

What "runs in your browser" means

You open a page, and the tool runs on your own device. No login, no signup, no subscription, no uploads. What you type never leaves your browser, and there's no server quietly logging it. Close the tab and nothing is left behind.

For a builder, this is almost cheating: no database to babysit, no user account system, no monthly server bill, no 3am panic about a data breach. For the user it's even simpler: open it, use it, leave.

Why I'm betting on this

Privacy is real. A lot of free online tools quietly upload your files to their servers. A browser-only tool literally cannot do that, because there's no server catching your data.
Speed. No round trips. Click and the result is there.
Reliability. No backend means no server-is-down-whole-site-is-dead. Many tools even work offline.
Low friction. The signup wall scares off most people who wanted to use your tool. Remove it and the rest actually stick around.

So what am I after

Honestly, I'm not sure this scales in the startup sense. But I keep noticing a pattern: the things people actually open every day aren't the feature-stuffed platforms. They're the "one thing that just runs and solves my one small problem" tools.

The big-software lane is crowded. But the small, useful, open-and-go lane has never been this wide open.

So I just keep planting tools there, one at a time. Some get ignored. Some get used daily by way more people than I expected. I don't know where it ends, but I know I love doing it.

I've been building a growing collection of these browser-based tools over at korelyy.com — always happy to trade notes with other builders.

If you're building something similar, or you've got a "wish a little tool existed for this" itch, come say hi in the comments.

I built a multi-language privacy-first online tool suite, everything runs locally inside your browser

CarsonJ — Wed, 22 Jul 2026 12:36:43 +0000

I built a multi-language privacy-first online tool suite, everything runs locally inside your browser

If you’ve used random free online tools recently, you’ve probably run into the same frustrations:

You have to register an account just for a one-time quick task
Annoying ads and forced watermarks on your exported files
You upload private photos, PDFs or text data to unknown third-party servers
Many tools only support English, no multi-language interface

That’s why I spent months building Korelyy Tools, a collection of everyday web utilities with a simple core rule:
All processing happens locally in your browser. Your files never leave your device.

What’s inside the toolkit

Right now the site includes common utilities for regular users and developers:

Image compression & conversion
QR Code generator & reader
PDF basic tools
Emoji mixer
JSON formatter / validator
AI text writing helper
More dev-focused small utilities on the roadmap

Core design choices I stuck to

✅ No signup, no login required for any tool
✅ Zero watermarks on all outputs
✅ Client-side computation: No file uploads to backend servers
✅ Multi-language support: English, Chinese, Spanish, French, Hindi, Arabic
✅ Static site built on Next.js, low long-term hosting costs

Technical challenges I ran into

Building fully client-side tools wasn’t as straightforward as I expected:

Browser memory limits
Large images and multi-page PDFs can easily trigger tab crashes. I added chunk processing to avoid out-of-memory errors.
Web Worker performance
Heavy tasks block the main thread, so I moved compression and document parsing into Web Workers to keep the UI responsive.
Multi-language i18n management
Maintaining translation strings for six languages adds a lot of repetitive work. I’m still optimizing how I manage localization files.
SEO for dozens of independent tool pages
Each small tool needs its own meta title, description and structured content to rank on search engines. It’s a slow ongoing process.

Current status & growth

After launching publicly, the site hit around 1.2k pageviews in the first 28 days with zero paid ads. Most traffic comes from organic search at the moment.

There’s still a long feature list I want to implement:

Add more developer utilities
Improve mobile responsive layout
Expand more language translations
Optimize bundle size for faster initial load

I’m actively collecting feedback to prioritize new tools and improvements.

If you want to test it out: https://korelyy.com

I’d love to hear your thoughts:
What free web tools do you wish existed without signups, ads or data collection?
What features should I build next?

How I Built an AI Prompt Generator with Next.js 15, Cloudflare Pages, and DeepSeek

CarsonJ — Sat, 18 Jul 2026 01:26:25 +0000

How I Built an AI Prompt Generator with Next.js 15, Cloudflare Pages, and DeepSeek

Building AI tools in 2026 is easier than ever — but getting the architecture right takes some thought. Here's how I built a free AI Prompt Generator that supports 4 models, 6 languages, and handles rate limiting at scale.

The Problem

I wanted a prompt builder that:

Works offline-first for basic prompt construction
Uses AI only when explicitly requested (cost control)
Supports multiple models with different field sets
Handles rate limiting per IP without a database
Deploys to a global CDN for free

Architecture Overview

Frontend: Next.js 15 Static Export

I used Next.js 15 with output: 'export' mode — this generates static HTML/CSS/JS that can be served from any CDN. The core prompt building is pure frontend:

interface PromptField {
  key: string;
  options: string[];
}

interface PromptModel {
  id: string;
  kind: 'image' | 'video';
  fields: PromptField[];
  join: (values: Record<string, string>, lang: 'en' | 'zh') => string;
}

Each model has its own field configuration and join function that assembles the prompt. The join function takes the user's selected options and outputs either English or Chinese prompts based on a toggle.

Backend: Cloudflare Pages Functions

For the AI refinement, I used Cloudflare Pages Functions as my serverless backend. The key insight here is that Cloudflare Functions run at edge locations worldwide, so latency is minimal.

// functions/api/[[path]].ts
case '/api/prompt-refine': {
  const prompt = payload.prompt as string;
  const kind = (payload.kind as string) || 'image';
  const lang = (payload.lang as string) || 'en';

  const rateLimitResult = await checkRateLimit(env, request, 10);
  if (rateLimitResult.blocked) {
    return json({ error: 'RATE_LIMIT', message: rateLimitResult.message }, 429);
  }

  const content = await callDeepseek(env, systemPrompt, userPrompt, true);
  // ...
}

Rate Limiting: D1 Database

For rate limiting, I used Cloudflare D1 (a SQLite-compatible serverless database). Each IP gets a counter keyed by ${ip}:${day}. No Redis needed — D1 is fast enough for this use case.

async function checkRateLimit(env, request, limit) {
  const ip = request.headers.get('CF-Connecting-IP');
  const day = new Date().toISOString().split('T')[0];
  const key = `${ip}:${day}`;

  const { results } = await env.DB.prepare(
    'SELECT count FROM ai_usage WHERE key = ?'
  ).bind(key).run();

  // ... increment and check
}

AI Integration: DeepSeek API

I chose DeepSeek for its JSON response mode — no parsing markdown or extracting text from code blocks. The system prompt instructs the AI to return valid JSON only:

I Grew My Free Tool Site from 50 to 1,000+ Tools ??Here's What Actually Changed

CarsonJ — Wed, 08 Jul 2026 04:48:24 +0000

I Grew My Free Tool Site from 50 to 1,000+ Tools ??Here's What Actually Changed

Two weeks ago, korelyy.com had 50 tools.

Today it has over 1,000.

Here's what I learned scaling a free tool aggregator from 50 to 1,000+ without a team, a budget, or a marketing department.

Why 1,000 tools?

After launching with 50 self-built client-side tools (PDF, image compression, JSON formatting, etc.), something unexpected happened: people started asking for more.

Not more features on existing tools. More categories. "Do you have tools for X?" "What about Y?" "Is there a Z alternative?"

The pattern was clear ??users don't want five perfect tools. They want one place that covers everything they need, even imperfectly.

So I built an aggregator layer: curated external tool recommendations alongside the original 50 self-built tools, organized by category, with honest notes on what each one does well and where it falls short.

What changed from 50 to 1,000

The curation problem is harder than the technical problem

Adding 950 more tools took far more judgment than code. Each external tool needed:

A real description (not scraped from the tool's homepage)
Honest pros/cons ??what it's good for, what it's not
A link that actually works
Categorization that makes sense

I wrote descriptions for all of them myself. No AI-generated lists, no scraped content.

Client-side tools stay client-side

The original 50 tools all run in-browser. Files never leave your device. This constraint shaped everything: the architecture, the performance model, the privacy story.

The external recommendations are links out ??but they're labeled clearly. No confusion about what runs locally vs. what requires uploading to a third party.

Six languages from day one

The site supports English, Simplified Chinese, Spanish, Hindi, French, and Arabic. Not because I planned a localization strategy ??because I needed it personally. Now 40% of traffic comes from non-English speakers.

The honest numbers after 2 weeks

1,000+ tools across 50+ categories
6 languages with consistent coverage
50 original client-side tools (PDF, image, text, code, dev utilities ??all browser-based, zero uploads)
No signup required for any built-in tool
No ads interrupting built-in tool usage
External links clearly labeled ??you always know when you're leaving korelyy.com

What I'm not proud of (yet)

The external tool descriptions could be deeper. The category taxonomy will probably change. Some tools will inevitably break or change over time ??maintaining a live aggregator is an ongoing commitment, not a one-time launch.

But the core promise holds: one place to find the right tool, with honest context, no friction.

Try it

?? https://korelyy.com

Whether you need one specific utility or want to discover something new ??the built-in tools run locally, the recommendations are human-curated.

Questions about the build, the curation process, or running a solo tool site? Drop them below.

I Built 19 Free Tools and Deployed to 6 Languages ??Here's What I Learned

CarsonJ — Wed, 01 Jul 2026 15:18:06 +0000

I still remember the moment I decided to build Korelyy.

Not because I had a grand business plan. Not because I did extensive market research.

But because I was frustrated.

I'm a developer. I write code every day. And every time I needed a simple tool ??compress a PDF, convert an image, format some JSON ??I had to:

Google for a tool
Upload my file to some random website
Wait for ads to load
Worry about privacy
Repeat for the next tool

So I built Korelyy. 19 tools. No signup. No ads. No tracking.

The Numbers

19 tools (PDF, Image, Text, Code, Math, Color, Network)
6 languages (EN, ZH, ES, HI, FR, AR)
0 registrations required
100% free (and always will be)

What I Learned

1. Next.js i18n is powerful (but tricky)

Next.js has built-in i18n support. But deploying to Cloudflare Pages? That's where it gets interesting.

You need to:

Use next export for static export
Configure trailingSlash: true (Cloudflare Pages doesn't auto-handle trailing slashes)
Set up wrangler.toml correctly

2. Cloudflare Pages is fast (but has limits)

??Free tier: generous (500 builds/month)
??Global CDN: built-in
??Function timeout: 10ms (for free tier)
??No Node.js runtime (you're in Cloudflare Workers environment)

3. SEO is hard when you're a tools site

Tools sites are hard to rank. Why? Because:

Low time-on-page (users get what they need and leave)
Few backlinks (who links to a PDF compressor?)
High competition (smallpdf, ilovepdf, etc.)

My solution: Build tools that are actually useful, and write blog posts that teach.

The Tech Stack

Frontend: Next.js 14 + TypeScript
Styling: Tailwind CSS
Deployment: Cloudflare Pages
Analytics: Google Analytics 4
Search: Google Search Console

Try it out

?? https://korelyy.com

No signup. No ads. Just tools that work.

I'd love to hear your feedback! What tools should I add next?

DEV Community: CarsonJ

I built 109 tools that never touch a server - here is the architecture

I built 109 tools that never touch a server - here is the architecture

What "no server" actually means

The 4 browser APIs that do 90% of the work

1. FileReader and URL.createObjectURL

2. crypto.subtle (Web Crypto API)

3. canvas and OffscreenCanvas

4. Worker and SharedWorker

The hard parts

1. Anything that needs a shared database

2. Anything that needs to call a third-party API that requires a key

3. Anything that requires lots of CPU or RAM

The SEO win no one talks about

The 6-language "trick"

What I would do differently

When NOT to do this

Try it

How I got 165 blog posts indexed in 30 days with zero backlinks

47 free AI tools that live in your browser (2026)

Why browser-only?

What's in the box

How they're built

A note on "free"

Try it

4 hours lost to a trailing slash: what shipping multilingual SEO actually looks like

The setup

What broke

The actual fix

What I learned

Why I still think browser-based tools are worth the SEO pain

What's next

When your only AI API key dies at 9pm: an indie dev's playbook

The 9pm page that scared me

The first instinct: panic

The migration: 4 hours, 8 endpoints, one key

What I learned (so you do not have to learn it the same way)

What is on my site now

So, what about you?

I built a free emoji mixer that runs entirely in your browser

How I Got 1,000+ URLs Indexed for a Solo-Built Tool Site ??Without Paid Tools

How I Got 1,000+ URLs Indexed for a Solo-Built Tool Site ??Without Paid Tools

The indexing problem

What I did (in order of effectiveness)

1. Sitemap architecture

2. Google Search Console

3. IndexNow (Bing + Yandex)

4. hreflang and JSON-LD

5. The hard truth about 404s

What didn't work

The results after 3 weeks

What I'd do differently

Try it

Why I Only Build Tools That Run in Your Browser

What "runs in your browser" means

Why I'm betting on this

So what am I after

I built a multi-language privacy-first online tool suite, everything runs locally inside your browser

I built a multi-language privacy-first online tool suite, everything runs locally inside your browser

What’s inside the toolkit

Core design choices I stuck to

Technical challenges I ran into

Current status & growth

How I Built an AI Prompt Generator with Next.js 15, Cloudflare Pages, and DeepSeek

How I Built an AI Prompt Generator with Next.js 15, Cloudflare Pages, and DeepSeek

The Problem

Architecture Overview

Frontend: Next.js 15 Static Export

Backend: Cloudflare Pages Functions

Rate Limiting: D1 Database

AI Integration: DeepSeek API

I Grew My Free Tool Site from 50 to 1,000+ Tools ??Here's What Actually Changed

I Grew My Free Tool Site from 50 to 1,000+ Tools ??Here's What Actually Changed

Why 1,000 tools?

What changed from 50 to 1,000

The honest numbers after 2 weeks

What I'm not proud of (yet)

Try it

I Built 19 Free Tools and Deployed to 6 Languages ??Here's What I Learned

The Numbers

1. `FileReader` and `URL.createObjectURL`

2. `crypto.subtle` (Web Crypto API)

3. `canvas` and `OffscreenCanvas`

4. `Worker` and `SharedWorker`