DEV Community: Andrew Rozumny

CORS Errors Explained: A Practical Debug Guide for 2026

Andrew Rozumny — Fri, 24 Apr 2026 13:37:10 +0000

Access to fetch at 'https://api.example.com' from origin
'http://localhost:3000' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

I've personally lost hours thinking my API was broken — only to realize the server was fine, but the browser simply refused to show the response.
If you're stuck in that loop right now, this guide will save you time.

What CORS actually is

CORS is not a server problem — it's a browser restriction.
The browser checks whether your frontend is allowed to access a backend from another origin. If the server doesn't explicitly allow it via response headers, the browser blocks the response from your code.

Important: the request still reaches the server. You just can't read the response in JavaScript.

The 5 most common CORS errors

Error: No 'Access-Control-Allow-Origin' header is present

Cause: Your server doesn't include the required header in its response.

app.use((req, res, next) => {
  res.header("Access-Control-Allow-Origin", "http://localhost:3000");
  next();
});

Error: Response to preflight request doesn't pass access control check

Cause: The browser sends an OPTIONS request first to check permissions — and your server doesn't handle it.

app.options("*", (req, res) => {
  res.header("Access-Control-Allow-Origin", "http://localhost:3000");
  res.header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE");
  res.header("Access-Control-Allow-Headers", "Content-Type, Authorization");
  res.sendStatus(204);
});

Error: 'Access-Control-Allow-Origin' must not be '*' when credentials are included

Cause: Cookies and Authorization headers require a specific origin — wildcards don't work with credentials.

app.use((req, res, next) => {
  res.header("Access-Control-Allow-Origin", "http://localhost:3000");
  res.header("Access-Control-Allow-Credentials", "true");
  next();
});

Error: Method PUT is not allowed by Access-Control-Allow-Methods

res.header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE,OPTIONS");

Error: Request header field Authorization is not allowed

res.header("Access-Control-Allow-Headers", "Content-Type, Authorization");

Fix by stack

Express / Node.js

import cors from "cors";

app.use(cors({
  origin: "http://localhost:3000",
  credentials: true
}));

nginx

location /api/ {
  add_header 'Access-Control-Allow-Origin' 'http://localhost:3000';
  add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
  add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';

  if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Max-Age' 1728000;
    add_header 'Content-Length' 0;
    return 204;
  }
}

FastAPI

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:3000"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

Apache (.htaccess)

Header set Access-Control-Allow-Origin "http://localhost:3000"
Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"

How preflight actually works

When you send a request with a custom header (like Authorization) or a non-simple method (like PUT), the browser doesn't send your request directly. It first sends an OPTIONS request to ask: "Is this allowed?"

Browser  →  OPTIONS /api/data  →  Server
         ←  200 + CORS headers  ←
Browser  →  PUT /api/data       →  Server
         ←  response            ←

If the server doesn't respond to OPTIONS correctly — or takes too long — the actual request never gets sent. That's why fixing preflight handling is often the first step.

The credentials trap

When you use credentials: 'include' in fetch (for cookies or session auth), the wildcard * stops working entirely. You must specify the exact origin AND set Access-Control-Allow-Credentials: true.

// This will NOT work with credentials
res.header("Access-Control-Allow-Origin", "*");

// This will
res.header("Access-Control-Allow-Origin", "https://yourfrontend.com");
res.header("Access-Control-Allow-Credentials", "true");

Quick debug checklist

[ ] Server returns Access-Control-Allow-Origin with the correct origin
[ ] OPTIONS requests return 200/204 with CORS headers
[ ] Access-Control-Allow-Methods includes the method you're using
[ ] Access-Control-Allow-Headers includes custom headers you send
[ ] If using credentials — no wildcard *, specific origin only

Test before you change more code

Before editing middleware, proxy configs, or .htaccess files, verify what headers your server is actually returning.

Paste your endpoint URL into ToolDock CORS Tester — it shows the exact headers for both the main request and the preflight, so you know exactly what's missing before touching your code.

SEO in 2026 feels broken. So I’m trying something else

Andrew Rozumny — Fri, 17 Apr 2026 13:56:49 +0000

I’m not an SEO expert.

Just a developer trying to get at least some users to the things I build.

And lately it feels… strange.

