DEV Community: Airball Nick

I Built a Data-Driven Palworld Breeding Calculator for Version 1.0

Airball Nick — Wed, 07 Oct 2026 03:53:36 +0000

Palworld breeding looks simple when you are just putting two Pals into the farm.
From a code point of view, it is a nice little data-modeling trap.

I built and maintain a free Palworld Breeding Calculator for Palworld 1.0. It lets players pick two parents and see the egg, pick a target and find valid parents, plan multi-generation breeding trees, and inspect the data behind the tool.

Disclosure: this is my project, and the link above goes to it. It is free to use, does not require an account, and is not affiliated with Pocketpair or Garena.

This post is the build story: how the calculator ended up as a static Next.js app powered by bundled game data instead of a runtime API.

The core mechanic is deterministic

The first useful constraint is that Palworld breeding is not fuzzy.

For ordinary pairs, every Pal has a hidden value usually called CombiRank. The game averages the two parents' ranks, rounds up, and returns the closest Pal in the ordinary breeding pool.

Conceptually:

function calculateTargetRank(firstRank: number, secondRank: number) {
  return Math.floor((firstRank + secondRank + 1) / 2);
}

Then the calculator searches the ordinary pool for the Pal closest to that target rank.

The wrinkle is that ordinary formula does not cover everything. Palworld 1.0 has:

299 Pal entries in the breeding dataset
183 entries in the ordinary formula pool
164 special combo rows that override the formula
297 Pals that can actually enter a Breeding Farm

So the algorithm is not just "average two numbers." It is:

Check whether the parent pair has a special combo.
If so, return the fixed child.
If not, calculate the target CombiRank.
Search only the ordinary formula pool.
Apply the dataset's tie rule consistently.

That is small enough to run in the browser, but important enough that I did not want every component to reimplement it.

The shared breeding module became the heart of the app

The app has a shared breeding library that loads the local JSON data and exposes the same primitives everywhere:

calculateOffspring(first, second)
buildReverseBreedingMap()
rankedParentPairs(target)
Pal lookup by name and slug
farm eligibility and unbreedable flags
display helpers for data dates and gender conditions

That lets these pages agree with each other:

the homepage pair calculator
the reverse planner
the breeding tree
every generated per-Pal guide
the open dataset endpoints

This matters because breeding calculators drift easily. If the homepage, the tree planner, and the data export each carry their own copy of the formula, one of them will eventually be wrong.

Static pages are a feature, not a limitation

I wanted the site to work more like a reference than an app shell. The important pages should be indexable, linkable, and fast without waiting on runtime data.

The current site is a Next.js App Router project with:

a calculator-first homepage
an All Pals chart at /breeding
generated per-Pal breeding guides under /breeding/[pal]
a target-first planner at /reverse-planner
a visual breeding tree at /breeding-tree
passive inheritance odds at /breeding/passives
open data at /data

The breeding data and Pal artwork are bundled locally. That means the core calculator does not depend on a third-party image CDN or a database request at runtime.

For this kind of tool, static generation is a good fit:

the dataset changes by game version, not by user
every Pal page can be generated up front
search engines can crawl real content instead of a blank client app
the calculator still hydrates where interactivity is useful

The result is closer to a game reference with tools attached than a single-page calculator.

Reverse lookup changes the user experience

Most players do not ask, "What does this pair produce?"

They ask, "How do I get Anubis?" or "What can I breed from the Pals I already have?"

So the app builds a reverse map by iterating through valid farm-eligible parents and storing every child outcome:

for (let i = 0; i < parents.length; i += 1) {
  for (let j = i; j < parents.length; j += 1) {
    const first = parents[i];
    const second = parents[j];
    const result = calculateOffspring(first, second);
    // store [first, second] under result.child
  }
}

That reverse index powers the target-first planner and the per-Pal pages. Each target page can show the parent pairs that produce it, while the breeding tree can continue expanding parent routes backward by generation.

