DEV Community: Aniket Saini

QuietBench: A Free Developer Utility Suite I Built Solo (No Ads, No Sign-Up, No BS)

Aniket Saini — Sat, 11 Jul 2026 14:52:09 +0000

What I Built

QuietBench (quietbench.dev) is a free suite of everyday developer utilities — the kind of tools you Google at 2am when you're stuck on something small but annoying:

JSON Formatter — format, validate, and minify JSON instantly
Regex Tester — test patterns with live match highlighting
Cron Builder — build and understand cron expressions without memorizing syntax
WCAG Contrast Checker — check color contrast ratios for accessibility compliance
API Request Tester — send requests and inspect responses without opening Postman

No accounts. No paywalls. No cookie-consent maze. Just open the tab, do the thing, close the tab.

Why I Built It

I kept bouncing between five different single-purpose tool sites every time I needed to format JSON or test a regex — each with its own ad-heavy layout, weird UX, and a sign-up wall for "advanced" features I didn't need. I wanted one clean, fast place for the tools I reach for constantly. So I built it.

Tech Stack

React + Vite + TypeScript for the frontend
Tailwind CSS for styling
Cloudflare Pages for hosting
Porkbun for the domain

The whole thing is a static SPA, deployed with a single command:

npm run deploy

which runs the Vite build, prerenders every route, and pushes to Cloudflare via Wrangler.

Challenges I Ran Into

A CSP regression that tanked my LCP score
I tightened my Content Security Policy for safety and accidentally forgot to allowlist Google Fonts. Page load time (LCP) spiked overnight. Lesson: every CSP change needs a Lighthouse re-check, not just a "looks fine" glance.
SPAs and crawlers don't get along
Since QuietBench is a client-rendered SPA, non-JS crawlers (and some bots) were seeing an empty shell instead of actual content. I fixed this with build-time prerendering using Playwright — every one of the 11 routes now gets a fully-rendered HTML snapshot generated at build time, so crawlers see real content without needing to execute JS.
Getting indexed without SEO gimmicks
Rather than chasing broad, competitive keywords, I focused on long-tail, exact-match queries — specific error messages, exact syntax terms, the kind of thing someone pastes directly into Google when they're stuck. I also set up IndexNow for instant Bing submission on every deploy, so new content doesn't sit around waiting to be crawled.
The little things that break silently
A www/non-www redirect inconsistency was quietly splitting my traffic and confusing search engines — fixed with a Cloudflare Redirect Rule. Small, boring, but it matters for SEO hygiene.

What's Next

Two more long-tail content pages, currently paused while I read Search Console data to make sure I'm building the right pages, not just more pages
Continued distribution — dev.to has been the most genuinely engaged channel so far
More utilities based on what I personally keep needing

Try It

👉 quietbench.dev

It's free, it's fast, and it doesn't ask you for your email. Would genuinely love feedback from other devs — especially if a tool is missing something you'd expect, or if you spot a bug.

Building this solo, learning SEO and infra as I go. If you're into indie dev tools or want to swap notes on prerendering/IndexNow setups, drop a comment — happy to share specifics.

RivalryFuel: AI Hype Commentary for Any Rivalry

Aniket Saini — Fri, 10 Jul 2026 11:00:06 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

RivalryFuel — an AI-powered hype commentary generator that turns any rivalry into a dramatic, stadium-announcer-style speech. Pick two sides (sports teams, tech stacks, even Tea vs Coffee), hit generate, and Gemini writes a passionate, biased commentary — then ElevenLabs brings it to life with a real announcer voice.

With the World Cup happening right now, passion for rivalries is everywhere — in stadiums, group chats, comment sections. RivalryFuel captures that same chaotic, biased energy in a 30-second, shareable format. My goal was to build something that felt genuinely fun to click "generate" on more than once.

Demo

🔗 Live App: https://rivalryfuel-686994035117.asia-southeast1.run.app

🎥 Video Demo: https://youtu.be/imMa8FMHlck

