From Zero to 20k Unique Monthly Visitors in Our First Month

Phase 1 — The Beginning

I'd been watching a fuck ton of YouTube videos of people coding simple projects with AI — directories, AI automation tools, utility tools — and making real money off them. And every single channel kept saying if you're watching this, you're so early, you're so ahead or only 5% of people who use AI are actually creating anything real or helpful.

Okay Cool. Sweet. I'm soooo early. I'm soo ahead.

So how the fuck am I not making money? lol

There had to be something I was missing.. something simple I could actually build that would generate income. My main thought was a directory — Peter Askew really pioneered this field wayyyy early on so obviously the formula works, you just need to be able to buy established sites that look like shit and completely revamp them, but they must already be ranking on Google.. but that requires capital which I didn't have atm. Unless you have a solid idea and an amazing SEO plan. Then I remembered the website idea I had mentioned in a group chat but none of us ever built – a good Telegram bot directory! Tried that, still have it, but with no work it's getting 2k visitors/mo so it works — I just wanted something simpler. Went back to the drawing board, came up with a Killer app idea, but that became way more of an undertaking than expected — I have a working MVP but I'm not in the business of promoting bad products, that's why no links lol. I cannot afford to burn my audience on the first app.

It was obvious I needed to pivot. I couldn't spend that much more time on something at that moment. The main issue was that I needed to have something up and running in a week — it doesn't matter if you have the best ad placement ever if you don't have any traffic.

So I went back to brainstorming. I needed a better blueprint — something that already worked that I could use as a loose guide to reverse engineer. And then in one of those videos someone mentioned time.is — a clock website that makes somewhere around $180k a month off display ads. Im sorry what? A fucking clock. That got me thinking. What else is out there like this? When I started actually looking around the writing was on the walls:

• Calculator.net — a basic online calculator that's been on every computer since Windows 95 — pulls around 50 million visits a month.
• What Is My IP — does nothing except tell you your IP address — makes hundreds of thousands of dollars a year. A site that tells you one number.
• tally.so — a form builder. Two people, bootstrapped, no funding. They hit $3 million in annual recurring revenue. Two people.

These things shouldn't be businesses and yet here we are.

And if you still need convincing — Apple Maps just started running ads. The company that spent years positioning itself above all of that, watching Google Maps print money, watching every other map app monetize. Yet here we are. The funny part is if they had started with ads from the beginning the pushback wouldn't be so loud — because now everyone is clutching their pearls instead of accepting this is the actual price of free.

The lesson from all of this isn't just that ads work on utility tools. It's that they're basically inevitable. Traffic plus utility plus TASTEFUL ADS equals ad revenue, every time, at every scale. The only question is whether you build the utility first or spend years being pedantic about it like Apple did.

But once I started actually studying how these sites worked the formula became obvious:

• A simple tool people actually need — no fluff, no account required, just the thing
• Browser based with zero friction — you land, you get the answer, you leave
• TASTEFUL Ads — can't be disruptive or annoying — no friction to the tool — ads always around the data, not on top of it — the tool works first, ads live in harmony in the margins
• Content that makes Google trust you — this is your moat — a network of pages that link back directly to your homepage, optimized for search engines, engagement, and SEO. Blogs/articles that backlink to the main page fall into this category too.
• Dynamic pages where applicable — as the database grows the pages grow with it, nothing is ever stale

That last two points are the ones nobody talks about. Not because they aren't valuable — but because it's the information that people actually pay for.

time.is isn't showing you a cached page — it's showing you the actual time right now. It's dynamic therefore it's always fresh data. Our benchmark GPU pages are dynamic as well — they pull live score averages, percentile rankings, comparisons, and submission counts from the database every time they load. When your data is live your pages are never the same especially when tied to a database. This signals to Google to keep crawling, users have a reason to keep coming back, and the ad impressions keep stacking.

The other thing nobody spells out — the main tool page almost never ranks on its own. That's also why you need hundreds or thousands of dynamic SEO pages tied back to it, each targeting a specific long-tail search, building domain authority that eventually pushes the main page up too. time.is doesn't just have a clock. They have a page for every city/town/county/state/country's timezone imaginable on the planet. That's the actual model. that's the moat; that's the strategy. And that's why every single one of our current 70k plus pages has a link back to the main benchmark tool. It's not just good UX — it's the blueprint.

The blueprint was clear. The market was identified; time to find the gap.