The useful UI pattern is:

Pick the target Pal.
Compare parent pairs.
Prefer the pair whose rarest parent is easiest to obtain.
Expand the harder parent another generation if needed.

That workflow is much closer to how players actually breed.

The data model had a few sharp edges

The more interesting part of this project was not the UI. It was the corrections.

The first trap: Katress + Wixen.

Most breeding combos are unordered. Parent A and parent B can be swapped and the child stays the same. Katress + Wixen is the exception: the child depends on which species is female.

female Katress + male Wixen gives Katress Ignis
male Katress + female Wixen gives Wixen Noct

If your special-combo map uses a sorted pair key like Katress|Wixen, the second row overwrites the first one. One child silently disappears.

The fix was to store all outcomes for a pair, then expose alternates with their gender condition.

The second trap: game-file rows are not always enough to decide whether a Pal can breed in game.

Panthalus and Astralym have self-pair rows in the data, but neither can enter a Breeding Farm. Panthalus cannot use base facilities, and Astralym is unobtainable. That rule cannot be inferred safely from special_combos, so the dataset now has an explicit breeding_exclusions block with sources and verification dates.

The third trap was my own bug: I initially treated any X + X -> X row as "catch-only." That was too broad. Relaxaurus Lux and Mossanda Lux have self-pair rows, but they also have real cross-species combos. The correct rule is: a Pal is catch-only only when every listed combo for it is the self-pair.

That kind of mistake is exactly why the site now has a public corrections log.

The dataset is public on purpose

The calculator exposes the same data it uses:

The endpoints are static files or static route outputs with CORS open, so another browser-based tool can fetch them directly.

Example:

const data = await fetch("https://www.palworldonline.net/api/pals.json")
  .then((response) => response.json());

const anubis = data.pals.find((pal) => pal.name === "Anubis");
console.log(anubis.parent_pair_count);

The data includes fields that are easy to get wrong if every tool re-derives them:

breedable
breeding_farm_eligible
special_only
parent_pair_count
elements
male_percent
gender fields for special combos

I would rather other tools reuse corrected data than repeat the same bugs.

What I would do again

Three decisions paid off:

First, centralize the formula. Every route and export should call the same calculator logic.

Second, make corrections explicit data. If something cannot be inferred from game-file combo rows, it deserves its own field.

Third, publish the data. A tool with a visible corrections log is easier to trust than a black box that only shows the final answer.

If you play Palworld, the calculator is here:

https://www.palworldonline.net/

If you build tools, the dataset is here:

https://www.palworldonline.net/data

If you spot a breeding result that looks wrong, I want to know. Game data changes, and the only useful calculator is one that can be corrected.

I Opened the Palworld Breeding Dataset Behind My Calculator

Airball Nick — Wed, 07 Oct 2026 03:51:13 +0000

I built a Palworld breeding calculator, but the part I most want other developers to use is the data.

The dataset behind the site is now public as JSON and CSV:

https://www.palworldonline.net/data

Disclosure: I built and maintain the calculator I am linking to here. It is free to use, does not require an account, and is not affiliated with Pocketpair or Garena.

This post is about what is in the dataset, why I opened it, and the breeding-data bugs it is designed to prevent.

What is available

There are four lightweight endpoints:

The data page also links the full Paldeck profile JSON used by newer lookup features.

The breeding exports cover Palworld 1.0 breeding data:

299 Pal entries
297 Pals that can enter a Breeding Farm
183 ordinary formula-pool entries
164 special combo rows
CombiRank values
parent-pair counts
element types
gender ratio
breedable and farm-eligible flags
gender fields for special combos

The endpoints are served with:

Access-Control-Allow-Origin: *

That means you can fetch them from another browser-based tool without needing a proxy.

Quick example