Try it yourself — click a preset like "Messi vs Ronaldo," hit Generate Commentary, then hit "Listen to Column" to hear it out loud.

How I Built It

The app is built with React + TypeScript + Vite + Tailwind CSS, deployed on Google Cloud Run.

Gemini 2.0 Flash powers the core hype generation — I engineered the prompt to keep responses playful, biased toward the chosen side, and dramatically "shouted into a stadium mic" rather than neutral or robotic. Getting the tone right took a few iterations of prompt tweaking.

ElevenLabs handles the text-to-speech layer — the generated commentary is sent to ElevenLabs' API and played back in-browser as a stadium-announcer voice, turning static text into something that actually feels alive.

One fun challenge: I hit Gemini's free-tier rate limit mid-build and had to switch API keys/projects to keep testing — a good reminder that even small demo apps need quota planning. I also had a UI bug where longer names like "Cristiano Ronaldo" were clipping on smaller screens, fixed with responsive flex layouts and dynamic font scaling.

Prize Categories

Submitting for:

🏆 Best Use of Google AI — Gemini 2.0 Flash generates all commentary in real time with custom prompt engineering for tone and bias
🏆 Best Use of ElevenLabs — Real-time text-to-speech converts generated commentary into an actual audible stadium-announcer moment

Thanks for putting together another fun challenge — built this solo over the weekend! Would love to hear what rivalry you'd want to see hyped up next 🔥

weekendchallenge

What actually happens when you launch a side project with zero audience

Aniket Saini — Thu, 09 Jul 2026 03:09:10 +0000

Everyone talks about the build. Nobody talks about what happens the week after, when you go to actually tell people it exists and discover every distribution channel has its own quiet gatekeeping you didn't know about until you hit it.

Hacker News flagged my Show HN before it ever reached the front page. Not rejected — flagged, silently, likely because the account posting it was brand new with a self-promotional link and zero history. No warning, no explanation, just gone from /newest for anyone not specifically looking.

Reddit was worse in a different way. r/webdev's AutoMod rejects any submission from an account under three months old with low karma — a hard gate, not a soft one, and it doesn't care which day you post or how you phrase it. r/SideProject let the post through technically, but Reddit's own spam filter quietly removed it minutes later, invisible to everyone except me looking at my own profile.

X was just silence. Zero followers means the algorithm has no graph to push the post into. Four views, three of which were probably me refreshing.

The one channel that actually worked was the one with the lowest bar to entry: writing. dev.to doesn't gate you behind account age or karma. You write something, it's live, and if it's genuinely useful, people find it — slowly, but for real. That's where actual engagement happened.

The pattern underneath all of this: almost every high-leverage distribution channel is, by design, hostile to accounts with no history. That's not a bug — it's the exact mechanism that keeps those platforms usable, and it exists specifically to stop people doing exactly what I was trying to do: show up once with a link and leave. The system is working as intended. It just doesn't feel that way when you're the one hitting the wall.

What's actually working, three weeks in, isn't a growth hack — it's writing things people search for, verbatim, and being patient about everything else building account history the boring way: showing up, commenting on other people's stuff, and not trying to skip the line.

If you're about to launch something with a brand-new account everywhere, budget for this. It's not a failure state, it's just how the first few weeks go.

Securing Your CI/CD Pipeline from Day One: A Practical Guide

Aniket Saini — Wed, 08 Jul 2026 14:39:13 +0000

**Outline: Securing Your CI/CD Pipeline from Day One

Introduction: The "Shift-Left" Mindset** The Hook: Start with a brief explanation of why waiting until production to check for security vulnerabilities is a recipe for disaster.

The Solution: Introduce the concept of DevSecOps and "shifting left"—bringing security into the earliest stages of the software development lifecycle.

What We're Building: Briefly outline the architecture: A Python Flask application, containerized with Docker, moving through a Jenkins pipeline that automatically halts if critical vulnerabilities are detected by Snyk or Trivy.

2. The Prerequisites
Provide a quick checklist for readers who want to follow along:

