Did 15 mins of digging in luel.ai's frontend. here's what i actually found.. copy/paste reproducible: (I’m confident they might take this stuff down after the post hence the video) 1/ counter on the page says ~606,000 contributors. their own shipped bundle has a fixed: meta:{total:71e3, distinct_countries:74, source:"user_profiles waitlist (country_code only)"} that's 71,000. their own data disagrees with their own counter by ~535k. 2/ same file hardcodes 86 per-country counts (IN:7876, JP:5025, ZA:4621, KE:4544, GB:4112, US-CA:2375…). they sum to 74,675. the source field literally calls it a snapshot of “waitlist users” not a live aggregate. a static export shipped to the client. 3/ the "live" heatmap is fabricated client-side: Each dot = cityCoord (Math.random()-0.5)*0.5 that's ±0.25° (~±25 km) of RNG jitter on a hardcoded city-coordinate table, regenerated fresh every page load. a second Math.random() seeds the WebGL shader dither. the "alive" feeling is pure animation. nothing is being fetched live. 4/ now the contributor counter itself. here's the actual display function from their bundle: function n(e){let t=Math.max(5e5,1e5*Math.floor(e/1e5));return `${Math.round(t/1e3)}K `} let o=n(5e5); Math.max(5e5, …) = hardcoded floor at "500K ". the widget cannot render below that no matter what value the backend returns. 5/ reproduce it yourself in 60 seconds: luel.ai/_next/static/chunks/… search for: Math.max(5e5,1e5*Math.floor or meta:{total:71e3 or distinct_countries 6/ what this proves from the client side: their embedded user total (71k) contradicts their displayed counter (~606k) the heatmap is fabricated with RNG, not live activity the counter widget has a 500K floor baked into the code 7/ok but the api endpoint returning the ~606k number ,surely THAT’s a real database read? no. it’s a function of unix time: count ≈ floor(constant 0.07048 × current_unix_seconds) i forecast the value 2 minutes into the future. landed within 2 of the actual returned number out of ~606,000. that’s 0.0003% error. statistically impossible from real signups..real user activity has variance, clocks don’t. responses come back with x-vercel-cache: HIT, frozen in 30-second cache windows. they’re not even hitting a database. it’s a cached time function served from edge. the “live counter” is a clock multiplied by a growth rate (~0.07/sec = ~6,089/day baked in). not a counter. 8/ what’s provable from the client side, no backend access needed: their embedded user total (71k) contradicts their displayed counter (~606k) the heatmap is RNG on top of a hardcoded city table, not live activity the counter widget has a 500K floor baked in the api endpoint is a deterministic time function, served from edge cache four independent layers of “fabrication”...