type PalRow = {
  name: string;
  slug: string;
  combi_rank: number;
  rank_position: number;
  special_only: boolean;
  breedable: boolean;
  breeding_farm_eligible: boolean;
  parent_pair_count: number;
  elements: string[];
  male_percent: number;
  icon_url: string | null;
  guide_url: string;
};

type PalsResponse = {
  pals: PalRow[];
};

const data: PalsResponse = await fetch(
  "https://www.palworldonline.net/api/pals.json",
).then((response) => response.json());

const pals = data.pals;

const targets = pals
  .filter((pal) => pal.breedable && pal.parent_pair_count > 0)
  .sort((a, b) => b.parent_pair_count - a.parent_pair_count)
  .slice(0, 10);

console.table(targets.map((pal) => ({
  name: pal.name,
  pairs: pal.parent_pair_count,
  rank: pal.combi_rank,
})));

For spreadsheet work, use the CSV versions. The schema is intentionally flat.

Why not just scrape a calculator?

Because breeding tools tend to hide the assumptions that matter.

If a site only shows the final child, you cannot tell:

whether special combos were applied before the formula
whether special-only children were excluded from the ordinary pool
whether the calculator knows about gender-dependent combo rows
whether farm-ineligible Pals were excluded
whether X + X -> X was interpreted too broadly

The public dataset exists so those assumptions are visible.

Correction 1: Katress + Wixen is gender-dependent

This was the row that broke my first implementation.

Katress + Wixen can produce two children:

female Katress + male Wixen gives Katress Ignis
male Katress + female Wixen gives Wixen Noct

Most special combos are unordered. This one is not.

If you store special combos in a map keyed by sorted parent names, both rows become the same key:

Katress|Wixen

One row overwrites the other, and one child disappears from your reverse lookup.

The combo export avoids that by carrying gender fields:

{
  "parent_a": "Katress",
  "parent_a_gender": "female",
  "parent_b": "Wixen",
  "parent_b_gender": "male",
  "child": "Katress Ignis",
  "breeds_true": false,
  "gender_dependent": true
}

If your tool builds a reverse planner, you need this.

Correction 2: farm eligibility is not the same as having a row

Some data rows exist because they are in the game files, but they do not mean the Pal can actually use the Breeding Farm.

Panthalus and Astralym are the two important cases in this dataset.

They have self-pair rows in the game data. A naive tool might read those rows and conclude that each Pal breeds true.

In practice, they cannot be used as normal breeding parents:

Panthalus cannot use base facilities, including the Breeding Farm.
Astralym is unobtainable by the player.

So the Pal export separates:

breedable
breeding_farm_eligible

Those fields are not duplicates. A Pal can be present in the data while still being excluded from real parent-pair planning.

Correction 3: a self-pair row is not enough

This one was my own mistake.

I originally treated any X + X -> X row as proof that a Pal was catch-only.

That is too aggressive.

Relaxaurus Lux and Mossanda Lux have self-pair rows, but they also have real cross-species combos:

Relaxaurus + Sparkit
Mossanda + Grizzbolt

The correct rule is:

A Pal is catch-only only when every listed route for that Pal is the self-pair.

That bug is now in the corrections log because I want downstream users to know what changed and why.

The CombiRank formula still matters

The data is not just a table of special cases.

For ordinary breeding pairs, Palworld averages both parents' CombiRank, rounds up, and returns the closest Pal in the ordinary formula pool.

CombiRank runs opposite to player intuition: common Pals sit near the high end, rare Pals near the low end.

That is why the export includes the raw combi_rank instead of only a precomputed pair table. You can build your own planning logic if you want to rank routes differently.

For example, you might prefer parent pairs where the rarer parent is still relatively common:

function routeDifficulty(pair: [PalRow, PalRow]) {
  return Math.min(pair[0].combi_rank, pair[1].combi_rank);
}

Higher is usually easier in that comparison, because the lower-ranked parent is less rare.

Why the corrections log is part of the product

Game datasets are not static truth.

They are interpreted. Sometimes the interpretation is wrong. Sometimes the source table is real but incomplete for gameplay. Sometimes a game update moves the goalposts.