A basic Python Flask application pushed to a Git repository.

A working Jenkins server.

Docker installed on the Jenkins agent.

A free Snyk account (for the API token) and Trivy installed on the pipeline environment.

3. Stage 1: Dependency Scanning with Snyk (SAST)
The Concept: Explain that modern apps are mostly made of open-source libraries. Snyk scans the requirements.txt file of the Flask app to find known vulnerabilities (CVEs) in those dependencies.

Pipeline Integration: Show how to add Snyk into the Jenkinsfile.

Key Takeaway: Explain the importance of failing the build only on high or critical severity issues to avoid pipeline fatigue.

4. Stage 2: Container Image Scanning with Trivy
The Concept: Once the application code passes, it gets built into a Docker image. Trivy steps in here to scan the underlying OS packages and base image (e.g., python:3.9-slim) for vulnerabilities.

Pipeline Integration: Walk through the shell commands used in Jenkins to trigger Trivy against the newly built local image before it gets pushed to a registry.

Why Both? Briefly clarify why you need both tools: Snyk for the application layer (Python dependencies) and Trivy for the infrastructure layer (the container itself).

The Jenkinsfile (The Heart of the Article) Provide a clean, well-commented declarative pipeline snippet. This is what your readers are really here for.

Groovy
pipeline {
agent any
stages {
stage('Checkout') {
// Git checkout steps
}
stage('Security Scan: Snyk') {
// Snyk testing steps for Python
}
stage('Build Image') {
// Docker build steps
}
stage('Container Scan: Trivy') {
// Trivy scanning steps
}
}
}
6. Conclusion & Next Steps
Wrap up by summarizing how this automated approach saves time and prevents compromised code from reaching production.

Encourage readers to try implementing this in their own homelabs or side projects.

This structure balances theoretical concepts with the practical, code-heavy execution that the DEV Community loves.

What my first week of Google Search Console data taught me about SEO for a new site

Aniket Saini — Tue, 07 Jul 2026 05:34:32 +0000

I assumed getting indexed was the hard part. It wasn't — Quietbench got crawled and indexed within days. What the first week of impression data actually taught me was something more specific: which kind of page a brand-new domain can realistically rank for, and which it can't yet.

The main tool pages got zero impressions. /json-formatter, /regex-tester, /api-tester — nothing. Makes sense in hindsight: "JSON formatter" is a query owned by sites with a decade of backlinks and authority. A new domain isn't out-competing that anytime soon, no matter how good the tool is.

The long-tail supporting pages got almost all of the traction. Pages like /regex-tester/cheat-sheet and /cron-builder/syntax-explained picked up impressions almost immediately, for queries like "cron syntax" and "website contrast checker" — specific, lower-competition phrases with far less entrenched competition.

The clearest signal came from one page that got zero impressions despite being indexed. I'd written a /api-tester/what-is-cors page targeting the query "what is CORS" — a broad, heavily-answered question already owned by MDN, web.dev, and freeCodeCamp. Meanwhile, the page's own content had the exact console error text buried in a sub-section: "No 'Access-Control-Allow-Origin' header is present...". That's the actual thing someone in a debugging session searches for, verbatim, not a definitional question. Restructuring the page to lead with that error message instead of the broad definition was a one-line insight that took a week of data to actually see.

The pattern, stated plainly: a new domain can't compete on definitional or generic queries yet, no matter the content quality. It can compete on specific, verbatim, low-competition phrasing almost immediately — error messages, exact syntax terms, comparison phrases. If you're building a new site's content strategy, the frustrating console error your users paste into Google is worth more, right now, than the polished "what is X" page you were probably planning to write first.

Following that data, not a guess, is doing more for the site's early SEO than anything I planned upfront.

Adding a Content Security Policy to a static SPA without breaking anything

Aniket Saini — Mon, 06 Jul 2026 02:59:39 +0000

Quietbench started from a scaffolded template that shipped with zero security headers. Adding them properly was less about writing the policy and more about not breaking the one tool that needs to stay permissive.

