DEV Community: Indie Maker

Free tiers die quietly — so I verify every link in my directory, every week

Indie Maker — Tue, 20 Oct 2026 03:36:18 +0000

Every "free stuff" directory on the internet has the same disease: rot. A free tier gets quietly shrunk, a startup sunsets its free plan, a landing page starts redirecting to a pricing page — and the directory keeps cheerfully sending people to a deal that no longer exists. Half the links in most directories are lying to you; they just don't know it yet.

I know because I built one of these directories, and keeping it honest turned out to be the entire job. Collecting the links took a weekend. Verifying them forever is the product.

The verification loop

Every entry in my directory gets re-checked automatically once a week. The checker follows each outbound link and looks for the obvious failure modes: the page is gone, the domain is parked, the "free" plan now requires a credit card, the offer text changed beyond recognition.

Two design decisions mattered more than the checker itself:

Show the check date on every card. Each listing displays when it was last verified — "Checked Oct 12, 2026" — right on the card. A directory that hides its freshness is asking for trust it hasn't earned. If a check is stale, the user can see that and discount accordingly.

Don't delete on the first failure. Sites throw 403s at bots and redirect chains break for innocent reasons. My rule: a failed check flags the entry for review; repeated failures across consecutive weeks get it pulled. One strike is a warning, not a verdict. I've manually re-checked flagged entries and found plenty of false alarms — bot protection doing its job, not a dead offer.

The honesty rules

A directory of free things lives or dies on whether people believe the word "free". So the rules are strict:

Official offers only. Free products and official free tiers from the provider itself. No pirated streams, no keygens, no "free" download sites. If it's not on the provider's own site, it's not listed.
Paid promos are labeled paid. During Black Friday season I run a deals category — and every paid deal in it is marked PAID in plain sight, with its end date. Mixing paid deals into "free" listings without labels is how directories sell out their users.
Credit-card-required gets said out loud. A "free tier" that demands a card upfront is a trial in a trench coat. It's still listable if it's genuinely useful — but the card requirement goes in the listing, not in fine print.

What I actually spend time on

People assume a directory is a content problem: write more listings. It isn't. The weekly work is janitorial — re-checking flags, confirming a tier really died before pulling it, replacing a dead offer with a live alternative. The list stays around 270 entries not because I can't find more "free" things, but because that's what I can keep verified.

The flip side is that verification is a moat a scraped directory can't copy. Anyone can export 5,000 links. Almost nobody re-checks them.