That is why the data page includes a corrections log with:

what the common mistake is
what the actual behavior is
why the correction matters
the sources checked

This is not just for transparency. It is a maintenance tool. If someone tells me the calculator is wrong, I want to know which assumption changed.

Use it

The dataset license on the page is intentionally permissive:

Free to use, including commercially. Attribution with a link to palworldonline.net is appreciated.

If you are building a Palworld tool, spreadsheet, wiki helper, Discord bot, route planner, or visualization, you can start here:

https://www.palworldonline.net/data

If you only want the calculator, it is here:

https://www.palworldonline.net/

And if you find an error, please treat that as useful signal. I opened the data because I would rather have one corrected table than a dozen tools quietly repeating the same bug.

Next.js on Cloudflare Workers: 3 bugs that only showed up in production

Airball Nick — Tue, 06 Oct 2026 09:28:26 +0000

I recently shipped a side project, TikTok Story Viewer. You paste a public TikTok username and watch that account's Stories without logging in. It's a Next.js 15 App Router site: ~200 statically generated pages in 13 languages, two API routes, and a media proxy that streams images and videos from TikTok's CDN.

I deployed it to Cloudflare Workers with the OpenNext Cloudflare adapter. Everything worked in next dev. Then three problems appeared that I had never seen locally. Here's what they were, how I tracked them down, and what I changed.

1. Every thumbnail was broken: the query string got decoded twice

Symptom

In production every avatar and video cover was a broken image. My media proxy endpoint returned 502 for all of them, while opening the same CDN URLs directly in the browser worked fine.

The proxy itself is simple. The client passes the CDN URL as a query parameter, and the Worker fetches it and streams it back:

// client
const proxied = (url: string) => `/api/media/?url=${encodeURIComponent(url)}`;

// app/api/media/route.ts
const url = req.nextUrl.searchParams.get('url');

The wrong guess

My first theory was that TikTok's CDN blocks requests coming from Cloudflare IPs. It's a plausible story and I almost built a fallback around it. Then I logged what the Worker actually received and compared it with what the client sent:

sent:     https://p19-…webp?dr=9640&refresh_token=…&x-expires=…&x-signature=…
received: https://p19-…webp?dr=9640

Everything after the first & was gone, including x-expires and x-signature. TikTok's image URLs are signed, so an unsigned URL gets a 403. Not IP blocking.

Why

encodeURIComponent turns the inner & into %26. Somewhere between the Worker receiving the request and Next.js parsing searchParams in this setup, the query string was decoded one extra time. %26 became a real &, and the nested URL got split into separate parameters.

The local Workers runtime (wrangler dev on the OpenNext build) reproduced it. next dev didn't, which is why I never noticed. My earlier "it works on Workers" test had used an audio URL without a query string, so it passed.

Fix

Stop putting a URL inside a URL. I now send the media URL as base64url, which contains no &, = or %, so it survives any amount of decoding:

// lib/media-url.ts: used by both client and server
export function encodeMediaUrl(url: string): string {
  let bin = '';
  for (const byte of new TextEncoder().encode(url)) bin += String.fromCharCode(byte);
  return btoa(bin).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}

export function decodeMediaUrl(token: string): string | null {
  try {
    const b64 = token.replace(/-/g, '+').replace(/_/g, '/');
    const bin = atob(b64 + '='.repeat((4 - (b64.length % 4)) % 4));
    return new TextDecoder().decode(Uint8Array.from(bin, (c) => c.charCodeAt(0)));
  } catch {
    return null;
  }
}

const proxied = (url: string) => `/api/media/?u=${encodeMediaUrl(url)}`;

The proxy still validates the decoded URL against a host allowlist and re-checks every redirect hop, so it can't be used as an open proxy.

Lesson: if you pass a URL through a query parameter, test it with a URL that has its own query string, and test on the real runtime.