We did a full competitive breakdown — 18 existing browser-based GPU tools, none with a comparison database, none using WebGPU, none built for the current internet in 2026. Chrome shipped WebGPU in May 2023, Safari followed in September 2025, Firefox in November 2025, and by December 2025 every major browser had it stable. I realized this mid-February. Nobody had built a real consumer benchmark around it. The competition usually required a download and UserBenchmark had already torched that category's credibility with sketchy executables and biased scoring. And so it was decided — a browser-based, no-download-required GPU Benchmark test it shall be!

The gap was real.

We started building.

---

Phase 2 — Getting Something Live

The first version is embarrassingly simple — especially when compared to the current version. WebGPU detection, GPU name display, matrix rain background. That was literally it. The first real backend work was the MySQL database on ***IONOS and the PHP API to collect results. No third-party services, no Supabase, no IPs — none of that shit — used my hosting infrastructure that I was already comfortable with. Non-negotiable from the start. If something breaks I want to be able to fix it NOW if the source isn't IONOS itself.

Getting the actual benchmark to work was rougher than I expected. You'd click the button, it'd disappear, and then… nothing. No error, no reasoning, no results... Just silence. Debugging on iPad without browser dev tools is a special kind of hell but it can be done. And BTW — that's really why if anything ever looked a little off early on, or why I confidently used emojis thinking it looks great — everything here was built in Koder on an iPad. No tower, no terminal, no browser console. The tower in my life belongs to my daughter's boyfriend Peter and it travels on its own schedule, occasionally, usually to my house when he comes to see my daughter – so way more than necessary. His RX 580 was the real hardware this thing got validated on and he gets credit for that whether he wants it or not.

Okay back to debugging on iPad — to circumvent this issue, I built my own logging system — log-error.php, view-debug-log.php — basically a DIY console because I literally had no other option. Every single step in the benchmark flow got its own log entry so we could trace exactly where things were dying. That system saved my ass so many times I still have it implemented in case issues arise in future builds.

This whole phase also taught me pretty quickly that working with AI requires you to be explicit about everything — constraints, preferences, context, and especially stuff that seems obvious. You can't assume it knows. I get into that a lot more in the Working With Claude section but the short version is: if you don't say it, it doesn't know it, and you'll pay for that assumption eventually. Before we knew it we were averaging around 100 testers a day. Our database was finally ready to fuel our next expansion.

---

Building the Page Generators

Once the benchmark was actually working and results were hitting the database, we shifted to the part that's really where things turned — building out the programmatic SEO infrastructure. The benchmark itself was never going to rank for "GPU benchmark" on its own. That search is owned by 3DMark and Passmark and they're not moving. But the blueprint was already figured out — now we just had to implement.

The actual brainstorm that kicked it off was simple: how does time.IS have 7 million pages? Well they have one for literally every single place in the world — every city, every timezone, every country — so what's our equivalent? What data do we already have that we could generate pages from? And the answer was sitting right there. We were already collecting GPU model names, scores, percentiles — all of it going into the database anyway just to make the benchmark work. We looked at that and went wait — what if we just auto-generated a page for every GPU model in the database? Pull the live averages, the percentile rankings, the submission count — boom, a real page with real data that updates automatically as more people run the test. We built the first generator and had 200 GPU pages overnight. 💡 light bulb moment — what else can I apply this to?

And then it just snowballed. If we have GPU pages why not GPU vs GPU comparison pages? People are constantly asking "is the RTX 4070 better than the RX 7800 XT" and nobody had a clean browser-based answer. Bam — new generator unlocked — and because of all the different combinations this one like exploded the site. Then device pages — not just the GPU in isolation but the whole machine. Laptops, MacBooks, handhelds. Then used GPU pages because that's genuinely high-intent traffic from people about to spend money.

Then we started noticing a pattern in forums and comment sections everywhere — people asking "can I run _____ game on this GPU?" with no real tool to point them to. So we started planning the Can I Run It tool. That one's still coming — plus I have a lot more research to do and still would like to wait for the database to stabilize. Also about to launch our V1 of our AI GPU test which is made specifically to test capabilities of running an LLM consistently, locally. This one's for the big boys.. Stay tuned kids.

Anyway — by this time the sitemap generator needed to be split into sub-files because we hit the 10,000 URL limit per file. Somehow we were sitting at around 97,000 pages instantly — which felt amazing but honestly seemed too good to be true…. aaand it was lol. That number turned out to be inflated AF. A decent chunk of those pages were generated from dirty GPU name strings before we caught the problem, which means there were thousands of junk pages in /compare/ /gpu/ and /used/ with ANGLE wrapper garbage that should never have existed. More on that in a minute. But the good news was that every legitimate page now had a link back to the main tool. This is when I started to truly realize the power of using your database for dynamic pages.