What I’m seeing

I published several posts on Dev.to.

Some were original — 20–80 views

Some slightly adapted — maybe 100–300

But overall, nothing really moves.

At the same time:

Google traffic → almost zero
My own site → barely indexed
Social → small spikes, then nothing

Feels like you start from zero every time.

The weird part

When I write a normal article — nobody reads it.

When I build a simple tool page for one very specific use case —

it has more chance to be indexed and actually used.

Not huge numbers. But different behavior.

This doesn’t look like classic SEO anymore.

Feels more like:

content that ranks → vs → answers that get extracted

The moment it clicked

I asked ChatGPT:

"regex for email validation"

It returned:

working regex
explanation
edge cases

Everything in one place.

No need to open anything else.

So why would someone click search results?

What I’m trying now

Instead of writing more content, I started building tools.

Small ones. Very simple.

JSON formatter
Regex tester
Base64 encoder
SSL checker
IP lookup

Right now I’m building towards ~100 tools.

Early signals

Still early, but I see:

tool pages get indexed faster
people actually stay on them
some long-tail queries appear
structured parts sometimes show up in AI answers

Again, small numbers.

But not the same pattern as blog posts.

How I structure a page now

I stopped thinking in terms of:

tool + some SEO text

Now each page looks more like a small answer system:

clear title for one exact problem
working tool
short intro
2–3 useful sections
examples
FAQ
glossary
related tools
links to nearby tools

Data structure behind it

Instead of writing everything manually, I model pages like this:

{
  slug: "json-formatter",
  title: "JSON Formatter",
  searchIntents: [
    "format json online",
    "pretty print json",
    "json beautifier"
  ],
  useCases: [
    {
      title: "Debugging API responses",
      description: "Make JSON readable"
    }
  ],
  glossary: [
    {
      term: "JSON",
      definition: "Structured data format"
    }
  ],
  relatedSlugs: ["json-validator"],
  clusterSlugs: ["json-validator", "json-diff"]
}

Shared layout

All pages use same structure:

<ToolPage>
  <ToolHeader />
  <ToolUI />
  <HowToUse />
  <UseCases />
  <Examples />
  <FAQ />
  <Glossary />
  <RelatedTools />
  <ClusterTools />
</ToolPage>

Only the tool itself is different.

Everything else is predictable.

What I think is changing

Not sure yet, but looks like:
Content is no longer the main unit.
Structured answers are.

Blog posts are easy to summarize.

Tool pages with clear structure are harder to replace.

Not sure where this goes

Honestly, I don’t have a conclusion.

Just testing.

I’ll keep building tools, structuring pages, and see what happens.
If something works — will share numbers.

If not — also useful result.

Curious about others

Are you seeing any traffic from AI tools?

Or still mostly Google?

Cron Expressions Explained (Without the Headache)

Andrew Rozumny — Thu, 16 Apr 2026 16:31:32 +0000

You see this:

*/5 * * * *

You know it does something.

You’re just not 100% sure what.

At some point every developer has this moment:

you google “cron expression every 5 minutes”

copy something

paste it into config

and hope production doesn’t break

Here’s the thing.

Cron is not hard.

It’s just… not made for humans.

Quick examples you actually use:

Every 5 minutes:

*/5 * * * *

Every day at midnight:

0 0 * * *

Every Monday at 9:

0 9 * * 1

The annoying part is not writing it.

It’s reading it later.

Especially when you come back after 2 weeks and think:

“who wrote this?”

(it was you)

Most mistakes are boring:

wrong field order

wrong timezone

misunderstanding what * really does

Nothing fancy.

Just enough to break things silently.

What helped me personally:

I stopped trying to “read” cron.

I just generate it and move on.

👉 https://tooldock.org/tools/crontab-generator

If you ever spent more than 5 minutes staring at a cron expression — you’re doing it the hard way.

Save this for later. You’ll need it.

Regex That Actually Works (Copy-Paste Ready Examples)

Andrew Rozumny — Wed, 15 Apr 2026 11:23:38 +0000

You paste a regex.

It doesn’t work.

You change one character.

Now it works.

You have no idea why.

At some point you just accept it.

Regex is not something you fully understand.

It’s something you negotiate with.