2. My API key ended up inside the Worker bundle

Symptom

No user-visible symptom, which is what makes it dangerous. I keep a third-party API key in .env.local, read it only in server code, and never prefix it with NEXT_PUBLIC_. Standard Next.js hygiene.

Then I read the adapter's build code and found it compiles your env files into the Worker. In @opennextjs/cloudflare, a build step reads .env, .env.production, .env.local and .env.production.local and writes the values into .open-next/cloudflare/next-env.mjs, which is bundled into the Worker. That makes local .env values available at runtime, but it also means any secret in an .env* file gets uploaded as part of your Worker code.

To be clear, that isn't the browser bundle. Visitors can't see it. But it's in your deploy artifact, and anyone with access to the script or the build output can read it.

Fix

Secrets go in .dev.vars for local development (Wrangler reads it automatically) and in wrangler secret put for production. .env* files are only for non-secret build settings like NEXT_PUBLIC_SITE_URL.
next dev doesn't read .dev.vars, so I load it with Node's built-in flag:

"dev": "node --env-file-if-exists=.dev.vars node_modules/next/dist/bin/next dev"

A small check runs before every deploy and refuses to continue if a secret value shows up anywhere it shouldn't:

// scripts/check-no-secrets.mjs (simplified)
const secrets = readSecrets('.dev.vars'); // e.g. the API key values
for (const dir of ['.next/static', '.open-next']) {
  for (const file of walk(dir)) {
    const content = fs.readFileSync(file);
    for (const s of secrets) if (content.includes(s.value)) fail(`${s.name} found in ${file}`);
  }
}
// .env* files are compiled into the Worker, so secrets must not live there either

"deploy": "npm run cf:build && node scripts/check-no-secrets.mjs && opennextjs-cloudflare deploy"

Lesson: "server-only" isn't the end of the story. Check what your deployment adapter does with env files, and grep your build output for your secrets.

3. The build crashed on one machine: `Cannot find module 'X X'`

Symptom

npm run deploy worked on my machine and failed on another one:

Error: Cannot find module '/Library/sec_registry/npm-registry-hook.js /Library/sec_registry/npm-registry-hook.js'
Require stack:
- internal/preload
Next.js build worker exited with code: 1

The same path twice, joined by a space, treated as one module.

Why

That machine is managed by IT. A system shell file prepends a security hook to NODE_OPTIONS every time a shell starts:

export NODE_OPTIONS="--require /Library/sec_registry/npm-registry-hook.js${NODE_OPTIONS:+ $NODE_OPTIONS}"