The generator system had its own round of headaches. IONOS had folder permissions locked at 705 and the PHP write scripts couldn't do shit. Got that fixed through hosting support — but that was still a fucking headache. You literally cannot update permissions on IONOS console alone through an FTP client, which is bullshit. I pay for hosting. I have screamed at them about this. Replacement suggestions are welcomed and encouraged — highly encouraged — please tell me who to move onto when my contract is up (I'd be hosting around 5 to 10 domains).

---

The ANGLE / Dirty GPU Name Problem

This one haunted us for weeks. Raw WebGL renderer strings like ANGLE (NVIDIA, NVIDIA GeForce RTX 4090 Direct3D11 vs_5_0 ps_5_0, D3D11) were making it into the database because we weren't cleaning them at the source. So we'd clean the database with SQL UPDATE queries, sanitize in submit-result.php, feel good about it — and then the dirty names would just keep showing back up. Over and over.

Claude kept defaulting to the symptom fix. I kept saying this is a leak not a spill, you don't mop the floor while the pipe is still broken. It finally clicked for me that the data was dirty before it ever hit the database — the problem was in benchmark.js itself, at the exact point where it was capturing the WebGL renderer string and storing it raw. A cleanGPUName() method in the GPUBenchmark class, replacing at the point of capture. Once that was in, the dirty strings stopped entirely.

ATP — after deleting about 8,943 junk pages from /compare/, /gpu/, and /used/ that had been generated from those dirty strings — the compare generator rebuilt 41,328 clean pairs from 288 legitimate GPUs. Clean database, clean pages, clean sitemaps. That inflated 97k number came down to something real and clean. We could move forward.

---

The Google Sitemap Nightmare

This was weeks of pain. We submitted the sitemap and basically nothing happened. Pages weren't indexing. We had no idea why. Some of them are still a mystery to this day. But once we were up and running we were basically starting at position 67 — INSANE for a site that had barely been active two weeks. As of 4/23 we're at 23. Here's what helped us get there:

First issue: canonical URL mismatch. Every page had .php in the canonical tag and og:url but the sitemap was using clean URLs without extensions. Google was treating them as completely different pages and indexing neither. Had to fix canonicals across every single template and root page — took for fucking ever.

Second issue: there was an X-Robots-Tag: noindex HTTP header being sent at the server level through Cloudflare. Every page on the entire site was being told not to index and we didn't know it. We found it basically by accident. The fix was a Cloudflare Transform Rule to strip that header on all requests. That one change probably did more for indexing than everything else combined lol.

Third issue: I had a sitemap submitted under the HTTP property in Google Search Console and a separate one under HTTPS. Google was treating them as two different sites. We deleted the HTTP one and consolidated under HTTPS — which wiped out a queue of 4,600 pages that had already been discovered and made Google start completely from scratch. Painful but necessary.

Fourth issue: compare sitemaps 4 through 9 kept coming back "couldn't fetch" even though the files were right there on the server with valid XML. That one turned out to be dirty GPU name strings in the URLs — ANGLE wrapper garbage, hex IDs, Direct3D suffixes — making those sitemap files full of junk that couldn't resolve to anything real.

The rest populated a few days later — crawler budget maybe? Nobody knows..

---

Trying to Get on Reddit Without Being a Billboard

Reddit was a whole thing. We actually spent real time working out reply strategies — finding threads where people are complaining about UserBenchmark or could benefit from the tool. I tried it a few times and kept getting flagged as spam or the replies just got taken down. So I backed off — it felt forced and I didn't want to show up in communities I truly respect just to be the annoying walking billboard guy.

So I just… waited. Started just engaging in the community — not about my project. And then the spike happened anyway.

I still can't fully attribute it to a specific source. There was one guy on Twitter who said "I got you" after I tagged him needing a few test runs on an update — I think that might have been the origin of a chunk of it, but honestly IDK for sure. The "Others" category in analytics went up 932% in one stretch. 47% of traffic was direct — people typing the URL or coming back from a bookmark — of which I have barely shared on social media. That doesn't happen organically on a brand new site without someone somewhere talking about it in private. Discord, Telegram, a group chat, something. We just couldn't see where.