Typical workflow:

google "regex email"
copy something scary-looking
paste
test
slightly panic
tweak random symbol
it works
never touch it again

Here are a few patterns that actually come up all the time.

Email (good enough, not perfect):

^[^\s@]+@[^\s@]+\.[^\s@]+$

URL (basic, but works in most cases):

https?:\/\/[^\s]+

Only numbers:

^\d+$

Remove extra spaces:

\s+

The problem with regex is not writing it.

It’s understanding it later.

You come back after a week and think:

“what is this even matching?”

Most bugs are stupid:

forgot to escape something
used greedy match by accident
missed boundaries

Nothing complex.

Just painful.

What helped me:

stop trying to be clever.

Start simple. Then expand.

Also, use a tester.

Seriously.

👉 https://tooldock.org/tools/regex-tester

Paste → tweak → see what’s happening.

Way faster than guessing.

If you have one regex you keep reusing — drop it below.

I’m pretty sure we’re all sharing the same 5 patterns anyway.

Fix JSON Parse Errors Fast (With Real Examples)

Andrew Rozumny — Tue, 14 Apr 2026 13:06:55 +0000

If you’ve ever seen this:

Unexpected token } in JSON at position 42

Congrats. You’ve officially joined the club.

😅 The Classic Scenario

You’re just trying to:

call an API
parse a config
or debug something simple

And suddenly:

💥 everything breaks

🔥 The Problem (aka “it looks fine to me”)

Example:

{
  "name": "John",
  "age": 30,
}

Looks fine, right?

Nope. That trailing comma just ruined your day.

🧠 Why JSON Is So Annoying

Because JSON is stricter than your code reviewer.

It does NOT allow:

trailing commas
single quotes
comments

Meanwhile JavaScript is like:

“eh, whatever bro”

⚡ The Fastest Way to Fix It

Instead of staring at your screen for 10 minutes:

👉 https://tooldock.org/tools/json-validator

Paste → instant error → fixed.

No guessing. No pain.

🧪 Quick Debug Checklist

When JSON breaks, check:

❌ trailing commas
❌ missing quotes
❌ broken {} or []
❌ undefined values

💀 Real Talk

Most JSON bugs are not complex.

They’re just:

“you missed one tiny thing”

🔗 Want deeper breakdown?

More examples + real fixes here:

👉 https://tooldock.org/json-parse-error-explained

💡 Pro Tip

When debugging API responses:

always log raw JSON
validate before parsing
never trust external data blindly

(yes, even your own backend)

⚙️ Final Thought

JSON errors are annoying.

But once you know the patterns — they become a 5-second fix.

If this saved you even 1 debug session — mission accomplished 🚀

You’re probably leaking sensitive data every time you use online dev tools

Andrew Rozumny — Tue, 07 Apr 2026 10:46:31 +0000

Most developers don’t think twice before pasting data into online tools.

JSON formatters, JWT decoders, base64 converters, regex testers…

You just open a site, paste your data, get the result, and move on.

But here’s the problem:

You’re often sending that data to someone else’s server.

The hidden risk

That “quick utility” you’re using?

It might:

log your data
store it temporarily
or even keep it longer than you expect

And most of the time, you have no idea.

No clear guarantees.
No visibility.
No control.

“It’s just a formatter” — is it?

Even simple tools usually work like this:

You paste your data
It gets sent to a backend
The server processes it
You get a response

That means your data leaves your machine.

Sometimes it’s harmless.

Sometimes it’s not.

Where this becomes a real problem

Think about what developers actually paste into these tools:

API keys
tokens
internal JSON payloads
logs with user data
config files

Stuff that was never meant to leave your environment.

I caught myself doing this

At some point I realized I was doing exactly this.

Copy → paste → convert → done.

Without even thinking about where that data goes.

That’s when it started to feel… wrong.

A better approach

I started looking for tools that:

run entirely in the browser
don’t send data anywhere
don’t require accounts

Just open → use → close.

Why this matters

For small utilities, there’s no real reason to involve a server.

Formatting, encoding, decoding — all of this can be done locally.

Faster.
Safer.
Simpler.

What I ended up doing

I started putting together my own small set of browser-based tools.

Mostly for myself at first.