The easy part: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a sane Referrer-Policy — free wins, nothing depends on being frameable.

The tricky part: the site has an API tester that needs to fetch() arbitrary user-supplied URLs. A locked-down connect-src 'self' would've quietly broken it. Fix was leaving connect-src * intentionally open while keeping everything else tight — script-src 'self', frame-ancestors 'none'. A CSP doesn't need to be uniformly strict, just strict where it matters for your app.

The gotcha: vite dev doesn't read the _headers file at all, so testing against the regular dev server tells you nothing about whether the CSP will actually apply. Cloudflare Pages reads _headers at deploy time — the only way to test that locally is running the build through wrangler pages dev dist, which mirrors production behavior. Skip that and you're shipping headers you never actually verified.

Also cleaned up @google/genai and express - leftover scaffold dependencies nothing imported. Not vulnerabilities, just unaudited surface for zero benefit. Dropped 121 packages.

Live at quietbench.dev if you want to check the headers yourself.

What building a contrast checker taught me about WCAG that I had wrong

Aniket Saini — Sun, 05 Jul 2026 02:30:23 +0000

I assumed the WCAG contrast checker for Quietbench would be the simplest tool in the suite — compute a ratio, compare it to a threshold, done. A few things surprised me enough to change how I think about accessibility in my own projects.

"Passing AA" isn't one number. The 4.5:1 ratio everyone quotes only applies to normal text. Large text (18pt+, or 14pt+ bold) only needs 3:1. UI components and graphical objects have their own 3:1 threshold under WCAG 2.1's non-text contrast rule. A tool that only checks one ratio against one threshold is giving wrong answers for half the content on a real page.

AAA isn't just "AA but stricter" in the way I assumed. AAA bumps normal text to 7:1, but the large-text threshold only moves to 4.5:1 — not a flat multiplier. Building the "suggest a fix" feature meant handling these as genuinely different target ratios per content type, not one formula scaled up.

The relative luminance formula is not intuitive. WCAG doesn't compare RGB values directly — it converts to relative luminance first, which weights green far more heavily than red or blue in how humans perceive brightness. Two colors that look similarly "light" or "dark" to the eye can have meaningfully different contrast ratios against the same background, which is exactly why eyeballing contrast doesn't work and a checker is worth having.

Most "suggest a fix" tools I looked at just darken or lighten until they hit the threshold, ignoring the original hue. That technically passes WCAG but can produce a color that no longer matches the brand or design intent. I ended up preserving hue and adjusting lightness within the same color family first, only shifting saturation as a fallback if that alone couldn't reach the target ratio.

None of this is exotic once you know it, but I'd been treating "contrast checking" as basically solved logic before actually building one. It isn't — it's a small pile of specific rules that don't generalize the way intuition suggests.

Live at quietbench.dev/contrast-checker if you want to check your own palette against it.

The 3 mobile bugs that took longer to fix than the entire desktop version

Aniket Saini — Sat, 04 Jul 2026 04:53:24 +0000

Building the API request tester for Quietbench, the desktop version came together fast — headers, body, response view, done. Mobile is where I actually lost time.

The CORS warning banner. On desktop, a dismissible banner explaining a blocked request has plenty of room. On a narrow viewport, it either pushed the actual response out of view or got truncated into something unreadable.
Fix was less about styling and more about rethinking the banner as collapsible-by-default on small screens, expandable on tap — not just shrinking the same layout down.
The URL input row. Method dropdown + URL field + Send button in one row is fine until the viewport gets narrow enough that the URL field shrinks to a few visible characters. Testing a real API URL when you can see 8 characters of it is useless.
Ended up stacking the method selector above the URL field on small screens instead of forcing everything into one row no matter what.
The Send button itself. Small thing, but on mobile it kept ending up either off-screen when the keyboard was open, or too close to other tap targets to hit reliably.
Pinning it above the keyboard and giving it more breathing room from neighboring elements fixed more "why isn't this working" confusion than any logic bug did.