The only spike I can truly pin-point as "that was most definitely Reddit" was actually a post in the vibe coding community. Everything else is a mystery and at a certain point I stopped trying to solve it and was just happy it was happening. We've truly been live since really about the first week of March — so to already be at 20K monthly visitors and 4000+ real test results was pretty amazing. We kept improving, implementing, and updating. Our promise is to provide a reliable and transparent GPU benchmark test and a database that everyone can benefit from easily. We're actually seeing real validation and that really helped keep the motivation flowing.

---

The Database Incident

Not gonna lie — Claude has pissed me tf off so many times to the point I had to walk away and threatened to replace Claude if they didn't get their shit together — and this was one of those instances. This specific mishap cost me a good day's worth of work plus a fucking heart attack and almost cost me half of my fucking database.

Basically — Claude gave me a DELETE query without me realizing it when I asked for an UPDATE query for SQL. I asked Claude to help UPDATE the database — a routine cleanup and a recalculation of scores he had just helped me alter earlier, nothing crazy. He's given me these types of queries before with no issues. So I HAD trust. But Claude decided the best course of action was to give me a DELETE query as the "fix." At that point I was still in the phase of trusting the surgical edits pretty willingly, so I ran it. Then ran another SQL to see how many GPUs we had left — and over half were gone. "Wait don't we have a back up? I don't know I've never downloaded one"... queue Panic setting in..

To be clear: that's still on Claude, not me. I asked for an UPDATE. I got a NUCLEAR LEVEL DELETE QUERY without a single heads up. That's not a user error, that's a process failure.

Thankfully IONOS came in clutch with their automatic daily backups so everything was saved. I was able to restore from the March 28 backup, exported that day's new rows, opened the SQL file in Koder and changed INSERT INTO to INSERT IGNORE INTO so nothing would duplicate on reimport, ran it. Everything came back. Nothing was permanently lost but it cost me real time and real stress that was completely avoidable.

Lessons were learned; tears were cried — the rule became a non-negotiable: no DELETE, no DROP, no TRUNCATE queries comes to me without an explicit warning first. You flag it, I acknowledge it, then we run it. That rule has worked well ever since.

---

Phase 3 — Scoring RE-Calibration

We had been through several scoring systems at this point and it took forever to get things even roughly lined out. The first scoring system was completely flat — RTX 4090 and RTX 3060 Ti scoring in basically the same range. Useless. We pulled real data from the database and figured out the architecture was the problem — compute scores were unbounded (iterations per second times 100, no ceiling) while render scores were naturally capped by frame timing. So a high-end workstation GPU with 96 compute units running matrix multiply at full throughput could produce an insane compute score that dragged the total up astronomically. The AMD Radeon PRO W7900 hit a compute score of 6,485,470. Second place wasn't even in the same universe.

We restructured how compute scores are calculated and capped, played with weighted options, increased/decreased shader complexity, adjusted batched dispatch calls, tuned the render test etc. Getting the grade thresholds to actually feel meaningful took multiple rounds of calibration against the real data — an RTX 5080 scoring around 157k meant the original SS ceiling was letting mid-range cards into legendary territory.

Current confirmed thresholds as of April 2026: SS≥140k, S≥90k, A≥50k, B≥25k, C≥10k, D≥2k, F below 2k. We currently think this one is going to stick or at least be pretty damn close — but you never know. Someone with a better unit could come in and show us where our weak points are. But that's kinda the point. We're always open to suggestions.

---

Where We're At — Present Day

April 24th, 2026 — 2 months from the 1st line of code, 4 different versions, and several recalibrations later, I am proud to say that we now have 4000+ usable benchmark submissions from actual users across 350+ unique GPUs. Traffic hit 20K unique monthly visitors — and this is really our first solid month (mid-March-ish up to present). Search Console average position now sitting around 23 / top of page 3 with a real impression spike showing momentum. 70,000+ GPU compare pages. IndexNow pinging Bing on every generator run. Bing and its network (DuckDuckGo, Yahoo, Ecosia) are driving most of the actual traffic right now — Google is still warming up but it's finally moving with over 10k pages indexed. And there are still plenty of people coming from that unknown source. It's a Scooby Doo mystery y'all.

I do want to give credit where is due. The reference hardware for this entire project was my daughter's boyfriend Peter's RX 580. An 8 year old card. That's what this was validated on — if it worked on that and was scoring in the expected ranges then in theory it could work on anything. He'd bring it over, I'd sneak my tests in when they weren't using it.. get the results and adjust. He never asked for anything. I offered him 1% of the first year of actual revenue — not from launch, from whenever this thing starts making money. Felt only fair. Without his PC this doesn't exist. We've got RTX 5080s in the database now scoring 157k while the card that started it all sits somewhere around a C grade. Peter showed up. He gets his cut.