The directory is FreeHub (https://free.toppn.com/) — 269 freebies across VPS & cloud, hosting, storage, domains & SSL, VPN, streaming, and dev tools, every one re-checked weekly with the date shown. If you rely on a free tier I haven't listed — or you've spotted one of my listings going stale — I genuinely want to hear about it. Keeping the list honest is a group project.

A financial calculator is only as good as its formula

Indie Maker — Mon, 19 Oct 2026 09:19:18 +0000

Online financial calculators have a trust problem. You type in your numbers, a monthly payment appears, and you have no idea what math produced it. Was that mortgage calc using monthly or semi-annual compounding? Does the tax calculator include state tax? Which year's brackets? Usually, you can't tell — the formula is hidden.

I think the fix is embarrassingly simple: publish the formula. Here's what that looks like in practice, from building a set of financial calculators.

Show the math on the page

Every calculator should display the actual formula it uses, with the variables labeled. For compound interest, that's A = P(1 + r/n)^(nt) — and then define each symbol in plain language. This does two things: users can verify the result by hand, and other developers can spot your mistakes. Both have happened to me, and both made the tool better.

State your assumptions explicitly

A mortgage calculator isn't just a formula — it's a stack of assumptions: compounding frequency, whether property tax and insurance are included, how extra payments are applied. List them next to the result. The calculators people trust most are the ones that say "here's what I assumed" instead of pretending there's one true answer.

Run it client-side

Financial numbers are sensitive. Running the calculation entirely in the browser means the numbers never leave the user's device — there's no server log of someone's salary or mortgage balance to leak. As a bonus, results update instantly as you type, which makes the tool feel dramatically better.

Test against known values

Before shipping, verify each calculator against authoritative sources: IRS tax tables for the income tax calc, bank-published amortization examples for mortgages. Write these as actual test cases, not eyeball checks. One wrong assumption in a refinance calculator can cost a real person real money.

Write guides, not just inputs

Most people don't know what "points" or "PMI" mean. A short plain-English explanation next to each input turns a calculator from a black box into a learning tool — and it's what separates a useful page from a commodity widget.

I applied all of this building CalcWise (https://finance.toppn.com/) — 9 free financial calculators covering compound interest, mortgage, refinance, credit-card payoff, retirement, investing, income tax, ROI and profit margin. Formulas published, everything runs locally in the browser, no sign-up. The most valuable feedback I've gotten wasn't feature requests — it was people checking my math. That's exactly the dynamic you want.

I was sick of subscriptions for basic PDF tasks, so I built a pay-per-use toolbox

Indie Maker — Sun, 18 Oct 2026 07:44:07 +0000

I merge PDFs maybe twice a month. Split one occasionally. Compress one when Gmail complains it's too big.

For this, my options were:

Adobe Acrobat — a monthly subscription, for something I do twice a month.
"Free" online tools — plastered with ads, capped at 2 tasks a day unless you pay, and who knows where your files go.
A desktop app from 2009 — you know the one.

None of these felt right, so I built the thing I actually wanted: PDF Toolbox.

What it does: merge, split, compress, plus Word / PPT / Excel → PDF. Six tools, that's it. No editor, no e-sign, no "AI-powered" anything — the boring stuff, done well.

How it's priced: no subscription. You buy credits, they never expire. Use 3 this month and 0 the next — you pay nothing in between. First 3 conversions are free, no account needed. Files auto-delete after 2 days (it's a toolbox, not a storage service).

Why pay-per-use? Honestly, this is the experiment. Subscriptions are great for the vendor and terrible for the twice-a-month user. Ad-supported "free" means you're the product and your PDFs are training data. Credits felt like the honest middle: you pay for exactly what you use, nothing else.

The part I'm still unsure about: do people actually want this, or does everyone just expect PDF tools to be free? I've watched too many indie makers (myself included) build something reasonable and discover the market's answer is "cool, but I'd rather watch ads."

So here's my ask: try the 3 free conversions, and tell me straight — would you ever pay per use for this, or is PDF tooling a race to free that nobody wins?

I got tired of "can you see my screen?" so I built a shared reading room for documents

Indie Maker — Sun, 18 Oct 2026 05:30:19 +0000

Every document review I've ever been part of goes like this: someone shares their screen, the PDF is too small to read, they scroll while you're still on page two, and half the meeting is "can you see my screen? …how about now?"

I kept thinking: why are we all staring at one person's screen, when the document itself could be the shared space?

So I built SyncPage (https://syncpage.app). The idea is simple: every document gets its own room. You upload a PDF, a deck, a spreadsheet — everyone opens the same document in their own browser, and you can see each other's cursors and annotations live. The presenter can pull everyone to the page they're on, or people can wander off and read independently, then snap back with one click. Voice is built in, so you don't need a separate call running alongside.

A few things I was deliberate about:

1. Guests don't need an account. You send a link, they click, they're in the room. Every signup wall I removed increased the odds someone would actually show up to the review.

2. It handles real office documents, not just PDFs. Word, PowerPoint, Excel — the stuff people actually review — with annotations that stick to the document.

3. Presenter sync and independent reading. Most tools pick one: either everyone's locked to the presenter's screen, or everyone's on their own and nobody knows which page you're talking about. We do both — follow the presenter, or break away and rejoin whenever you want.

It's a small bootstrapped team (five of us) and very much a work in progress. Web, Windows, and Android are out; macOS and iOS are next.

If you do document reviews with a team — or if you've ever sat through the "can you see my screen" dance — I'd love to hear how you handle it, and what you'd want from a tool like this.

I got tired of "free tools" lists full of dead links, so I built one that checks itself every week

Indie Maker — Thu, 08 Oct 2026 05:09:25 +0000

Every few months I go looking for a free tier of something — a VPS to host a side project, an API with a generous free plan, a free font for a landing page. And every time, the same thing happens: I open one of those "100+ free tools" listicles, click the third link, and land on a pricing page that killed its free tier two years ago. Or a domain that's now parked.

The lists aren't malicious. They just rot. Nobody goes back to re-check 100 links.

So I built the thing I kept wishing existed: a directory of legitimate freebies where every outbound link is re-verified automatically, every single week. Dead, paywalled, or quietly-changed offers get flagged and removed. New additions only go live after manual verification.

It's called FreeHub — https://free.toppn.com/

Right now it tracks 258 free products and free tiers across 7 categories:

Free VPS & cloud servers (Oracle Cloud's always-free tier, etc.)
Free web & app hosting
Free cloud storage
Free streaming (100% licensed — no piracy, no risk)
Free domains, SSL & CDN
Free VPN & privacy tools (only trustworthy ones — no shady "free" VPNs)
Free dev & AI tools (GPUs, repos, APIs, design)

A few things I was deliberate about:

1. Facts over marketing copy. Each listing shows the actual free tier (not "free!" with the asterisk doing heavy lifting), plus limits and how to claim it. If a free tier needs a credit card for verification, it says so.

2. No paid rankings. It's a directory, not an affiliate farm. Placement isn't for sale.

3. It stays fresh by design, not by discipline. The weekly check is automated — I don't have to remember to do it, which means it actually happens.

It's a side project and very much a work in progress. If you know a legitimate free tier that's missing, or spot a dead link I missed, I'd genuinely love to hear about it in the comments.

https://free.toppn.com/

14 Tools, Zero Servers: How I Built a Whole Utility Belt That Runs 100% in Your Browser

Indie Maker — Mon, 05 Oct 2026 13:48:42 +0000

This is part 2 of my browser-local tools series. In part 1 I argued that your files don't need to leave the device. This time, the full tour: 14 utilities I shipped that run 100% in the browser — each with the 30-second "how it actually works" for fellow devs. If you code, steal these patterns. If you don't, just bookmark the tools.

The whole collection lives at Quick Toolbox — free, no sign-up, and every tool works offline after the first load. Here's what's inside.

🖼️ Image tools: the Canvas API does all the heavy lifting

Image Compressor — Shrink JPG/PNG/WebP photos before sending them anywhere. Under the hood it's three lines of real work: createImageBitmap(file) to decode, drawImage() onto a canvas at the target size, then canvas.toBlob(callback, 'image/jpeg', quality) where the quality slider maps straight to that third argument. A 4MB phone photo becomes ~300KB at quality 0.8 with no visible difference.

Image Converter — Same pipeline, different MIME type. JPG ↔ PNG ↔ WebP, which covers 99% of real-world needs. The trick most people miss: converting PNG screenshots to WebP typically cuts 60–80% of the bytes.

Image Resizer — Set exact pixel dimensions or scale by percentage, with aspect-ratio lock so nothing gets stretched. Also lets you switch output format in the same pass — resize and convert in one click.

📄 PDF tools: yes, entirely in the browser

PDF Merger and PDF Splitter — The flow: FileReader → ArrayBuffer → a PDF library running in the page → copyPages() into a new document → save → trigger download. No server ever sees the bytes. This is the one I care about most: contracts, ID scans, bank statements — the exact documents you should never upload to a random "free PDF tool" site.

⌨️ Text & dev tools

JSON Formatter & Validator — JSON.parse() in a try/catch; on failure it maps the character offset from the error message back to a line and column so you see exactly where the trailing comma is. Beautify, minify, one click each.

Base64 Encode & Decode — The classic pitfall: btoa() throws on anything outside Latin-1. The fix is TextEncoder → bytes → btoa(String.fromCharCode(...bytes)), and the reverse with TextDecoder on decode. Full Unicode support, which half the online converters get wrong.

Timestamp Converter — Paste 1690000000 or 1690000000000, it figures out seconds vs. milliseconds with a magnitude heuristic and converts to readable date/time (Beijing Time included). Every backend dev has needed this at 2am.

Password Generator — Custom length and character sets, built on crypto.getRandomValues() — never Math.random() for anything security-adjacent. Generated locally, so the password literally never exists anywhere but your machine.

UUID Generator — crypto.randomUUID() in a loop, bulk-generate and copy them all with one click. Boring, essential.

QR Code Generator — A QR encoding library running in JS renders to <canvas>, and you download the PNG. Text, URLs, Wi-Fi credentials — handy for sharing a link from desktop to phone.

Word Counter — Handles mixed-language text (English words + CJK characters counted sensibly) and estimates reading time. Writers and translators use this daily.

Case Converter — UPPERCASE, lowercase, Title Case, camelCase, snake_case — regex transforms, one click. The kind of thing you need twelve times a day.

Color Converter — HEX ↔ RGB ↔ HSL with a live picker preview. Front-end devs: stop Googling "hex to rgb" forever.

Same philosophy, money edition: CalcWise

I applied the same "runs locally, nothing uploaded" idea to personal finance. CalcWise is a set of financial calculators — mortgage, compound interest, retirement planning, ROI — each paired with a plain-English guide that explains the math instead of just spitting out a number. Your salary numbers stay in your browser, where they belong.

And a directory of actually-free stuff: FreeHub

While building these I kept running into "free" tools with gotchas, so I started FreeHub — a directory of verified free tiers and deals: VPS hosts, cloud storage, domains, streaming, dev tools. Every entry is checked against the official site; anything that shut down or paywalled gets removed. If you're hunting for free infrastructure for your side project, start there.

What's next

Everything above is free, no account, no tracking of what you do with the tools. The pattern behind all of it is simple: if the browser can do it — and in 2026 it can do a lot — there's no reason to involve a server.

What utility do you wish existed as a zero-server browser tool? Drop it in the comments — the most-requested one gets built next. 👇

Your files don't need to leave the device: building browser-local tools

Indie Maker — Thu, 01 Oct 2026 05:22:34 +0000

Most "free online tools" work like this: you upload your file to a server, it does the work, you download the result. For many tasks, that round trip is pointless — your browser can do the whole job locally, faster and more privately.

I learned this building a small toolbox of utilities, and the pattern is simpler than people expect. Here's the playbook.

Reading files without uploading. The File API gives you everything: an <input type="file"> plus URL.createObjectURL() lets you work with the file entirely in memory. No fetch, no FormData, no server involved at all.

Images: canvas does the heavy lifting. Compression and format conversion are just drawImage into a canvas followed by canvas.toBlob() with a quality setting, or toDataURL('image/webp') for conversion. Resizing is the same pipeline. The browser's image decoders are excellent — you get quality comparable to server-side tools for the common cases.

PDFs: real libraries run in the browser now. pdf-lib can merge and split PDFs purely client-side; pdf.js renders previews. These are the same libraries server tools use, just bundled for the browser. The main gotcha is memory: a 200MB PDF will hurt on a low-end phone, so process in chunks where you can and warn the user before tackling huge files.

Text and dev utilities are trivially local. JSON formatting, Base64, UUIDs, hashing, QR codes — all pure functions. There's never a reason for these to touch a network.

The architecture payoff. With zero backend, the whole thing is a static site. Hosting costs next to nothing, there are no servers to scale, and the privacy story writes itself: files never leave the device because there's nowhere for them to go. That's not a marketing line — it's a structural guarantee.

What to watch out for. Mobile Safari has quirks around large blobs and downloads; always test the download step (a[download] + object URL) on real devices. And be honest about limits: browser-local can't do OCR well or handle truly massive files — say so in the UI instead of failing mysteriously.

I put this approach into practice with Quick Toolbox (https://tools.toppn.com/) — 14 free utilities, all client-side, no sign-up. If you're building tools like these, start local-first and only add a server when the browser genuinely can't do the job.