DEV Community: Param Jaisinghani

APEX Versus: An AI That Instantly Settles Any 'Who Would Win' Argument

Param Jaisinghani — Wed, 16 Sep 2026 05:31:25 +0000

Ever argued with a friend about who'd win — Goku or Superman? Messi or Ronaldo? Your country vs... any other country? I built APEX Versus to settle exactly this kind of argument instantly, using AI.

Type any two things — real people, anime characters, movie heroes, companies, countries, athletes, even animals — and get an instant, detailed verdict. Free, no account needed.

How it actually works

It's not just "whichever name has more search results." An AI model automatically detects what category your matchup belongs to — there are 16 of them — and scores it on 7 dimensions that actually make sense for that category:

Anime characters → Power, Speed, Durability, Technique, Battle IQ, Willpower, Potential
Athletes → Skill, Athleticism, Achievements, Consistency, Clutch Factor, Legacy, Versatility
Countries → Economy, Military, Influence, Innovation, Quality of Life, Culture, Growth
Plus real people, companies, cricketers, movies, food, animals, mythology, video game characters, cars, electronics, and medical products — each with their own 7 dimensions.

"Naruto vs Goku" and "India vs China" don't get scored on the same axes — the AI picks the right lens and shows a radar chart breakdown, not just a single number.

The fun stuff

⚡ Power Tiers — fictional characters get an 8-tier power-scaling badge, from "C — Peak Human" up to "S++ — Omniversal," the same convention power-scaling communities use
🎲 Surprise Me — one click picks a genuinely plausible random matchup from the same category
🏆 Power Rankings — every comparison ever run feeds a live leaderboard of the highest-scoring entities on the whole site
🗳️ Community Verdict — vote on whether you agree with the AI's call and see the real-time split
💬 Forum — argue it out with other people, not just the AI
🎬 Video export — download your result as a shareable video card
🔗 Embeddable widget — drop a live result card onto your own blog with two lines of code

Why it's not just a toy

Free tier: 5 comparisons a day, zero signup friction
Instant: a real verdict in a few seconds
Consistent: results are cached, so a popular matchup gives everyone the same real analysis instead of a different random answer every time
Careful where it matters: for sensitive categories like medical products, the AI is explicitly instructed to stay informational rather than prescriptive — it's not medical advice, and the app says so clearly

It's a small side project, still improving every week. If you've got a "who would win" argument that's been unresolved for years, go settle it: apexversus.com

My paid AI feature was simultaneously free-for-anyone-to-abuse AND broken for the people actually paying for it

Param Jaisinghani — Fri, 04 Sep 2026 10:44:56 +0000

A few weeks ago I shipped "Deep Analysis" and "Advanced Analysis" on APEX Versus - an AI "who would win" comparison site. Pay a few credits, get a deeper AI breakdown of any matchup: per-dimension reasoning, a hypothetical scenario, wildcard factors, that kind of thing. Pro plan users are supposed to get it unlimited.

Ran a full debug pass on the codebase this week. Found out the feature had two bugs at once, and they canceled each other out in the worst possible way.

Bug 1: the paywall didn't exist server-side.

The frontend checked credits before calling the API. Normal enough - except the API itself never checked anything. POST /api/compare with mode: 'advanced' and no auth header at all would happily burn a real Gemini call and return real content. No login required, no credit check, no daily cap. The free-tier quota I did have only applied to the basic comparison endpoint - I'd built rate limiting for the wrong door.

I confirmed it with a plain curl request. It worked. Zero auth, zero payment, full output.

Bug 2: the feature was invisible to the people who'd actually paid for it.

Separately, the UI had this line:

deepCard.style.display = isPaid ? 'none' : 'block';

Read that again. The card that lets you use Deep Analysis was hidden whenever the user was on a paid plan. My "Advanced Analysis" button - the one Pro users are paying for - had literally no onclick anywhere in the HTML. The function existed. Nothing called it. Ever. It had been dead code since the day I wrote it.

So: free users who found the right request shape got it for nothing, forever. Paying users couldn't find the button to use the feature they were paying for. Directly opposite of what a paywall is supposed to do, both directions, at once.