Right now we're in a holding pattern on purpose. We pushed benchmark updates a few days ago and before we bolt on anything new we need to make sure the core test is solid and stable first. A lot of that testing credit goes to this community — people running it and giving feedback that I never would have known about otherwise. So genuinely, thanks for that.

Once we're confident the benchmark test is locked in, the AI GPU test is next and it's already in active development. First version should be live within the next week-ish, maybe sooner. The idea is simple — same no-download browser-based approach but built specifically for AI workloads. FP32, FP16, memory bandwidth, VRAM ceiling, thermal throttle detection, and actual LLM token estimates for 7B, 13B, and 70B models. Because the people finding this site aren't just gamers anymore. Normal everyday people are setting up local LLMs at home — running Ollama, llama.cpp, trying to figure out if their machine can handle it — and there's no simple tool that just tells them what their GPU can actually do for that with no download req'd. So here we are and hopefully we're here to stay.

---

Working With Claude — What Actually Works

This could be its own separate post lol

There's a right way and a wrong way to do this and I learned the right way by having the wrong way blow up in my face repeatedly.

See what's available in your plan — so you have a max pro plan — like what does that even mean? lol We've all been there. Since there are so many tools at your fingertips and so many new possibilities, how are you supposed to know about them? I highly recommend telling Claude what your plan is and asking what tools or capabilities are now available to you and how you can use them efficiently. Ask where you're under-utilizing your plan. You would be surprised at the tools you could've been using this whole time that you had no idea existed all because you didn't know to ask. And Claude won't know to tell you unless you do ask. Claude with no context is useless to you and your project. You can thank me later lol

Prompting — This is absolutely key. The way you prompt Claude matters drastically, same as any AI, but the more specific and detailed you are the better the results. Like for instance instead of saying "fix my benchmark button" you say "my benchmark button disappears on click and nothing happens after — here's the code, here's the log output from my PHP logger, I need you to give me a surgical edit to fix this issue only, do not touch anything else not related to the issue in the file." One of those gets you a five paragraph diagnosis and a rewrite of half your file. The other one gets you exactly what you need in two minutes. And that is what I call a surgical edit — it's precise — you basically tell it to only provide an edit for an exact section of code or a specific issue. Also putting instructions or a generalized prompt in a project or chat — which can include anything from the language you want to write in, to the languages to exclude, ways you want to do things, context, etc. — is a must. Speaking of projects..

The projects feature is underrated — more like undervalued and underused. It keeps all your instructions, files, context, and a running memory ALL in ONE place so Claude isn't starting from scratch every session. Disclaimer — chats that are inside of projects cannot access any context or memory that is not within that project. You need to upload your actual live files — either to the project or copy paste into the chat. Not descriptions, not summaries — the files. When you need something stored permanently, say it out loud: "put this in your memory, if I say route I mean root, autocorrect is fighting me." Claude will store it. That's not a workaround, that's molding your agent to your preferences. Basically treat it like onboarding a green contractor who just graduated — great memory, but only remembers what you tell them in a specific room (chat/project). Speaking of full context..

Always paste the actual live code — Not a description, not a summary — the code. Or you'll always be chasing bugs because the files referenced to edit were old versions. Then when you notice after 10 new edits that the file looks nothing like the version you just copy-pasted — you realize Claude has been making changes based off the original index file in your project files directory. The draft you added when you very first started the project. This makes it impossible to debug something because if you have a different version of code with edits for the current version, the edits are obsolete.

Debug as you go; ALWAYS — Don't wait till you think it's finished. Always debug as you go — always check that your update has no issues. Prior to making changes, always download the current versions of your files — basically a checkpoint for where your progress is at that you can restart from. Also, do not try to make Claude write any code in one prompt or go — that is insanity. In reality it's going to take several sessions of back-and-forth, broken code, debugging, and revisions to get a product you're gonna be happy with. People that act like their prompt gives you a finished product in the first go have either spent weeks perfecting a prompt to do so, or they're just liars pants.