Just to avoid jumping between random sites and wondering what happens to my data.

For small tools, local-first just makes more sense.

Curious how you handle this

Do you trust online tools with sensitive data?

Or do you prefer local-first alternatives?

Stop Pasting Sensitive Data Into Random Online Tools

Andrew Rozumny — Fri, 03 Apr 2026 19:09:16 +0000

If you've ever pasted sensitive data into an online tool…

pasted a JWT into a random decoder
formatted JSON with API keys inside
tested regex on production data

…you’ve probably thought:

“this is probably fine”

But is it?

The uncomfortable truth

Most online tools still work like this:

You paste your data
It gets sent to a server
It gets processed there

And you're just… trusting it.

No idea where it goes.
No idea if it’s logged.
No idea who can access it.

The moment it hit me

I was debugging a JWT with user data inside.

Pasted it into a tool.

Then realized:

I have no idea where this just went.

That was enough.

So I built my own tools

I ended up building a set of dev tools that:

run entirely in the browser
don’t upload anything
don’t track anything

👉 https://tooldock.org/

Why this actually matters

This isn’t paranoia.

This is everyday dev stuff:

tokens
logs
internal payloads
user data

You don’t always control what ends up in your clipboard.

Example

Let’s say you’re:

decoding a JWT
formatting JSON
testing regex

With most tools:
→ your data leaves your device

With ToolDock:
→ everything stays local

Unexpected benefit

It’s not just privacy.

It’s speed.

no network
no waiting
instant feedback

Once you use client-side tools, everything else feels slow.

What’s inside

Right now there are ~90 tools:

JSON Formatter
Regex Tester (real-time)
UUID Generator
Base64 Encode / Decode
JWT Decoder
Timestamp Converter
Hash Generator

Curious

Do you actually care if tools upload your data?

Or is it “meh as long as it works”?

Every Stripe test card you'll ever need (plus fake checkout data for Shopify, WooCommerce & Magento)

Andrew Rozumny — Wed, 01 Apr 2026 23:14:29 +0000

If you're building or testing an e-commerce checkout, you've been there: opening the Stripe docs, scrolling for the right test card, copying it, then hunting for a fake address that matches the right country format.

I got tired of this. So I built a tool that generates everything at once.

But first — here's the complete reference you came for.

Stripe test cards

Success scenarios:

Card number	Type	Scenario
4242 4242 4242 4242	Visa	Success
5555 5555 5555 4444	Mastercard	Success
3782 822463 10005	Amex	Success
6011 1111 1111 1117	Discover	Success

Failure scenarios:

Card number	Scenario
4000 0000 0000 0002	Always declined
4000 0000 0000 9995	Insufficient funds
4000 0000 0000 0069	Expired card
4000 0000 0000 0127	Incorrect CVC
4000 0000 0000 0119	Processing error

3DS scenarios:

Card number	Scenario
4000 0025 0000 3155	3DS required
4000 0027 6000 3184	3DS recommended
4000 0000 0000 3220	3DS2 required

Use any future expiry date and any 3-digit CVV (4 digits for Amex).

Shopify Bogus Gateway

Shopify has a built-in test payment provider that doesn't need a real Stripe account.

Setup: Settings → Payments → Add payment method → Search "Bogus Gateway"

Card number	Result
1	Successful payment
2	Failed payment
3	Gateway exception

Use any name, any future expiry, any CVV.

WooCommerce test cards

WooCommerce with Stripe plugin uses standard Stripe test cards above.

Enable test mode: WooCommerce → Settings → Payments → WooCommerce Payments → Enable test mode.

Magento test cards

Magento 2 with Braintree sandbox:

Card number	Type
4111 1111 1111 1111	Visa
5500 0055 5555 5559	Mastercard
3714 496353 98431	Amex

CVV: 123, Expiry: any future date.

The part nobody talks about: fake addresses

Cards are easy. But you also need a realistic fake address that matches the country format — especially if your checkout validates postal codes.

US:

123 Main Street, Chicago, IL 60601

UK:

42 High Street, London, E1 2AB

Germany:

Hauptstraße 15, 10115 Berlin

Generating these manually every time is annoying.

Quick tips for checkout testing

Test the full flow, not just payment.
Most devs only test success. Your declined card handling is just as important — test that the error message is clear and the user can retry.