None of these are hard problems individually. What actually cost time was assuming "responsive" meant "the same layout, smaller" — it doesn't.
Each of these needed an actual layout decision for narrow screens, not just a breakpoint that shrinks things proportionally.

Live at quietbench.dev/api-tester if you want to try it on your phone — genuinely curious if anything's still awkward.

Why I ripped out a cron parsing library and wrote my own

Aniket Saini — Fri, 03 Jul 2026 04:13:27 +0000

Building the cron builder for Quietbench, I started with an npm package for parsing and calculating next-run times. Get it working, move on. That lasted about a week.

The problem: the library handled standard cron fine, but broke on real edge cases — conditional OR/AND behavior when day-of-week and day-of-month are combined, step values inside ranges (1-10/2), and off-by-one errors around DST transitions. When I checked its output against standard cron engines, the mismatches showed up fast.

Why not patch it: the parsing and "next run time" logic were tightly coupled internally. Fixing one edge case risked breaking another. Writing something scoped to exactly what I needed was less work than fighting someone else's abstraction.

The rewrite keeps three things cleanly separate: tokenize/validate each field, normalize day-of-week/day-of-month interaction explicitly, and compute next executions by walking forward in time rather than solving algebraically. Slower in theory, irrelevant in practice — nobody notices a few milliseconds when they're reading 5 output times.

Building the cron builder for Quietbench, I started with an npm package for parsing and calculating next-run times. Get it working, move on. That lasted about a week.

The problem: the library handled standard cron fine, but broke on real edge cases — conditional OR/AND behavior when day-of-week and day-of-month are combined, step values inside ranges (1-10/2), and off-by-one errors around DST transitions. When I checked its output against standard cron engines, the mismatches showed up fast.

**The actual lesson: **reaching for a library first isn't wrong. But once I was spending more time reverse-engineering why the library disagreed with standard cron behavior than I would've spent writing the logic myself, that was the signal to just own it.

Live at quietbench.dev/cron-builder — curious if anyone finds an edge case it still gets wrong. reaching for a library first isn't wrong. But once I was spending more time reverse-engineering why the library disagreed with standard cron behavior than I would've spent writing the logic myself, that was the signal to just own it.

Live at quietbench.dev/cron-builder — curious if anyone finds an edge case it still gets wrong.

I built a free, no-signup dev tools site because I was tired of ad-heavy formatters

Aniket Saini — Thu, 02 Jul 2026 14:24:24 +0000

Like a lot of developers, I have a handful of bookmarked utility sites I use constantly — JSON formatter, regex tester, that kind of thing. Over time most of them got slower, ad-heavier, or started asking for signups for basic features.

So I built my own small suite:

JSON Formatter — format/validate/minify, with a tree view for nested objects
Regex Tester — live match highlighting plus a plain-English breakdown of what your pattern does
Cron Builder — visual builder + parser, shows your next 5 execution times
Contrast Checker — WCAG AA/AAA contrast checking with a live preview
API Tester — lightweight Postman-style request tester, no install

Everything runs client-side in the browser — no backend, no data leaves your machine, no account needed.

### A few implementation notes for anyone curious

The cron parser was the one piece I ended up writing from scratch rather than pulling in a library. I wanted predictable behavior for the "next 5 execution times" calculation without dragging in a heavy dependency.

Writing a cron parser from scratch is a trap, though. I immediately hit a subtle bug in how Day-of-Month and Day-of-Week restrictions interact. In standard Unix cron, if both fields are restricted (i.e. not *), the engine treats them as an OR condition, not an AND. My initial logic combined them with an AND operator, which broke schedules like 0 0 1 * 1 (which should run on the 1st of the month or every Monday). I caught it when sanity-checking the next execution times against public standard engines, and had to rewrite the matching logic to correctly handle the conditional OR/AND split.

Built with React + Vite + Tailwind, deployed as a static site.

Would genuinely appreciate feedback — especially if anything looks broken on mobile, that's the area I'm least confident in right now.

https://quietbench.dev