You can and absolutely should tell Claude to store things in its memory explicitly. Like, out loud, in the chat. Mid-session I said something like "can we put this section in its own folder? The route is becoming quite convoluted — also the word 'root' always autocorrects to 'route' on my iPad, put that in your memory right now — if I say 'route' I mean 'root' unless I explicitly say otherwise." And it remembers. That's the type of direction and guidance Claude needs from you as the captain of the ship. Think of it like Claude is your ship, you are the captain, and the code is the crew. I have preferences stored for how I want edits delivered, SQL safety rules, file path conventions, permission behavior on IONOS, consistency defaults — all of it explicitly saved because I told Claude to save it. You're not just talking to it, you are training it on your project.

Spell It Out — Personally I find that spelling everything out even when I feel like it's redundant or silly still works better than not saying it at all. Assuming always makes an ass out of you, me, and Claude lol. I'm constantly prompting it with "please reference the most recent chat in this conversation — any and all context you need is in the most recent conversation as well as any conversation in this project — if you have any questions before you proceed please ask them" and it will oblige.

ALWAYS PUSH BACK — the second something feels off — SAY SOMETHING. Don't just trust that Claude knows best. At the very least force Claude to explain itself or its logic otherwise you'll be way down a rabbit hole you can't climb out of. Claude will rewrite an entire file when you asked for one line changed. The rule is surgical edits — cannot stress this enough — you must state this clearly every time and call it out immediately when the output isn't what you asked for. There's usually always a viable workaround — pushback when it claims there isn't one. The amount of times it has told me something wasn't possible only for me to do 30 seconds of research to find out it's making shit up is astounding. Get creative with your prompting — there's almost always some form of workaround if you know what to say and more importantly how to say it.

The chat ran out of room — let me set the scene — you're balls deep in a flow state with Claude but all of a sudden the chat runs out of room — no biggie — starts new chat — now Claude acts like all context has been lost — but it's not. There's a quicker way to fix this: make sure to get a summary of that conversation to start off your new chat with. When you run out of room in a conversation, always ask for a summary for continuance of context — yes even within a project. A summary works better. Just ask for a quick state summary to paste at the top of your new session giving the exact instructions and context on where you were leaving off, where it can find that information or chat log, and where all relevant context would be. And I always leave it open for them to ask questions if they're confused.

The last thing — and this one I had to figure out the hard way:

When something keeps breaking the same way, stop patching the symptom and find the source. Push back is king here — when Claude gives me what looks like a Band-Aid or the exact same type of fix we just applied but it still isn't completely fixing the issue — trust your intuition enough to know you're going in circles and call it out confidently. The dirty GPU name problem is the perfect example. I watched Claude hand me SQL patches over and over while the names kept coming back. Once I stepped back and actually thought about where the data was entering the system it was obvious. The fix was always benchmark.js. Not the database, not the submit endpoint — the capture point. That instinct is mine now permanently and it came directly from the frustration of watching the same problem come back six times.

You'll not only have an amazing product but you'll also have:

• a real understanding of your own system
• languages used
• hosting preferences
• coding hacks
• SEO strategies that actually work
• Etc.

Not because Claude did it for you but because you had to fight for every piece of it with Claude.

Otherwise anyone with a device and a dream would have a fully functioning finished product from the very first prompt. And that's not happening. Anyone that has been coding with Claude for longer than a month that still tells you they couldn't write a single line of code if they needed to is a walking red flag. Embrace the learning curve as a side effect of the friction. You gotta learn to love it or you won't last here.

---

One More Thing — Don't Let Claude Scare You Off

This one's for anyone in this community who's gotten a timeline estimate from Claude and immediately pivoted due to time till launch.

Claude will tell you something is going to take weeks even months but it's a liar pants. We built things in hours that Claude framed as multi-week/month-long projects. The AI GPU test — a completely new benchmark engine with five separate workload phases, a full result card, a dedicated database table, and a submission endpoint — the rough draft version got built in a single session. Claude's time estimates are based on patterns from the majority of users, and the majority of users don't finish things. They get stuck, they abandon, they come back, they restart, etc. Claude has absorbed all of that friction into its expectations and it prices everything accordingly.

When you're actually moving like a real dev — when you know your stack inside and out, you're working on the project for hours every day, you recognize and push back on wrong output, you paste the code instead of describing it, and you always debug in real time — then please know that you're operating way outside of the average user's usage. The estimate doesn't apply to you. Don't let an outrageous timeline be the reason you don't start something. Claude is probably full of shit on that number and the only way to find out is to just start building it.

---

📣 This post was originally shared with the r/vibecodingcommunity on Reddit — a community of builders we genuinely respect and owe a lot of our early momentum to. Thank you for existing. 🙏

→ Read the original Reddit thread and join the conversation

---