Always test 3DS separately.
3DS authentication adds a second step. Use card 4000 0025 0000 3155 to trigger it and make sure your UI handles the redirect correctly.

Test with guest checkout AND logged-in user.
These often have different code paths and different bugs.

The tool I built

I put all of this into one place — a free browser-based generator that gives you fake customer name, email, phone, country-specific address, and the right test card for your platform in one click.

Supports: Generic/Stripe, Shopify, WooCommerce, Magento, BigCommerce.
Countries: US, GB, AU, CA, DE, UA, JP.
Export as JSON or copy individual fields.

👉 tooldock.org/tools/ecommerce-test-data

Everything runs in your browser — nothing is sent to any server.

What's the most annoying part of checkout testing for you?

Claude AI Usage by Country: Israel Leads at 4.90x, Tanzania at 0.03x

Andrew Rozumny — Wed, 01 Apr 2026 21:47:53 +0000

Anthropic just released the Claude AI Usage by Country data via the
Anthropic Economic Index (sample: Nov 13–20, 2025).

The metric is simple: a score above 1x means a country's share of
Claude usage exceeds its share of the global working-age population.

🏆 Top performers

Country	Score
🇮🇱 Israel	4.90x
🇸🇬 Singapore	4.19x
🇨🇭 Switzerland	3.21x
🇰🇷 South Korea	3.12x
🇦🇺 Australia	3.27x
🇺🇸 USA	3.69x
🇨🇦 Canada	3.15x

📉 Lowest usage

Country	Score
🇹🇿 Tanzania	0.03x
🇲🇬 Madagascar	0.07x
🇲🇿 Mozambique	0.13x

What's interesting

Europe is surprisingly strong — France (2.66x), UK (2.59x), Ireland (2.39x), Norway (2.43x). Even countries like Poland (1.41x) and Greece (1.21x) are above baseline.
Asia is split — Singapore (4.19x) and South Korea (3.12x) are crushing it, while India (0.22x) and Indonesia (0.48x) are far below 1x.
Africa and Latin America are mostly sub-1x — likely a mix of pricing, language support, and infrastructure.
Japan at 1.59x — higher than I expected given the strong local AI ecosystem (Claude competes with domestic models there).

My take

The correlation seems to be: **English proficiency + tech sector density

GDP per capita**. Israel's dominance makes sense — massive tech industry, high English fluency, small population (so the ratio amplifies easily).

The really interesting story is what happens as Claude adds more
languages and local pricing — countries like Brazil (0.70x) and Mexico
(0.44x) feel like huge untapped markets.

Source: Anthropic Economic Index. Data as of Jan 15, 2026.

What's your country's score? Did anything surprise you?

English is now a programming language and I have mixed feelings

Andrew Rozumny — Sun, 29 Mar 2026 10:53:43 +0000

A few years ago if you said "just describe what you want and the computer will do it" — that was science fiction. Now it's Tuesday.

I spent last week building 40 browser-based developer tools. Half of them I described in plain English to Claude Code and it just... built them. Components, types, tests, the lot.

The weird part isn't that it works. It's how it feels.

There's this guilt developers know — the "am I even really coding?" feeling. Stack Overflow used to trigger it. AI just cranks it to 11.

But here's what I actually noticed: the thinking didn't go away. It moved. Less time on "how do I type this correctly". More time on "is this the right thing to build at all".

The English-as-code thing is real. But it's less like replacing programming and more like the abstractions keep going up. Assembly → C → Python → now this. Each step felt like cheating to someone.

Where do you draw the line between "using tools" and "not really coding"? Or is that even the right question?

I added 40 tools to my dev toolkit site in one week — here's what I learned

Andrew Rozumny — Sat, 28 Mar 2026 19:42:40 +0000

A week ago ToolDock had 20 tools. Today it has 60+.

Here's what I shipped, what broke, and what actually matters.

What I built

All tools run entirely in your browser. No sign-up, no server round-trips, no data leaves your device.

This week I added:

AI & LLM tools

Token Counter — count tokens before sending to GPT/Claude
LLM Cost Calculator — compare API costs across providers
MCP Config Generator — generate Claude Code config files
Cursor Rules Generator — .cursorrules for your stack
System Prompt Builder — templates for any LLM