Open a shell inside another shell (an editor's terminal, a nested zsh) and you get the flag twice:

--require /path/hook.js --require /path/hook.js

Node is fine with that. But Next.js parses NODE_OPTIONS and re-serializes it for its build and dev workers. When an option appears twice in the space-separated form, the values get concatenated, and the worker receives:

--require="/path/hook.js /path/hook.js"

I confirmed it in isolation by feeding both variants through Next's own helpers:

const u = require('next/dist/server/lib/utils.js');
u.formatNodeOptions(u.getParsedNodeOptionsWithoutInspect());
// single  → "--require=/path/hook.js"
// doubled → "--require=\"/path/hook.js /path/hook.js\""

Fix

I couldn't, and shouldn't, edit the managed system file. Instead, every npm script that starts Next.js goes through a tiny wrapper that removes exact duplicates from NODE_OPTIONS and keeps one copy of each hook:

// scripts/run.mjs: usage: node scripts/run.mjs next build
const TAKES_VALUE = new Set(['-r', '--require', '--import', '--loader']);

function dedupeNodeOptions(value = '') {
  const tokens = value.match(/"[^"]*"|'[^']*'|\S+/g) ?? [];
  const units = [];
  for (let i = 0; i < tokens.length; i++) {
    const next = tokens[i + 1];
    if (TAKES_VALUE.has(tokens[i]) && next && !next.startsWith('-')) units.push(`${tokens[i]} ${tokens[++i]}`);
    else units.push(tokens[i]);
  }
  return [...new Set(units)].join(' ');
}

const env = { ...process.env, NODE_OPTIONS: dedupeNodeOptions(process.env.NODE_OPTIONS) };
spawn(process.argv[2], process.argv.slice(3), { stdio: 'inherit', env });

"build": "node scripts/run.mjs next build",
"cf:build": "node scripts/run.mjs opennextjs-cloudflare build"

build needs the wrapper too, because the OpenNext build runs npm run build internally.

Lesson: if a build fails only on one machine, compare echo $NODE_OPTIONS first.

Bonus: things that did work well

Fully static pages + Workers static assets. Every page is prerendered and there's no ISR, so I used OpenNext's static-assets incremental cache. No R2 bucket, no KV for page caching. The compressed Worker is about 1.2 MB, comfortably under the free plan's limit.
Cron Triggers for quota alerts. An hourly scheduled handler checks the upstream API quota and emails me (via Email Routing's send_email binding) at 20%, 5% and 0% remaining, deduplicated with KV. One oddity: a temporary * * * * * schedule never fired for me, while 0 * * * * has run every hour since. I didn't get to the bottom of that one.
Cloudflare Web Analytics needed zero code. Enabling it in the dashboard injected the beacon automatically, including SPA navigation tracking.

If you're moving a Next.js app to Workers, my short checklist is:

Test URL-in-URL parameters on the real runtime.
Keep secrets out of .env*, and grep your build output.
Check NODE_OPTIONS when only one machine fails.

The site is live at tikstory.net if you want to see the result. Feedback is welcome, especially if you've run into any of these differently. 🙏

I Built TikStory: A No-Login TikTok Story Viewer on Next.js and Cloudflare Workers

Airball Nick — Tue, 06 Oct 2026 09:19:52 +0000

TikTok Stories are easy to post and easy to miss. They disappear after 24 hours, and if you watch one while logged into TikTok, the creator can see your account in the viewer list.

I wanted a simpler web experience for public TikTok content: paste a username, view what is publicly available, and do it without signing into TikTok.

That became TikStory, a free browser-based TikTok Story viewer and downloader:

https://tikstory.net

What TikStory does

TikStory lets you enter a public TikTok username or profile URL and view:

Active TikTok Stories
Recent public videos
Public reposts
Profile details such as avatar, bio, follower count, likes and video count
Full-size profile pictures

It also supports downloads:

Stories as MP4 or JPG
Public videos as MP4
Audio from videos or Stories as MP3
Profile pictures in full size

The project is deliberately simple from the user side:

Open tikstory.net
Paste a public TikTok username
Watch or download from the browser

No TikTok login. No app install. No browser extension.

The privacy line I wanted to keep clear

I built TikStory around a few product rules:

Public accounts only. It does not bypass private accounts or TikTok privacy settings.
No TikTok login. Users never enter TikTok credentials.
No stored search history. The app does not keep a per-user lookup history.
No media storage. Media is streamed through the app and not stored as a library.
Creator removal requests are supported. A creator can request that their username be blocked from search.

That last point matters. Tools like this should not pretend the social context disappears just because the content is technically public. The project is meant for low-friction viewing, research and personal archiving of public content, not harassment, reposting, impersonation or scraping private material.

The stack

The site is built with:

Next.js 15 App Router
React 19
Tailwind CSS
OpenNext for Cloudflare
Cloudflare Workers
TypeScript

Most pages are statically generated. Runtime work happens in the Worker for the TikTok lookup API, media proxying, redirects and locale handling.

The live domain is:

https://tikstory.net

Why Cloudflare Workers

For this type of project, Cloudflare Workers are a good fit:

The app is mostly read-heavy.
The generated pages are static and cacheable.
The runtime API layer is small.
The media proxy can run close to users.
Deployment stays lightweight.

One design detail I cared about was keeping secrets out of the client bundle. The public site URL can be a build variable, but provider API keys live only in Worker secrets or local .dev.vars during development.

I also added a deploy-time secret check so API keys do not accidentally end up inside .env files or build output. It is the kind of boring guardrail that saves you from a very un-boring cleanup later.

Multilingual SEO from day one

TikStory currently ships in 13 languages:

English
Spanish
Portuguese
Indonesian
Malay
German
French
Italian
Dutch
Russian
Turkish
Thai
Vietnamese

Each tool page has localized metadata, canonical URLs and hreflang alternates. There are also dedicated pages for adjacent intents like:

TikTok Story Viewer
Anonymous TikTok Viewer
TikTok Profile Viewer
TikTok Story Downloader
TikTok Video Downloader
TikTok Repost Viewer
TikTok MP3 Downloader
TikTok Profile Picture Downloader
TikTok Follower Count

That structure is not accidental. Search traffic for tools like this is fragmented across many intents, and users often know the task they want before they know the product name.

A few implementation decisions that paid off

1. Keep result URLs out of the index

Search result pages can easily create crawl traps if every username becomes an indexable URL. TikStory keeps lookup results out of canonical indexable paths and blocks API/result-style URLs from crawling.

2. Stream media instead of storing it

Media is proxied with a host allowlist, and redirects are checked at each hop. The app does not keep copies. That keeps the system smaller, reduces operational risk and matches the privacy promise better.

3. Treat private accounts as a hard stop

If an account is private, the app says so and stops there. No ambiguity, no "try again with another method" dark pattern.

4. Write responsible product copy

The copy avoids fake user counts, fake testimonials and exaggerated guarantees. It explains what the tool does, what it does not do and how users should handle downloaded content.

What I learned

Building a small utility product is less about the input box and more about the edges:

What happens when a story expires?
What happens when the provider is rate limited?
What should a private account response look like?
How do you avoid indexing infinite lookup pages?
Where do you put removal requests?
How do you make the same tool page useful in 13 languages?

Those decisions are not flashy, but they make the product feel trustworthy.

Try it

If you ever need to view or save a public TikTok Story without logging in, try it here:

TikStory: TikTok Story Viewer

I would love feedback from other builders:

Is the positioning clear?
What would you change on the landing page?
Are there technical details you would want me to write about next?
Would a browser extension version be useful?

Thanks for reading.

DEV Community: Airball Nick

I Built a Data-Driven Palworld Breeding Calculator for Version 1.0

The core mechanic is deterministic

The shared breeding module became the heart of the app

Static pages are a feature, not a limitation

Reverse lookup changes the user experience

The data model had a few sharp edges

The dataset is public on purpose

What I would do again

I Opened the Palworld Breeding Dataset Behind My Calculator

What is available

Quick example

Why not just scrape a calculator?

Correction 1: Katress + Wixen is gender-dependent

Correction 2: farm eligibility is not the same as having a row

Correction 3: a self-pair row is not enough

The CombiRank formula still matters

Why the corrections log is part of the product

Use it

Next.js on Cloudflare Workers: 3 bugs that only showed up in production

1. Every thumbnail was broken: the query string got decoded twice

Symptom

The wrong guess

Why

Fix

2. My API key ended up inside the Worker bundle

Symptom

Fix

3. The build crashed on one machine: Cannot find module 'X X'

Symptom

Why

Fix

Bonus: things that did work well

I Built TikStory: A No-Login TikTok Story Viewer on Next.js and Cloudflare Workers

What TikStory does

The privacy line I wanted to keep clear

The stack

Why Cloudflare Workers

Multilingual SEO from day one

A few implementation decisions that paid off

1. Keep result URLs out of the index

2. Stream media instead of storing it

3. Treat private accounts as a hard stop

4. Write responsible product copy

What I learned

Try it

3. The build crashed on one machine: `Cannot find module 'X X'`