The root cause was the same bug wearing two different hats.

I'd tightened Firestore security rules a while back so credit balances can only be written server-side (admin SDK), not by the client - good instinct, closes a real self-serve-credits exploit. But I never went back and updated the code that used to write credits from the browser. It was still there, still running, just silently failing every time:

window.deductPaidCredit = async function(uid) {
  try {
    await updateDoc(doc(db, 'userCredits', uid), { credits: increment(-1) });
    // this write has been rejected by security rules for weeks.
    // the empty catch below means nobody ever found out.
  } catch(e) {}
};

An empty catch block is a great way to make a permission error indistinguishable from success.

Fix was straightforward once the actual shape of the bug was clear:

Moved the credit check and deduction fully server-side, inside a Firestore transaction, before the Gemini call happens - not after.
Deleted the dead client-side deduction function entirely.
Fixed the inverted visibility check so paid users can actually see the feature.
Added the missing button for the half of the feature that never had one.

Then I tested it for real instead of trusting the diff: ran Deep Analysis on a live paid account and watched the credit balance drop by exactly 2, atomically, server-confirmed. First time in this feature's existence that a credit deduction has actually happened.

The lesson that's stuck with me: a client-side check and a server-side check are not the same feature just because they look at the same variable. One is a suggestion. The other is the only one that counts. I had the suggestion and skipped the count for a feature that directly touches revenue, and it took a dedicated audit - not normal usage, not testing, not code review - to surface it, because both failure modes were silent by design (empty catches, hidden UI) rather than loud.

If you're running anything with a credits/paywall system: grep your codebase for every place a balance gets checked, and ask whether that check would survive someone skipping your UI entirely and hitting the API directly. If the answer requires the word "should," it's not actually enforced.

APEX Versus is live at apexversus.com if you want to see the (now-actually-working) Deep Analysis in action - first few comparisons are free, no signup needed.

I Built an AI That Settles "Who Would Win" Arguments — Here's How

Param Jaisinghani — Sun, 23 Aug 2026 20:12:19 +0000

Every group chat has that debate that never resolves: Messi or Ronaldo, Naruto or Goku, India or China. Someone always says "there's no real answer" and the thread dies. I got annoyed enough by this that I built a site that actually gives an answer.

What it does

APEX Versus lets you type any two people, characters, companies, or countries and get an AI verdict across 7 power dimensions — power, influence, wealth, intelligence, legacy, popularity, and potential. It picks a winner, gives an Apex Score for each side, and explains the reasoning instead of just flipping a coin.

Try it right now, no signup needed for your first few: https://apexversus.com

Why this was harder than it sounds

The obvious approach — "just ask an LLM who'd win" — falls apart fast. Ask the same matchup twice and you get wildly different reasoning, sometimes a different winner entirely. I ended up structuring every prompt around the same fixed rubric (the 7 dimensions), forcing the model to score each one explicitly before it's allowed to declare a winner. That single change took the results from "random vibes" to something that felt consistent and defensible.

Caching was the other half of the battle. Every unique matchup gets computed once via Gemini and cached in Firestore — reads stay public so anonymous visitors get instant results, but writes are locked down server-side (more on why below).

The stack

Frontend: plain HTML/JS, no framework — kept it simple since this was a solo build
Backend: Vercel serverless functions
AI: Gemini API for generating verdicts
DB/Auth: Firebase (Firestore + Auth)
Payments: Razorpay for the paid tier

A real security lesson

Early on, the Firestore rules for the cache collection were wide open — anyone could PATCH a battle's cached verdict directly via the public REST API, no auth required. On a site whose whole product is declaring "winners" about real people and companies, that's a content-injection hole waiting to be exploited. Locked it down so writes only happen through the Admin SDK server-side, reads stay public. Same story for daily-battle content and user credit balances, which I found could be self-granted client-side before the fix. Worth a reminder that "nobody's going to bother" is not a security model, even for a small solo project.

What's next

Referral system, push notifications for daily battles, and expanding the SEO-friendly comparison pages. Built and run solo, so feedback — what's broken, what's missing, what matchup you tried that gave a bad answer — is genuinely useful and I read all of it.

Try it: https://apexversus.com