CSS & Styling

CSS ↔ Tailwind converter
SCSS/LESS compilers (browser-based, no Node needed)
Tailwind CSS Cheatsheet with rem/px display

Developer utilities

.gitignore Generator
.env File Validator
Image Converter (PNG/WebP/JPEG, multi-upload)
Word Counter with Flesch reading score
chmod Calculator
JSONPath Tester
OpenAPI Spec Validator

What I learned

1. Browser APIs are more powerful than most developers realize

SHA-256 hashing, image conversion, SCSS compilation — all running client-side with zero dependencies.
Web Crypto API, Canvas API, and WebAssembly make things possible that seemed server-only two years ago.

2. Default values matter more than features

Tools with pre-filled examples get used immediately.
Tools with empty inputs get closed immediately.
Every single tool now has real, meaningful default data.

3. Tool chaining changes how people work

Added a "Send to →" feature that pipes output from
one tool directly into another. YAML → JSON Formatter
→ JSON Validator in one click.
People stay on the site 3x longer when they chain tools.

4. Smart Paste is underrated

Paste anything — JWT, JSON, SQL, cURL command,
Base64 string — and the site auto-detects the format
and opens the right tool. Sounds simple, surprisingly
useful in practice.

What's next

Still broken: LESS → Tailwind mapping (partial output)
Still ugly: Crontab Generator UI
On the list: JSON Schema from TypeScript,
HTTP Headers Reference,
More AI-powered explanations

Link: tooldock.org

What tools do you reach for daily that aren't there yet?

Your framework choice is now your biggest AI cost lever

Andrew Rozumny — Fri, 27 Mar 2026 11:01:14 +0000

The Wasp team published something worth reading today — they gave
Claude Code the exact same feature prompt for two identical apps, one in Next.js and one in Wasp, and measured everything.

The numbers:

Metric	Wasp	Next.js
Total cost	$2.87	$5.17
Total tokens	2.5M	4.0M
API calls	66	96
Output tokens (code written)	5,416	5,395

The last row is the interesting one. The AI wrote almost exactly
the same amount of code. But it cost 80% more to do it in Next.js.

The reason: cache creation and cache reads. Every LLM call re-reads the codebase context from scratch. A bigger codebase means every single turn costs more — not just for reading, but for loading into cache in the first place.

Next.js cache creation was 113% more expensive. Not because the AI did more. Because it had more boilerplate to read before it could start.

What this actually means

We've been evaluating frameworks on DX, performance, and ecosystem.
Add a new one: context efficiency.

How much of an AI's context window goes to signal (your business logic) vs noise (framework boilerplate)?

Wasp's declarative config means auth, routing, and jobs are defined in ~10 lines. Next.js equivalent is spread across middleware, route handlers, session files, and API directories. Same result, 4x the tokens.

The compounding problem

This test was a single feature. Real apps accumulate features. Every new route, every new model, every new API handler adds to the context that gets re-read on every single LLM call.

The performance degradation isn't linear either — research shows that AI performance degrades well before the context window fills.
You're not just paying more per call, you're getting worse output.

What to do about it

Measure your codebase token count now.
Run: find . -name "*.ts" -o -name "*.tsx" | xargs wc -c
That's roughly your AI cost baseline.
Audit your boilerplate ratio.
How much of that is business logic vs glue code?
The higher the glue ratio, the worse your AI economics.
Consider framework choices through this lens.
Wasp, Rails, Laravel — highly opinionated frameworks
have a new advantage they didn't have 2 years ago.
Less boilerplate = cheaper AI = faster iteration.

The irony

The same properties that make a codebase easy for humans to navigate — explicit, verbose, self-documenting — are exactly what's expensive for AI. The abstractions we used to see as "magic" are now genuinely economical.

I've been thinking about this for ToolDock — a browser-based
dev tools platform I'm building. Every tool page is pure business logic with almost no framework boilerplate, because everything runs statically. The AI token efficiency on it is noticeably better than client projects I've worked on with heavier stacks.

Worth checking the full Wasp post for the methodology details — they open-sourced both apps and the measurement scripts, which is the right way to publish a benchmark.

What's your current codebase token count?