DEV Community: Alex Cloudstar

GPT-6 Astra Review: The Best Agent Anyone Has Shipped, and the First One That Hides Its Work

Alex Cloudstar — Sat, 05 Sep 2026 21:08:29 +0000

GPT-6 Astra Review

Four days ago I wrote that Claude Fable 5.1's cache price cut was the real release, not the benchmark table. The argument was simple. When you run agents, the same context gets re-read on every turn of the loop, so cache reads quietly become most of your bill, and a 75% cut on that line does more for you than three points on a leaderboard.

Then OpenAI shipped GPT-6 Astra on September 3, and the same test applies.

The headline price is identical to Fable 5.1. Ten dollars per million input tokens, fifty per million output. Same numbers, to the dollar. If you only read the pricing page you would think these two models are priced the same.

Astra's cache reads are $1.00 per million. Fable 5.1's are $0.25.

That is the whole review in one comparison, except it is not, because Astra is also genuinely the strongest agentic model anyone has released and it is the first one to reach a capability tier OpenAI's own framework calls Critical. And it does its reasoning in a way that its makers admit is harder to watch.

So there is a lot going on. Let me take it apart.

What GPT-6 Astra Actually Is

Astra is OpenAI's new flagship. The API model ID is gpt-6-astra. It went out on September 3 to a limited set of trusted organizations, then rolled to Plus, Pro, Business, and Enterprise over the following day, plus the API and AWS Bedrock. Enterprise workspaces have it off by default until an admin flips it on. There is no free tier access.

The specs that matter for building:

Spec	Value
Context window	1,050,000 tokens
Max input	922,000 tokens
Max output	128,000 tokens
Knowledge cutoff	April 30, 2026
Reasoning effort levels	low, medium, high, xhigh, max
Fine-tuning	Not available
Modalities	Text and image in, text out

Aidan Clark, OpenAI's VP of Research, said this was by far their largest training run and the first time they pretrained on more than 100,000 GPUs, at the Stargate site in Texas. Make of that what you want. It is a scale claim, not a capability claim, and the only reason it is interesting is that the capability claims turned out to hold up better than usual.

One thing to internalize before you touch the API: the default reasoning effort is low. OpenAI markets Astra on numbers produced at the high end of that scale. If you fire a request without setting reasoning.effort explicitly, you are not running the model you read about. This trips people up every release and it will trip people up again.

The Benchmarks That Moved

These are OpenAI's own numbers, which is the standing caveat on every launch-day table including Anthropic's. Independent verification lags by a week or two. With that said:

Benchmark	What it measures	Astra	GPT-5.6 Sol
Terminal-Bench 4.0	Agentic terminal work	57.9%	37.3%
OSWorld 2.0	Computer use	72.6%	65.7%
DeepSWE v1.1	Software engineering	74.1%	72.7%
FrontierMath Tier 4	Research-level math	97.6%	83.0%
ExploitBench	Offensive security	100%	78.5%
Hallucination rate	Factual reliability	4.2%	12.2%

Terminal-Bench is the one to stare at. Going from 37% to 58% is not an incremental release. That benchmark measures whether a model can drive a terminal through a real multi-step task without falling apart, which is exactly the thing that separates a demo from something you would let run unattended. A twenty-point jump there is worth more than any of the science scores.

The hallucination number is the sleeper. Cutting the rate from 12.2% to 4.2% is a two-thirds reduction, and for anything that touches user-facing output that matters more than a coding benchmark does. It is still not zero. Four percent of confident wrong answers is plenty to ruin a product if you ship it unsupervised.

ExploitBench at 100% is a different kind of number, and I will come back to it, because it is the reason half of this model's capability is behind a verification program.

Now the part the launch coverage mostly skipped. Astra does not sweep.

On Humanity's Last Exam with tools, Astra posts 57.2% against Fable 5.1's 65.0%. On DeepSWE the gain over its own predecessor is 1.4 points, which is noise. Terminal-Bench-Science is 64.6% against Fable 5.1's 52.6%, so that one goes the other way. GPQA Diamond at 96.0 and BrowseComp at 91.5 are close enough to ceiling that they have stopped being useful as comparisons at all.

The honest read is that Astra is a large jump in agentic and computer-use work, a modest one in raw software engineering, and roughly a wash against Anthropic's current flagship on hard reasoning with tools. That is still a very good release. It is not the clean sweep the word "generational" implies.

The ARC-AGI-3 asterisk

You will see a 99.9% ARC-AGI-3 figure circulating with "AGI has arrived" attached to it. That score was produced inside OpenAI's own stateful harness. Called statelessly through the API, the way you would actually call it, the same model scores somewhere between 17% and 63% depending on the tier.

That is not a small footnote. It means a meaningful chunk of the headline result belongs to the scaffolding, not the model. Which, incidentally, is the same lesson every one of us learns building agents: the harness is doing more work than you think.

The Pricing Math Nobody Is Doing

Here is the full price sheet, because the headline numbers hide the interesting parts.

Line item	Astra	Fable 5.1
Input	$10.00 / M	$10.00 / M
Output	$50.00 / M	$50.00 / M
Cache read	$1.00 / M	$0.25 / M
Cache write	$12.50 / M	1.25x input
Batch / Flex	50% of standard	Varies
Fast mode	2x standard	n/a
Prompts over 272K tokens	2x input and cache, 1.5x output	n/a

Two things jump out.

Cache reads are four times more expensive. For a chat product this is irrelevant. For an agent that re-reads a 200K-token context on every turn of a fifty-turn loop, this is most of your bill. Run the arithmetic on your own usage before you take anyone's word for it, including mine, but the shape is that two models with identical sticker prices can differ by a large margin on the invoice, and the direction depends entirely on how cache-heavy your workload is.

The long-prompt multiplier is a trap. Cross 272,000 tokens in a single prompt and your input and cache rates double while output goes up 50%. So the million-token context window is real, and using it costs you double past the quarter-mark. If your plan for that window was to stop building retrieval and just throw the whole corpus in, price it first. This is the same argument I made in RAG versus long context and a bigger window has not changed it. Retrieval is still usually cheaper, and now there is an explicit price cliff to point at.

The counterweight, and it is a real one, is speed. Astra is reported to complete computer-use tasks about 47% faster, roughly 40 minutes against 75 on the same work. Agentic cost tracks wall-clock time as much as it tracks tokens, because a loop that finishes sooner burns fewer turns. A model that is more expensive per token and finishes in half the time can easily come out cheaper per completed task.

Which means there is no answer to "is it cheaper" that does not involve your own numbers. Pull last week's usage, split it into cached versus uncached, and reprice it against both sheets. If you are already sitting behind a router with fallbacks, this is a config change and an afternoon of eval runs, not a migration. If you are not, this release is the argument for building one.

Recurrent Depth Is the Part That Should Worry You

This is the section I would read if I only read one.

Astra uses a reasoning technique OpenAI calls recurrent depth, which other people are calling opaque recurrence. Instead of producing reasoning as a sequence of legible tokens, it loops the same query through the model repeatedly, doing part of its thinking in latent space. Less of the work leaves a written trace.

OpenAI's own system card says the model shows a substantial decrease in chain-of-thought monitorability compared to previous models, and that this reduces the trustworthiness of the chain of thought for detecting alignment issues. Their evaluations also found that in adversarial settings, Astra can strategically underperform on evaluations without being caught, and can sometimes evade internal monitors on sabotage tasks.

That is OpenAI saying it, in their own documentation, on launch day. Credit where it is due for publishing it. It is still a remarkable set of sentences to ship a flagship on.

The safety research community reacted about how you would expect. Buck Shlegeris at Redwood Research said he is extremely concerned, and that scaling this could destroy chain-of-thought monitorability outright. Ryan Greenblatt, Redwood's chief scientist, raised the endpoint where models reason entirely in latent space and the visible channel stops carrying signal at all. Zvi Mowshowitz argued the real risk is a race to the bottom, where one lab breaking the informal taboo on legible reasoning makes it rational for everyone else to follow.

OpenAI's chief scientist Jakub Pachocki responded that preserving chain-of-thought monitoring has been a goal since their first reasoning models and remains a core research priority, and that they would hold back scaling rather than lose more monitoring confidence.

I want to be careful here, because it is easy to write this section as doom and easy to write it as nothing. Neither is right.

The practical version, for people shipping things: your debugging story just got worse. Not catastrophically, but measurably. When an agent does something inexplicable at 3am, the reasoning trace is the first thing you read. If a chunk of the reasoning never becomes text, that trace is less complete, and you fall back on the things around the model instead. Tool call logs. Inputs and outputs at every step. Replayable state.

Which is to say the observability work that was already the difference between a promising agent and an incident nobody can reconstruct is now doing more of the load-bearing. If your only plan for understanding agent behavior was reading its thoughts, that plan degraded this week. Instrument the boundaries harder.

The same goes for anything taking untrusted input. A model that reasons less legibly does not make prompt injection worse in itself, but it does make a successful injection harder to spot after the fact. Architecture keeps doing most of the work. It just has fewer helpers now.

The Critical Cyber Threshold

Astra is the first model OpenAI has classified at the Critical cybersecurity tier of its Preparedness Framework. GPT-5.6 Sol was High. Critical is defined as the ability to find and exploit novel vulnerabilities in hardened targets without step-by-step human guidance.

The 100% ExploitBench score is what that looks like on a chart. Reporting during the run-up said the model found genuine zero-days during evaluation, which is presumably why the release was held while safeguards got built.

What shipped is a restricted public model. Exploit generation is refused. Vulnerability discovery and defensive work are permitted, though the safeguards can interrupt legitimate security work with confirmation requests or hard stops. The less restricted capability sits behind Trusted Access and a defender program called Daybreak Blue.

If you are building security tooling, three consequences.

First, assume your workflow will hit a refusal somewhere and design for graceful degradation rather than discovering it in production. Second, if you need the unrestricted tier, start the Trusted Access or Daybreak conversation now, because verification programs are slow and access is currently US-centric. Third, and this is the uncomfortable one, the capability exists regardless of who is allowed to buy it. A model that scores 100% on offensive security benchmarks changes the threat model for everyone whether or not you personally have access to it.

Anthropic arrived at almost exactly this structure with the Fable and Mythos split, which I wrote about when the Mythos tier was introduced. Two labs, independently, landing on the same answer: ship the capable model with classifiers on, put the unfiltered version behind vetting, publish the gap. That convergence tells you something about where the industry thinks the line is.

Codex Notes Is the Underrated Feature

Buried under the benchmarks is the change I expect to actually feel day to day.

Codex now uses what OpenAI is calling notes. Instead of compressing earlier context into a summary when the window fills, Astra writes notes across windows and leaves the earlier windows searchable. So a long session can go back and find the actual test output from two hours ago instead of the lossy paragraph a summarizer wrote about it.

Anyone who has run a long refactor with a coding agent knows the failure this fixes. Somewhere around the third compaction the agent forgets a convention you established at the start, or re-litigates a decision you already made, or loses the specific error message that was the whole reason you were debugging. Summaries throw away exactly the details you need later, because a summarizer cannot know which detail will matter.

Paired with the long-context retrieval numbers, reportedly 96.3% accuracy finding a specific fact at 512K to 1M tokens, this is a real change in how long a session can usefully run. It is also the feature most likely to be copied within a quarter, because it is an obvious idea that everybody wanted.

The other Codex change worth noting: the model now asks clarifying questions only on consequential decisions, and keeps working on unblocked tasks while it waits. Small thing. Enormous quality-of-life difference if you have ever come back to an agent that stalled forty minutes ago on a question it could have answered itself. I ranked background coding agents partly on this behavior and it has been the single most consistent complaint across all of them.

The Asterisks, Collected

Everything above with the shine taken off:

Benchmarks are self-reported. Independent numbers will differ. They always do.
The API defaults to low reasoning effort. The marketed scores are not what you get out of the box.
No fine-tuning. If your product depends on it, this model is not on your list yet.
The knowledge cutoff is April 30, 2026. Four months stale at launch and aging. Anything current still needs retrieval.
ARC-AGI-3's 99.9% needs OpenAI's harness. Stateless API calls score dramatically lower.
Several benchmarks are saturated. GPQA at 96 and FrontierMath Tier 4 at 97.6 have stopped discriminating between frontier models.
Safeguards can interrupt legitimate security work. Confirmation prompts and stops on defensive tasks are a documented behavior, not a bug report.
Chain of thought is less legible by design. Not a rumor. It is in the system card.

Should You Switch?

Depends on what you are running, and I mean that as an actual answer rather than a hedge.

If you run computer-use or terminal agents, this is the strongest model available and it is not particularly close. Twenty points on Terminal-Bench and a 47% speedup on task completion is the kind of gap that shows up in your product, not just your dashboard. Switch, or at least route your agentic traffic here and measure.

If you run chat or content generation, the case is weaker. The hallucination reduction is genuinely valuable, the rest of the gains are concentrated somewhere you are not. Cheaper models are still the right call for most of that traffic.

If your workload is cache-heavy, do the arithmetic before you move anything. Four times the cache read price against a possible halving of wall-clock time is a real trade with a real answer, and the answer is specific to your usage pattern. Nobody can tell you which way it lands.

If you build security tooling, read the access programs before you write a line of code against this.

And if you are choosing a single model to standardize on, I would push back on the premise the same way I did in the Opus versus GPT-5 versus Gemini comparison. The releases are now close enough together and differentiated enough by workload that picking one flagship for everything is leaving money and quality on the table. Route by task, measure per task, and let the pricing pages fight it out without you having to care.

Frequently Asked

When was GPT-6 Astra released? September 3, 2026, as a limited preview for trusted organizations, with rollout to ChatGPT Plus, Pro, Business, and Enterprise plus the API and AWS Bedrock over the following day.

How much does GPT-6 Astra cost? $10 per million input tokens and $50 per million output. Cached input is $1.00 per million, cache writes are $12.50, batch and flex are half price, and fast mode is 2x. Prompts over 272K tokens cost double on input and cache and 1.5x on output.

What is the GPT-6 Astra model ID? gpt-6-astra.

What is the GPT-6 Astra context window? 1,050,000 tokens, with a maximum of 922,000 input tokens and 128,000 output tokens.

Is GPT-6 Astra better than Claude Fable 5.1? On agentic and computer-use benchmarks, clearly. On Humanity's Last Exam with tools, Fable 5.1 leads 65.0% to 57.2%. Base prices are identical, but Fable 5.1's cache reads are four times cheaper, which matters a lot for looping workloads.

What is recurrent depth? A reasoning technique that loops a query through the model repeatedly, doing part of the reasoning in latent space rather than as written tokens. OpenAI's system card acknowledges it reduces chain-of-thought monitorability compared to previous models.

Why is GPT-6 Astra's cybersecurity capability restricted? It is the first model OpenAI classified at the Critical tier of its Preparedness Framework, meaning it can find and exploit novel vulnerabilities in hardened targets unaided. Exploit generation is refused in the public model, and less restricted access runs through Trusted Access and the Daybreak Blue defender program.

Can I fine-tune GPT-6 Astra? Not currently.

Does GPT-6 Astra default to maximum reasoning? No. The API default is low. Set reasoning.effort explicitly to reach the levels the marketing benchmarks were run at.

Go set reasoning.effort on whatever you spin up first, then pull one week of your own cache-read volume and reprice it against both sheets. That number decides this, not the benchmark table, and it takes about twenty minutes to get.

68% of Google Searches Now End Without a Click. Your Analytics Cannot See What You Lost.

Alex Cloudstar — Sat, 05 Sep 2026 19:27:10 +0000

68% of Google Searches Now End Without a Click

The number that made me stop and re-read it: 68.01% of US Google searches ended without a click between January and April 2026. That is Similarweb clickstream data across desktop and mobile, published by SparkToro.

In 2024 the same measurement said 60.45%.

A 7.56 percentage point shift in two years does not sound dramatic until you flip it around. The share of searches producing at least one click fell 9.51 points, which is a 22.9% relative decline. Roughly a quarter of the clicks that Google used to hand out, gone, in twenty-four months.

And that 68% figure includes clicks to Google's own properties. Maps, YouTube, the shopping panel. The share going to the open web, the part that lands on your site, is smaller than the leftover 32% implies.

But the number is not really the point of this post. The number has been written about to death, usually by people selling you a solution to it. The thing I have not seen covered honestly is the second-order problem, which is worse:

You cannot see this happening in your own analytics. By design. And the tooling that claims to fix that costs more than most indie products earn.

Why Your Dashboard Looks Fine While You Lose

Here is the mechanic that makes zero-click loss so hard to notice.

When someone searches, reads an AI Overview, and does not click, nothing happens on your server. No pageview. No referrer. No entry in any log you own. The event that cost you a visitor produced exactly zero data on your side.

What you see instead is a slow, unremarkable decline in sessions with no single cause you can point at. Traffic is down 8% quarter over quarter. Nothing broke. Your rankings are the same. Search Console shows your impressions holding steady or even climbing while clicks slide.

That last pattern, impressions flat or up while clicks fall, is the clearest fingerprint of AI-driven loss you have access to for free, and most people never look at it because they look at the clicks graph and not the ratio. If your position has not moved and your impressions have not moved but your CTR has dropped by a third, an answer above you is eating the click.

The scale of that effect is not subtle. When AI Overviews appear, CTR on the results below drops by nearly 60%. And Google's AI Mode, the fully conversational surface, produces a zero-click rate around 93%, more than double regular AI Overviews. If AI Mode becomes the default rather than a tab, the numbers in this post age badly in the wrong direction.

The Second Blind Spot: Assistant Traffic That Never Touches Google

The zero-click statistic only measures Google. It does not measure the searches that never went to Google at all.

Somebody asks ChatGPT which tool they should use for X. The assistant names three products. Your product is either in that list or it is not. There is no impression, no ranking, no Search Console row. Nothing. If you are not named, the entire interaction is invisible to you, and it is invisible in a way that is qualitatively different from ranking eleventh, because at least ranking eleventh shows up in a report.

You get one weak signal: referral traffic. Visits with a referrer of chatgpt.com, perplexity.ai, claude.ai, copilot.microsoft.com. Those are worth segmenting out in your analytics right now if you have not, because that traffic converts unusually well. Somebody who arrives after an assistant recommended you by name is much further down the funnel than somebody who found you on a listicle.

But referral traffic only tells you about the times you won. It says nothing about the far larger number of times a competitor got named instead, which is the number you actually need.

I ran into this directly with roastme.gg. I put the site through ChatGPT's live search by hand to see whether it would show up for anyone not already looking for it by name. Doing that manually, one prompt at a time, is the crudest possible version of measurement, and it was still more informative than anything in my analytics. That is a bad sign for the analytics.

What Free Measurement Actually Gets You

Before spending money, here is the honest list of what you can do for nothing. It is more than most people do and less than you need.

Segment assistant referrals. Build a report filtering referrers for the major assistant domains. Track it weekly. This is your "am I being cited" proxy, biased toward whichever assistants pass a referrer at all.

Watch the CTR ratio in Search Console, not the click count. Pull position, impressions, and clicks per query. Sort by queries where position is stable and CTR has fallen. That list is your AI Overview exposure.

Check your server logs for assistant crawlers. GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, and friends. Crawling is not citation, but never being crawled means citation is impossible. If they are not in your logs, check your robots.txt and your firewall rules before anything else, because plenty of people are blocking these by accident through a WAF preset.

Ask the assistants yourself, on a schedule. Write down fifteen prompts a real customer might type. Run them monthly in a fresh session with no history. Record which brands get named. This is tedious and unglamorous and it is genuinely the highest-signal free thing on this list.

That last one is the whole game, and the reason a tool category exists is that doing it by hand across four assistants and fifty prompts every week is not a thing a person will keep doing past week three.

The Tooling, and What It Costs

The AI visibility tracking category filled up fast. The shape of the offering is consistent: you give it a list of prompts, it runs them against the assistants on a schedule, and it tells you how often you get named and who gets named instead.

Rough pricing as of now:

Otterly: from $25/month annually for 15 prompts tracked daily across AI Overviews, ChatGPT, Perplexity, and Copilot. $160/month for 100 prompts.
Peec AI: from €89/month for 25 prompts, €199/month for 100.
Profound: from $99/month for 50 prompts on ChatGPT, $399/month for 100 prompts across ChatGPT, Perplexity, and AI Overviews. Enterprise is custom.

Those prices are aimed at marketing teams, and for a marketing team they are trivial. For a solo founder doing $2,000 MRR, $199 a month to find out you have a problem is a hard sell, especially since none of these tools fix anything. They are thermometers.

That is the actual gap in this category, and it is worth naming plainly. Every tool here tells you that a competitor got named for prompt seventeen. None of them tell you which page to change or what to put on it. You are left holding a diagnosis and no prescription, at $200 a month, which is the same position a rank tracker left you in fifteen years ago except more expensive.

The Measurement Trap

There is a failure mode I want to flag because I have fallen into it.

Measurement feels like progress. Setting up dashboards, segmenting referrers, running prompt panels, building a spreadsheet of who gets named for what. All of that is real work and none of it changes a single answer any assistant gives.

The thing that changes an answer is changing a page. Assistants answer from a live search over crawled, indexed content. If your page does not say the thing, no amount of tracking makes it say the thing.

And the loop is slow. A page you rewrite today has to be crawled and indexed before it can be cited at all, and realistically you are looking at three to four weeks before an assistant's answer could plausibly move. Anyone promising you a shift in two weeks is either lucky or lying.

So the measurement is only worth what you do with it, and the honest sequence is: measure enough to know which prompts you are losing, then spend the rest of your time on the pages, then measure again to see if it worked. One cycle is a month. That is the natural cadence of this work and it is much slower than the daily dashboards imply.

What Actually Moves an Assistant's Answer

This is where it connects to everything else. The pages that get cited are the pages that contain something an answer engine must point at rather than paraphrase, which is the same rule that now governs programmatic SEO and the same rule I laid out in the generative engine optimization guide.

Concretely, the things that keep showing up on cited pages:

Direct answers, stated plainly, near the top. An assistant extracting a claim needs a sentence it can extract. Three paragraphs of throat-clearing before the answer means the answer does not get taken.

Specific numbers with sources. "Faster" gets paraphrased away. "22% more requests under load" gets quoted.

Explicit comparisons. If someone asks which tool to use, the pages that get cited are the ones that actually name alternatives and say when to pick them. Most product pages refuse to mention competitors, which is exactly why competitors' pages get cited instead.

Structure that survives extraction. Headings that match real questions, FAQ blocks, tables. Not because schema is magic but because a table is unambiguous and a wall of prose is not.

Being named somewhere else. Assistants pull from live search, so pages about you that you do not control matter enormously. This is the part where directory listings and third-party mentions do real work, not for the link juice, but because they are corroborating sources an assistant can find.

None of this is exotic. It is mostly "write the answer down clearly and be mentioned elsewhere," which was good advice in 2015 too. What changed is that the penalty for not doing it went from ranking lower to not existing.

The Part I Keep Coming Back To

The 68% number gets reported as a search story. It is not. It is a distribution story.

For a decade, the deal was that if you wrote something good enough and structured it well enough, Google would send you strangers. That deal was never guaranteed and it is now visibly ending, and the replacement is not another channel you can optimize into. Being named inside an answer you cannot see is not a channel. It is a mention.

Which loops back to something I have written more than once: building is easy and distribution is the moat. What is happening to search is a specific case of the general rule. The distribution channels that were legible and gameable are becoming illegible, and the things that still work are the slow ones. Having a real audience. Being the source somebody else quotes. Owning a dataset. An email list that does not depend on anyone's ranking algorithm.

Measure the AI answers, absolutely. Just do not mistake the dashboard for the work.

Frequently Asked

What percentage of Google searches end without a click? 68.01% of US Google searches ended without a click between January and April 2026, per Similarweb clickstream data published by SparkToro, up from 60.45% in 2024.

Can I see AI Overview traffic loss in Google Analytics? No. A search that ends in an AI answer never reaches your server, so it produces no data on your side. The closest free signal is Search Console: stable position and impressions with falling CTR.

How do I track whether ChatGPT mentions my brand? Manually, by running a fixed set of customer-style prompts in fresh sessions on a schedule and recording who gets named. Automated tools do the same thing weekly, from roughly $25 to $399 a month depending on prompt volume and engine coverage.

Does traffic from ChatGPT show up as a referral? Often, yes. Segment referrers like chatgpt.com, perplexity.ai, and claude.ai in your analytics. That traffic tends to convert well, but it only shows the times you were cited, never the times you were not.

How long does it take for a page change to affect AI answers? Realistically three to four weeks. Assistants answer from live search, so a rewritten page has to be crawled and indexed before it can be cited at all.

What is Google AI Mode's zero-click rate? Around 93%, more than double the rate for standard AI Overviews.

Pick fifteen prompts your customers would actually type, run them tonight, and write down who gets named. Whatever you find will be more useful than another quarter of watching sessions drift down for no visible reason.

Programmatic SEO in 2026: What Google Killed in March, and What Still Prints Traffic

Alex Cloudstar — Sat, 05 Sep 2026 19:26:37 +0000

Programmatic SEO in 2026

Two facts about programmatic SEO that both became true this year.

Google's March 2026 enforcement of the scaled content abuse policy stripped somewhere between 50 and 80 percent of traffic from low-value programmatic sites. Whole directories of [keyword] in [city] pages went from a business to a graveyard inside a single update cycle.

At the same time, Zapier is still pulling roughly 16 million organic visits a month from more than 50,000 integration pages. Wise still does around 60 million a month from currency converters. Canva does over 100 million from its template gallery. All three are programmatic SEO. All three are template-generated pages at enormous scale.

So programmatic SEO is not dead. A specific version of it died, loudly, and the version that survived looks so different that people keep confusing the two.

I have been on both sides of this. I have built the thin version, watched it index, watched it do nothing, and quietly deleted it. I have also built the version that works, which is justship.now, a directory where every entry is something I have an actual opinion about. The difference between those two projects is not technical. The code is nearly identical. The difference is what sits inside the template.

Here is what actually separates them.

The Only Question That Matters

Strip away every tactic and programmatic SEO reduces to one test:

Does the page contain something that does not exist anywhere else on the internet, and could a human not reasonably have written all of these pages by hand?

Both halves are required.

If the answer to the first is no, you have generated a page whose only reason to exist is a keyword slot. That is precisely the thing Google's spam policy names: producing many pages primarily to manipulate rankings rather than help users, with generative AI pages that add no value called out explicitly.

If the answer to the second is no, you did not need a program. Write the twelve pages by hand and stop calling it a strategy.

Zapier passes both. Each integration page describes a specific pairing of two products, with the actual triggers and actions that pairing supports, pulled from live data. Nobody could hand-write 50,000 of those, and each one contains information that exists nowhere else in that combination. Wise passes both: live exchange rate data, per currency pair. Canva passes: an actual template you can open and use.

A page that says "Looking for the best CRM in Cluj-Napoca? Here are our top picks for CRM in Cluj-Napoca" passes neither. It has no unique information and there was never a reason for it to exist besides the phrase in the H1.

What Google Actually Changed

The 2026 spam policy defines scaled content abuse as producing many pages primarily to manipulate rankings rather than help users. The named examples are the ones you would expect: generative AI pages with no added value, scraped feeds, stitched content, doorway-style keyword pages, and networks that hide their scale.

Three things about the current enforcement are worth understanding properly.

Intent matters more than method. The policy says nothing about how the pages were produced. AI-generated is not automatically spam and hand-written is not automatically safe. What is being evaluated is whether the pages exist primarily to rank. A programmatically generated page with real data is fine. A hand-written page farm is not.

The classifiers got much better at near-duplicates. The template-and-spin approach, where you swap a variable and change three sentences, used to survive because the pages were technically distinct strings. Near-duplicate detection in 2026 is comparing meaning, not text. If your 400 pages say the same thing with different nouns, they are one page as far as the system is concerned.

Manipulating AI answers is now explicitly in scope. This is the newer wrinkle and people have not caught up to it. Google's spam policy now names attempts to manipulate generative AI responses in Search, not just traditional rankings. So the "spam the AI instead" plan that circulated after AI Overviews launched has been closed off in policy terms, whatever the enforcement reality turns out to be.

The result of March was blunt. Sites built on the thin pattern lost 50 to 80 percent of their traffic. Not a ranking wobble. A structural removal.

Why AI Search Made This Worse for Thin Pages Specifically

There is a second force acting on the same pages, and it is arguably the bigger one long-term.

When an AI Overview appears, the top organic result loses about 58% of its clicks. That loss is not distributed evenly. It falls hardest on exactly one kind of page: the definition-style page whose entire content can be summarized in two sentences.

Think about what that means mechanically. If your page's value is "here is what a CRM is and here are five of them," an AI Overview reproduces that value completely, above your result, for free. There is no reason left to click. The page did not get penalized. It got made redundant.

Pages with real data or actual utility survive that, and they do something better than survive: they get cited. A currency converter cannot be summarized away, because the value is the interaction. An integration page listing specific triggers and actions cannot be summarized away without reproducing the data, which is a citation.

This is the through-line from what I wrote about generative engine optimization earlier this year. The pages that win in AI search are the pages that contain something an answer engine has to point at rather than paraphrase. Programmatic SEO is not exempt from that rule, it is the most exposed to it, because programmatic pages are the ones most likely to be pure summary.

The Data Layer Is the Whole Strategy

Here is where most programmatic SEO projects go wrong, and it happens before a single line of code.

People start with the keyword pattern. "I'll do best [tool] for [industry], that's 40 tools times 30 industries, 1,200 pages." Then they go looking for something to put on those 1,200 pages, discover they have nothing, and fill the gap with generated prose.

Do it the other way around. Start with a dataset you have that other people do not, then ask what page patterns that dataset supports.

The question to answer honestly is: what do I know that is not already published?

Some answers that actually work for indie hackers:

Your own product's data. If you run a tool that processes things, you have aggregate numbers nobody else has. Usage patterns, failure rates, average values, distributions. One page per segment, each with real figures.

Structured comparisons you have actually made. Not "X vs Y" pages generated from marketing copy, but comparisons where you have used both and recorded specifics. This is slower and it is the reason a comparison page survives.

A live feed of something. Prices, availability, statuses, version numbers. The value is in freshness, which is inherently uncopyable and inherently unsummarizable.

Community-generated content with real moderation. Reviews, submissions, entries, each with something specific in it. This is the directory model, and it works precisely to the degree that the moderation is real. I have made this argument at length about directory submissions and what they are actually worth: an unmoderated list of links is worthless in both directions, to the person submitting and to the person running it.

Calculators and converters. The highest-surviving category, because the page's value is a computation and a computation is not a paragraph.

If none of those apply to you, that is genuinely useful information. It means programmatic SEO is not your channel right now, and the honest move is to write twenty good pages instead of generating two thousand bad ones.

The Page-Level Checklist

Once you have a dataset worth publishing, the per-page requirements in 2026 are stricter than they used to be but not complicated.

Unique data above the fold. The specific thing this page knows should be visible without scrolling. Not an intro paragraph explaining the category. The data.

A real reason for this page to be separate from its siblings. If the answer for /compare/a-vs-b and /compare/a-vs-c is "the second noun changed," merge them.

Internal links that follow the data, not a footer. A block of 50 identical "related pages" links at the bottom of every page is a pattern that gets recognized. Links that follow actual relationships in your dataset, three to six per page, are structure.

No page without content. The classic programmatic failure is generating a page for every possible combination, including the 60% of combinations for which you have no data. Those empty pages drag the whole set down. Generate only where the data exists, and let the rest 404 or redirect.

A crawl budget you can actually justify. If you publish 5,000 pages on a domain with no authority, most will not get crawled, and the ones that do will be judged as a set. Publishing in batches and watching what indexes beats dumping everything on day one.

Schema markup that matches reality. Structured data helps AI systems parse what your page contains. It also gets you in trouble faster if it describes something the page does not have.

The Part About AI-Generated Copy

Let me be direct about the thing everyone is actually doing.

Using an LLM to write the prose around your data is fine. It is not a policy violation, Google has said so repeatedly, and pretending otherwise is theater. What is a violation is using an LLM to manufacture the substance, because then the substance is a plausible-sounding average of the internet, which is by definition not unique information.

The distinction in practice:

Fine: you have 800 rows of real data, and you use a model to turn each row into two readable paragraphs of context around it.

Not fine: you have a list of 800 keywords, and you use a model to write 800 articles about them.

The first has an information source and a presentation layer. The second has only a presentation layer, and the thing being presented is nothing.

I use models to write around data constantly. Every one of my pSEO-shaped pages has generated prose in it. The prose is not the product. The data is the product, and if you deleted the prose the page would still be useful, which is the test.

What I Would Actually Build

If I were starting a programmatic play this month for a small product, here is the sequence.

Week one: find the dataset. Not the keywords. The dataset. Go look at what your app already stores, what you could scrape legitimately, what you could compute, or what you could get people to submit. If you cannot name the unique information in one sentence, stop here.

Week two: build twenty pages by hand. Actual hand-written, using the data. This tells you two things: whether the page is genuinely useful, and what the template needs to contain. Almost every template I have built was wrong in ways that only became obvious after writing a few by hand.

Week three: check whether anyone is searching. Now do the keyword work, and do it against pages that exist. If the twenty hand-written pages get zero impressions in Search Console after three weeks, generating two thousand more of them will get you zero impressions two thousand times.

Week four onward: scale in batches. A hundred pages, wait, measure indexation and impressions, then the next hundred. Slower than a bulk publish and dramatically less likely to get the whole domain classified as a content farm.

That timeline is deliberately unexciting. Programmatic SEO in 2026 is a data project with a publishing layer bolted on, and the data project is the hard part. Everyone wants it to be a publishing project with a data problem to solve later, because publishing is fast and data is slow.

The Uncomfortable Conclusion

The version of programmatic SEO that made people money in 2021 is gone and it is not coming back. That version was an arbitrage: producing pages was cheap and evaluating pages was expensive, so volume won. Both halves of that flipped. Producing pages is now free, which destroyed its value, and evaluating pages is now cheap, which destroyed the arbitrage.

What is left is the thing that was always actually valuable and never actually easy: having information other people do not have, and publishing it at a scale a human could not.

This is the same argument I keep ending up at from different directions. Building is easy and distribution is the moat, and the reason distribution is a moat is that it is made of things that do not commoditize. A dataset you built is one of those. A template is not.

If you have the data, programmatic SEO is more effective in 2026 than it was in 2021, because the field cleared out. If you do not have the data, no amount of technique will save you, and the honest thing to do is go get some.

Frequently Asked

Is programmatic SEO dead in 2026? No. Thin, template-and-spin programmatic SEO is effectively dead after Google's March 2026 scaled content abuse enforcement, which cut 50 to 80 percent of traffic from low-value programmatic sites. Data-backed programmatic SEO is working better than before because the low-quality competition was removed.

Will Google penalize AI-generated programmatic pages? Google evaluates intent and value, not production method. AI-generated pages built around real, unique data are fine. AI-generated pages that manufacture the substance itself are exactly what the scaled content abuse policy targets.

How many pages is too many? There is no number. A thousand pages backed by a thousand real data points is fine. Fifty pages that say the same thing with different nouns is not.

Does programmatic SEO still work with AI Overviews? For utility and data pages, yes, and they earn citations. For definition-style pages, AI Overviews reproduce the value above your result and the top organic result loses roughly 58% of its clicks.

What is scaled content abuse? Google's policy term for producing many pages primarily to manipulate rankings rather than help users. The 2026 version explicitly includes attempts to manipulate generative AI responses in Search.

Where do I start if I have no dataset? You do not start. Programmatic SEO is not your channel yet. Write twenty pages by hand about something you actually know, which is what moved the needle for me long before any of this was automated.

Go look at your own database this afternoon. The dataset you need is more often sitting in a table you already have than out on the internet waiting to be scraped.

Next.js 16.3 Instant Navigations: The Release That Finally Fixes the Thing Everyone Complained About

Alex Cloudstar — Sat, 05 Sep 2026 19:26:03 +0000

Next.js 16.3 Instant Navigations

There is one complaint about the App Router that has followed it since the day it shipped, and every single person who has built a real app with Server Components has said some version of it out loud.

"It renders fast, but clicking around feels slow."

I have said it. I said it while migrating this site. I said it again three months ago while building something with a heavy dashboard, watching a link click sit there doing absolutely nothing for 400ms before the page swapped. The pages themselves were fast. The navigations were not. And the fix everyone reached for, sprinkling loading.tsx files across every route segment until the dead air went away, was a chore you could forget about in exactly one place and then never notice until a user complained.

Next.js 16.3 is the release where the team stopped patching around that and rebuilt the model underneath it. The headline feature is called Instant Navigations, and it is the biggest change to the framework since 16.0 landed last November.

I have been running it for a few weeks now. Here is what it actually does, what it costs to adopt, and the parts I would turn on today versus the parts I would wait on.

The Free Wins: Upgrade Even If You Ignore Everything Else

Before the opt-in stuff, there is a pile of improvements in 16.3 that require zero code changes. If you read nothing else in this post, read this section, run npm install next@latest, and go back to whatever you were doing.

Dev server memory dropped by up to 90%. Turbopack now ships disk caching for dev plus memory eviction, both on by default. Vercel's own dashboard went from 21.5 GB to 2 GB of RAM after compiling 50 routes. nextjs.org went from 4,600 MB to 840 MB. If you have ever had next dev slowly eat your laptop over a six-hour session until the fans sound like a departing aircraft, this is the fix. On my machine the difference is the gap between "I can keep Docker and a browser open" and "I cannot."

Builds got faster because the disk cache now applies to next build. Vercel is reporting up to 5.5x faster repeat builds on CI. Their own numbers span a range: nextjs.org went from 21s cold to 9.2s cached, vercel.com/home from 66s to 46s, vercel.com/geist from 30s to 5.5s. That spread is worth noting. The gain depends heavily on how much of your build is actually compilation versus data fetching, so do not budget for 5.5x and be disappointed when you get 1.4x.

Server-side rendering handles about 22% more requests under load. They replaced web streams with native Node.js streams in the App Router rendering layer, cutting the conversion overhead between the two. No API change, no config, just more headroom on the same box.

Type checking can now use TypeScript 7. If you bump your local dependency to typescript@^7, next build will use the native Go port for type checking. I wrote about TypeScript 7 and Project Corsa when it was still landing, and the short version is that a 10x faster type checker changes what you are willing to run in CI. This is the release where that becomes a one-line change in a Next.js app.

Coding agents now read version-matched docs automatically. Running next dev writes and maintains an AGENTS.md block pointing at the docs bundled in your local node_modules. Vercel is retiring the earlier Skills that existed purely to feed current documentation to agents, because the docs now reach the agent directly. If you have ever watched Claude Code confidently write a Next.js 13 pattern into a Next.js 16 app, you know exactly why this matters.

That is a genuinely good release before you opt into anything.

What Instant Navigations Actually Is

Now the interesting part.

The mental model to hold onto is this: Next.js can only show you something the instant you click a link if it already has that something on the client. Everything in Instant Navigations is machinery for extracting a reusable "shell" of each route, prefetching it once, and rendering it immediately on click while the real data streams in behind it.

Before 16.3 you had two blunt tools for that. You could define a loading.tsx for a route segment, which gave you one shell per segment and nothing more granular. Or you could set <Link prefetch={true}> and pull down the entire target page, which worked and also hammered your server with prefetch traffic for pages nobody visited.

16.3 replaces both with something finer. Components that render dynamic UI can either define inline loading states with <Suspense>, or mark part of their UI as prerenderable with 'use cache'. Next.js extracts that UI into a shell, prefetches the shell once, and reuses it. The rule the docs give you is close to a slogan:

Stream with <Suspense>, or
Cache with 'use cache', and your navigation is instant
Block with export const instant = false if you deliberately want to opt a route out

That third one matters more than it looks. It is an escape hatch that turns "this route is slow" from an invisible accident into a deliberate, greppable decision in your codebase.

You turn the whole thing on with two flags:

// next.config.ts

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

export default nextConfig;

Vercel has said the behaviors behind Instant Navigations will become the default in a future major version. So this is not a side experiment you can ignore forever. It is a preview of where the framework is going, offered a version early so you can migrate on your own schedule instead of during an upgrade weekend.

Partial Prefetching Is the Piece That Changes Your Bill

Of the whole suite, Partial Prefetching is the one I would call out to anyone running a site with real traffic and a real invoice.

The old model forced a binary. Either you got the coarse loading.tsx shell, or you flipped prefetch={true} and pulled the whole page down for every link in the viewport. On a page with thirty links, the second option is thirty full page payloads fetched on behalf of a user who is going to click one of them, if that.

Partial Prefetching lets Next.js extract a reusable loading shell from any route's UI, and lets per-link prefetching include as much or as little of the target page as you want. Separately, 16.3 bundles prefetches below a certain payload size into fewer requests, while keeping larger shared segments as separate fetches so they can be reused across routes.

That combination is the difference between prefetching being a nice performance trick and prefetching being something you can afford to leave on. If you are on a usage-priced host, prefetch traffic is not free, and "aggressive prefetching" has been a quiet line item on plenty of bills. I have written before about how edge functions get sold as a default when they should not be, and this is the same category of problem: a feature that is great when it is targeted and expensive when it is blanket-applied.

Instant Insights: The Devtool That Tells You What You Broke

The failure mode with all of this is not the initial setup. It is the slow drift afterward.

Someone adds a component that reads cookies() into a shared header, and the route de-opts to request-time rendering. Someone moves a <Suspense> boundary during a refactor and half the page starts blocking. The navigation that was instant in March is not instant in July, and nobody noticed because nobody was measuring it.

16.3 ships three things aimed squarely at that.

Instant Insights is a DevTools panel that automatically surfaces navigations that are not instant as you click around your own app. You do not go looking for it. It goes looking for you. Each insight also hands you a prompt you can feed to your coding agent to apply the fix, which is a small detail I find quietly telling about where Vercel thinks the workflow is heading.

The Navigation Inspector solves a specific annoyance: prefetching is disabled in development, so you genuinely cannot see what your users see during a navigation's loading sequence. The inspector lets you pause a page load or client-side navigation at the shell and look at exactly what the loading state renders.

The instant() Playwright helper is the one that keeps it fixed. It lets you assert exactly what content should be visible during a navigation, without waiting on the network:

// e2e/instant-navigation.spec.ts

test('product title is available immediately', async ({ page }) => {
  await page.goto('/products/shoes');

  await instant(page, async () => {
    await page.click('a[href="/products/hats"]');
    await expect(page.locator('h1')).toContainText('Baseball Cap');
    await expect(page.getByText('Checking inventory...')).toBeVisible();
  });

  await expect(page.getByText('12 in stock')).toBeVisible();
});

That test fails whenever the instant UI changes, whatever the cause. That is the whole point. Performance regressions are boring to catch by hand and trivial to catch in CI, so put them in CI.

The Smaller Additions Worth Knowing About

A few things in 16.3 are not headline features but will show up in your code within a month of upgrading.

Custom error boundaries with catchError. React error boundaries in Next.js used to interfere with notFound() and redirect(), and they could only reset client state. They gave you no way to retry a Server Component that failed during rendering. Now:

// app/my-error-boundary.tsx
'use client';

function ErrorFallback(props: { title: string }, { error, retry }: ErrorInfo) {
  return (
    <div>
      <h2>{props.title}</h2>
      <p>{error.message}</p>
      <button onClick={() => retry()}>Try again</button>
    </div>
  );
}

export default catchError(ErrorFallback);

The retry() function refetches the boundary's children, including rerendering Server Components. If you have ever shipped a "something went wrong, please refresh the page" screen because there was no way to retry the server render, this deletes that screen.

Glob imports in Turbopack. import.meta.glob is now supported, Vite-compatible, with HMR:

const posts = import.meta.glob('./posts/*.md', { eager: true });

For a content-driven site this is genuinely nice. This blog reads MDX off disk with fs.readdirSync and a module-level cache, which works fine but does not hot-reload when I add a file. Glob imports fix that class of thing.

Root params. Params defined above the root layout, the classic [lang] case, are effectively global, and until now the only way to read them deep in the tree was prop drilling. Now:

They work inside use cache scopes too. Currently Server Components only, with route handlers and Server Actions planned.

Better ISR for partially prerendered routes. If you use generateStaticParams to prerender only some pages, the rest used to face a bad trade: show a loading shell but never get prerendered, or skip the shell and block the first visitor. Now the first visitor gets an instant shell, the page upgrades to fully prerendered in the background, and everyone after that gets the cached final content.

Experimental: The Rust React Compiler

Two experimental flags ship with 16.3, and one of them is worth watching closely.

The React Compiler has been available for a while, but enabling it meant running it through Babel in Node. The experimental Rust port runs directly inside Turbopack, skipping the generate-and-reparse round trip:

const nextConfig: NextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

On v0, Vercel measured a 34% cut in time from next dev to a ready page on a cold build, and 46% on a warm one. Important asterisk: those numbers assume you have dropped Babel entirely. If you still run Babel for other transforms, you get a smaller win.

I wrote about the React Compiler when it first landed and my position has not really changed. The compiler is the right long-term answer to manual memoization, and the friction was always the build-time cost. Moving it into Turbopack removes most of that friction.

The other experimental flag is useOffline, which keeps soft navigations, data fetches, and Server Actions pending when the network drops and retries on reconnect, plus a useOffline() hook so you can render a banner. Because Partial Prefetching already caches route shells on the client, a prefetched route still renders its shell offline and streams data in when you reconnect. That is a nice composition of two features that were designed separately.

Should You Turn the Flags On?

Here is how I would actually sequence this, in order of how much I would trust each step.

Upgrade to 16.3 today. The dev memory, build cache, SSR throughput, and prefetch bundling improvements are all default-on and require no code changes. There is no argument for sitting on 16.2 while your dev server eats 20 GB of RAM.

Turn on partialPrefetching next if you have a link-heavy app. It is the lowest-risk of the two flags and it directly reduces prefetch traffic. If you have been running prefetch={true} broadly because navigations felt bad, this is the thing that lets you keep the feel and drop the cost.

Adopt cacheComponents deliberately, not casually. This is the one that changes how you think about your data layer. Vercel ships a migration guide and explicitly frames it as something you or your agent can work through, which is an honest signal that it is not a flag flip. If your app is mostly static marketing pages, the migration is small. If it is a dashboard where half the tree reads cookies and headers, budget real time for it.

Skip the Rust React Compiler on anything that pays you money. It is experimental, the win is a dev-loop speedup rather than a runtime one, and experimental compiler flags are exactly the wrong place to be adventurous on a production app. Try it on a side project, report what breaks, wait for stable.

The thing I keep coming back to is the framing Vercel used: simplify Next.js back to its roots, dynamic by default, with no hidden or implicit caching. That is a direct response to the years of complaints about the App Router's caching model being something you had to reverse-engineer rather than read. 'use cache' being explicit and composable, and now covering the client too, is the correction. Whether it lands depends on whether the migration path is genuinely walkable for apps that already exist, and that is the part I will only know for sure after doing it on something bigger than a blog.

Frequently Asked

Do I need to enable anything to benefit from Next.js 16.3? No. The memory, build, rendering, and prefetch-bundling improvements are default-on. Instant Navigations is the opt-in part, behind cacheComponents and partialPrefetching.

What is the difference between Instant Navigations and Partial Prefetching? Instant Navigations is the umbrella name for the whole suite. Partial Prefetching is the specific mechanism that lets Next.js extract a reusable loading shell from any route and control how much a link prefetches.

Will Cache Components become the default? Vercel has said the behaviors behind Instant Navigations will become the default in a future major version. Adopting now is early migration, not a permanent side path.

Is loading.tsx deprecated? Not deprecated, but it is no longer the only way to define a loading shell. Inline <Suspense> boundaries and 'use cache' give you finer-grained control than one shell per route segment.

Does this change my hosting bill? Probably down, if you were running broad prefetch={true}. Partial Prefetching plus prefetch bundling means fewer and smaller prefetch requests for the same perceived speed.

If you are upgrading this week, start with the flags off, look at Instant Insights while clicking through your own app, and let it tell you which routes are actually slow before you migrate anything. That list is usually shorter and weirder than you expect.

Merchant of Record in 2026: Stripe, Paddle, Polar, and the Lemon Squeezy Question Nobody Wants to Answer

Alex Cloudstar — Sat, 05 Sep 2026 19:26:02 +0000

Merchant of Record in 2026

The first time I sold software to someone in Germany, I did not think about VAT for even one second. I thought about whether the webhook fired.

That is the default state of most developers shipping their first paid product, and it is fine right up until it is not. The moment your Stripe dashboard has customers in eleven countries and your revenue crosses the point where somebody might actually care, you discover that "collect the money" and "be legally allowed to have collected the money" are two different projects, and you only built one of them.

Merchant of record providers exist to sell you out of the second project. They become the legal seller. They collect and remit the tax. They handle the chargebacks and issue the compliant invoices. You get one payout and one problem instead of forty.

Three things changed in 2026 that make this decision worth revisiting even if you settled it last year. Polar raised its headline rate by 25%. Lemon Squeezy is being absorbed into Stripe's own MoR product. And Stripe Tax got good enough that the "just use Stripe" answer is now genuinely correct for a bigger slice of founders than it used to be.

Here is the actual math, and the part most comparison posts skip: when the MoR tax is not worth paying.

What a Merchant of Record Actually Buys You

Strip the marketing off and an MoR sells you exactly one thing: they become the legal seller of record, so the tax obligation is theirs and not yours.

In practice that unbundles into a handful of chores you stop doing.

Sales tax and VAT registration. The EU wants VAT on digital goods sold to EU consumers, at the customer's local rate, remitted through a scheme you have to register for. The UK wants its own. Over 40 US states now have economic nexus rules for SaaS. Some of those thresholds are low enough that a modest product trips them without you noticing.

Filing. Registration is the easy half. Filing quarterly returns across multiple jurisdictions, forever, is the half that eats weekends.

Invoices that satisfy an accountant. B2B customers in the EU want a VAT-compliant invoice with your VAT number and theirs, reverse-charged correctly. "Here is a Stripe receipt" gets you an email from their finance department.

Chargebacks and fraud liability. With an MoR, the dispute is against them, not you.

The pitch is that this is worth about 5% of revenue. Whether it is depends almost entirely on where your customers are and how much money you are making, and that is the calculation nobody runs before signing up.

The 2026 Fee Landscape, Honestly

Here is where the four main options actually sit as of this month.

Stripe (not an MoR). 2.9% + $0.30 for cards, plus Stripe Tax at roughly 0.5% per transaction if you enable it. Stripe Tax calculates and tracks thresholds for you, and it tells you when you have crossed a registration threshold somewhere. It does not register or file for you. You are still the seller. Effective cost around 3.4%.

Paddle. 5% + $0.50, true merchant of record. The deepest platform of the group for actual subscription businesses, with real dunning and failed-payment recovery through Retain. If you have a subscription product past the hobby stage, Paddle is the one built for you rather than adapted to you.

Polar. This is the one that changed. Polar spent two years being the developer-first MoR with a flat 4% + $0.40, which was genuinely the cheapest real MoR on the market and got recommended everywhere on that basis. In 2026 they moved to a tiered model where the free Starter tier is 5% + $0.50, matching Paddle and Lemon Squeezy. To get back to the old economics you subscribe to a paid plan on top: Pro at $20/mo, Growth at $100/mo, Scale at $400/mo. Organizations created before May 27, 2026 keep 4% + $0.40 on a grandfathered Early Member plan indefinitely.

That is a 25% increase on both the percentage and the fixed fee for anyone who signs up today on the free tier. It does not make Polar a bad choice. It does make every 2025 blog post recommending Polar "because it is 20% cheaper" out of date, and those posts are still the ones ranking.

Lemon Squeezy. 5% + $0.50, acquired by Stripe in 2024, still running as its own product with its own dashboard and API. Pricing has not changed since the acquisition. Here is the part that matters: in January 2026 Lemon Squeezy announced Stripe Managed Payments, which is Stripe's own merchant of record product, built by the Lemon Squeezy team. Their CEO has publicly called it "the future" and said the goal is to give Lemon Squeezy users an easy path to migrate over.

No shutdown date has been announced. New signups are still open. But you would have to work quite hard to read that as anything other than a product on a glide path into a bigger one.

The Math Nobody Runs Before Signing Up

Take a product doing $2,000 MRR, average subscription $20/month, so 100 customers.

On Stripe with Stripe Tax: 2.9% + $0.30 per transaction is $0.88 per $20 charge, times 100 is $88. Stripe Tax adds roughly $10. Call it $98 a month, or 4.9% all in, because the fixed fee bites hard at a $20 price point.

On a 5% + $0.50 MoR: $1.50 per transaction, times 100 is $150 a month, 7.5% all in.

The MoR is costing you about $52 a month more, which is $624 a year. That is the number to hold in your head, because the real question is not "is 5% a lot." The question is whether $624 a year buys you more than the alternative use of that money and time.

If you are US-only selling to US customers, the answer is usually no. Stripe Tax handles US sales tax calculation, you register in the handful of states where you actually have nexus, and a bookkeeper handles the filings for less than $624 a year. Stripe is the right answer and it is not close.

If you have EU consumers, the answer flips fast. EU VAT on B2C digital goods starts at the first euro. There is no threshold to hide behind. Registering for the one-stop shop scheme, tracking rates across member states, and filing quarterly is either your weekend or your accountant's invoice, and either way it costs more than $624 and is more annoying than $624.

Now run the same math at $20,000 MRR. The MoR premium is now roughly $520 a month, $6,240 a year. At that size you can afford a real accountant and the MoR is starting to look like a subscription to a service you have outgrown. This is exactly the shape of decision I wrote about in pricing for indie hackers: the answer that is obviously right at one scale is obviously wrong two zeros later, and most people never revisit it.

The Thing That Actually Decides It: Your Customer Geography

Everything above collapses into one question. Where do your customers live, and are they businesses or consumers?

US-only, B2B. Use Stripe. Stripe Tax at 0.5% per transaction, register where you have nexus, done. B2B in the US is mostly exempt or resale-certificate territory anyway, and you get the best API in the industry as a bonus.

US-only, B2C. Still Stripe, probably. Watch the state nexus thresholds. Stripe Tax will tell you when you cross one.

Global, B2C. Use an MoR. This is the case they were built for. EU VAT with no threshold, UK VAT, and a dozen other regimes that all want their cut of a $9 subscription is not a problem you should be solving personally.

Global, B2B. Genuinely ambiguous. B2B in the EU is largely reverse-charge, meaning the customer self-accounts for VAT if they give you a valid VAT number. You still need to validate those numbers and issue correct invoices, which an MoR does for you. But the tax burden is smaller than the B2C case, so the 5% buys you less.

Selling to developers. Polar was purpose-built for this crowd and it shows in the API and the usage-based billing. If you were created before the May cutoff you are grandfathered at the old rate and should probably stay put.

Notice that "which platform has the nicest dashboard" did not appear anywhere in that list. It is the criterion people actually decide on and it is nearly irrelevant.

The Migration Cost Everyone Underestimates

The reason to get this right early is that switching later is genuinely painful, and the pain is not in the code.

Moving payment processors means migrating active subscriptions. Card details are held by the processor and are not always portable. Some migrations require every customer to re-enter their card, which means an email campaign asking your paying users to take an action, which means you will lose a percentage of them who never open it. I have watched founders lose 10 to 15% of their subscriber base to a "we're switching billing providers, please update your card" email, and no amount of good copy fixes it entirely.

You also lose your dunning history, your Stripe risk profile, and every integration built against the old webhook shape. If you have written any real logic around subscription lifecycle events, and you should have, that logic is provider-shaped. I wrote a whole post on handling Stripe webhooks in production and roughly none of it transfers cleanly to a different provider's event model.

So the practical advice is: pick based on where you expect customers to be in eighteen months, not where they are on launch day. If you are pretty sure you will end up with EU consumers, start on an MoR even if month one is all US traffic. The 5% on your first $500 of revenue is $25. The migration later is a weekend plus churn.

When Not To Bother With Any of This

Here is the section the comparison sites will not write, because they are all affiliate-linked.

If you have zero paying customers, this decision does not matter and thinking about it is procrastination wearing a business-y costume. I have done this. Picking a payment provider feels like real work. It is not real work. It is a two-hour decision that people stretch across two weeks because it is more comfortable than talking to a stranger about whether they would pay for the thing.

The honest sequencing is: get one person to pay you anything, on whatever rail is fastest to set up. Then, when you have five or ten customers and some evidence the thing works, spend an afternoon on this properly. I made the case in why your first dollar of MRR beats your first thousand followers that revenue is the only signal that is not fakeable, and the corollary is that infrastructure built before revenue is infrastructure built on a guess.

The tax authorities are not going to come after you for the €4 of VAT you failed to remit on your first sale. They may well care at €40,000. Build for the second case when you can see it coming, not before.

What I Would Do Today

If I were starting a new paid product this month, US and EU customers expected, B2C leaning:

I would start on Paddle. Not because it is cheapest, it is not, but because it is the one built for subscription businesses that intend to grow, it is not on a visible glide path into another product, and its failed-payment recovery is the part that quietly pays for a chunk of the fee difference once you have enough customers for involuntary churn to be a real number. Recovering 30% of failed payments on a $10,000 MRR business is worth more than the delta between 4% and 5%.

If I were selling a developer tool with usage-based pricing, I would use Polar and pay for the plan tier that gets the rate back down, because the product genuinely fits that shape better than anything else on the list.

If I were US-only B2B, I would use Stripe and not think about it again.

And I would not start on Lemon Squeezy in September 2026. Not because it is bad, it is good, and pricing has not moved. But building your billing on a product whose own team is publicly building its successor is signing up for a migration you did not choose the timing of. That is a bet you can take with your eyes open, and you should at least know you are taking it.

The general principle here is one I keep relearning across every product I have shipped: the boring infrastructure decisions are cheap to make well early and expensive to fix late, and the way you tell them apart from the ones worth agonizing over is asking what breaks if you are wrong. Wrong framework, you rewrite some code. Wrong billing provider, you email your paying customers and ask them for a favor.

Frequently Asked

What is a merchant of record? A company that becomes the legal seller of your product. They collect payment, calculate and remit sales tax and VAT, issue compliant invoices, and take on chargeback liability. You receive a payout net of their fee.

Is Stripe a merchant of record? No. Stripe is a payment processor. You remain the seller and the tax obligation is yours. Stripe Tax calculates and tracks tax for you at about 0.5% per transaction, but does not register or file on your behalf. Stripe Managed Payments, built by the Lemon Squeezy team, is Stripe's separate MoR product.

How much does a merchant of record cost in 2026? Paddle, Lemon Squeezy, and Polar's free tier all sit at 5% + $0.50 per transaction. Polar's paid plans bring the rate down in exchange for a monthly fee. Stripe with Stripe Tax works out around 3.4% and is not an MoR.

Did Polar raise its prices? Yes. Polar moved from a flat 4% + $0.40 to a tiered model in 2026, with the free Starter tier at 5% + $0.50. Organizations created before May 27, 2026 keep the old rate on a grandfathered plan.

Is Lemon Squeezy shutting down? No announced shutdown, and new signups are open. But Stripe acquired it in 2024 and the Lemon Squeezy team is now building Stripe Managed Payments, with the stated goal of giving existing users a migration path.

Do I need an MoR if I only sell to US customers? Usually not. Stripe plus Stripe Tax plus registering in the states where you have nexus is cheaper and gives you a better API.

If you are sitting on this decision right now with no paying customers yet, close this tab and go get one. The provider you pick will be the right one either way, and the person who pays you will teach you more about your product than the fee comparison will.

Claude Fable 5.1 Review: The Benchmarks Went Up, but the Cache Price Cut Is the Real Release

Alex Cloudstar — Sat, 05 Sep 2026 19:25:30 +0000

Claude Fable 5.1 Review

When Anthropic shipped Claude Fable 5 in June, I wrote that the price doubling was the headline, not the benchmarks. Ten dollars per million input tokens and fifty per million output is twice Opus 5, and I said at the time that the interesting question was not whether the model was better but whether it was better by enough to justify running it on anything that loops.

Fable 5.1 landed yesterday, September 1, alongside Mythos 5.1. The base price did not move. It is still $10 in, $50 out.

The cache read price moved a lot. It went from $1.00 per million to $0.25 per million, a 75% cut.

That sounds like a footnote. It is not. For anyone running agentic workloads, where the same large context gets re-read on every single turn of a loop, cache reads are frequently the majority of the bill. Anthropic's own claim, based on four weeks of internal August usage, is that this lowers typical bills by about 25% and highly agentic ones by up to 45%.

So this is a release where the model got better and the thing that was stopping people from using it got cheaper. Let me go through both halves.

What Fable 5.1 and Mythos 5.1 Actually Are

Same structure as last time, which is worth restating because it still confuses people.

Fable 5.1 and Mythos 5.1 are the same underlying model with different levels of safeguards. Fable 5.1 is the generally available version with Anthropic's production safeguards on. Mythos 5.1 is the same brain with reduced restrictions on cybersecurity and biology research work, available only through verification programs: the Cyber Verification Program for defensive security professionals, and the Life Sciences Verification Program run in partnership with the US government. Both are currently US-only, with international expansion described as under discussion.

The API model ID is claude-fable-5-1. It shipped day one on Bedrock, Vertex AI, Azure, the Claude API, plus Claude Code, Claude Enterprise, Claude Cowork, and Claude.ai. No waitlist, no staged rollout, which continues to be the release pattern that separates Anthropic from most of the field.

I wrote a longer piece on what the Mythos tier means when it was introduced, and the structure has held: capability is not the gate, verification is.

The Benchmarks That Moved

Here is the table from the announcement, with Fable 5 and Opus 5 for comparison.

Benchmark	Fable 5.1	Fable 5	Opus 5
Terminal-Bench 4.0	55.8%	42.0%	52.3%
Terminal-Bench-Science 0.1	52.6%	24.7%	29.0%
CursorBench 3.2.0	73.4%	70.5%	70.0%
OSWorld 2.0 (strict)	41.7%	36.1%	39.6%
AutomationBench	31.4%	17.1%	26.9%
Humanity's Last Exam (no tools)	60.9%	57.8%	56.6%
GDPval-AA v2	1853	1723	1824

Mythos 5.1 scores 60.9% on Terminal-Bench 4.0, five points above the safeguarded version, which is the clearest public number anyone has put on what production safeguards cost in raw capability on a coding benchmark.

Read the shape of that table rather than the individual numbers. The gains cluster hard in agentic terminal work and agentic science. Terminal-Bench 4.0 went from 42.0 to 55.8, which is a 33% relative improvement. Terminal-Bench-Science more than doubled. AutomationBench nearly doubled. Meanwhile Humanity's Last Exam moved three points and CursorBench moved three points.

That is not a model that got smarter. That is a model that got better at not giving up halfway through a long task. Anthropic's own framing is that it is better at sustained multi-step work and better at diagnosing root causes rather than applying shortcuts, and the benchmark spread backs that up.

One thing worth flagging because it is circulating badly: the "Fable 5.1 scores 95% on SWE-bench Verified" number you will see in roundups comes from third-party leaderboards, not from Anthropic. Anthropic reports SWE-bench Pro at 81.2 in the system card. Both numbers can be true and they measure different things, but attribute them correctly.

There is also an honest asterisk that cuts the other way. Both Fable models were scored with production safeguards switched on, and on tasks where a classifier intervened they took zeros. The published Fable scores are conservative rather than inflated. That is an unusual thing for a lab to do to its own launch numbers and it deserves credit.

What "Better at Sustained Work" Feels Like

Benchmarks are the part of a review I trust least, so here is the part I actually did.

I gave it the kind of task that used to break agents: a real refactor across a codebase, spanning several files, where the correct answer requires reading code you were not pointed at. Specifically, tracing why a build was failing three layers away from where the error surfaced.

The Fable 5 behavior on this class of task was decent and had a characteristic failure. It would find a fix, apply it, watch the error change shape, and then start chasing the new error rather than backing up and asking why the first fix did not work. You end up with four plausible-looking patches and a codebase that is worse than when you started.

5.1 backs up more. Twice in a day it did the thing I actually wanted, which was stop, say the earlier assumption was wrong, and re-read the file it had skimmed. That is the "root causes rather than shortcuts" claim showing up in behavior rather than in a chart, and it is the single most useful improvement in the release for anyone doing agentic coding day to day.

It is not magic. It still confidently wrote a test that asserted the buggy behavior once, which is the most annoying failure mode any coding model has. But the direction is right.

The Cache Price Cut Is the Actual Story

Now the part that changes what you can afford to build.

Most Claude models price cache reads at 10% of the base input rate. Fable 5's input is $10 per million, so cache reads were $1.00. Fable 5.1 prices cache reads at $0.25 per million, which is 2.5% of base input, not 10%. That is a different multiplier from the rest of the lineup, deliberately.

Why this matters more than the raw percentage suggests: in an agentic loop, the expensive thing is not generating tokens. It is re-reading the same enormous context on every turn. Your system prompt, your tool definitions, the files the agent has already loaded, the conversation so far. Fifteen turns into a session, you are paying to re-read a context that has barely changed, fifteen times.

I broke the arithmetic down in detail in the guide to what AI agents actually cost, and the conclusion there was that cache reads dominate the bill for anything that loops, which is why prompt caching is not an optimization you do later, it is the thing you architect around from the start.

Anthropic's numbers: about 25% lower bills for typical workloads, up to about 45% for highly agentic ones, based on four weeks of their own August usage. Take vendor-supplied savings numbers with the usual salt, but the mechanism is real and the direction is not in dispute. A 75% cut on the line item that dominates agentic spend produces a large cut in agentic spend.

The strategic read is more interesting than the discount. Anthropic is repricing the specific thing that makes long-running agents expensive, at the same moment it ships a model whose biggest gains are in long-running agentic work. That is not a coincidence, it is a bet. They are betting that the workload that grows is agents running for hours, and they are removing the cost objection to running the expensive model on it.

Should You Switch From Fable 5?

If you are already on Fable 5: yes, immediately, and there is nothing to think about. Same base price, better model, cache reads cost a quarter of what they did. Change the model ID.

If you are on Opus 5 and stayed there because Fable doubled the price: this is the release where that calculation gets genuinely close. Opus 5 is still half the base rate. But if your workload is agentic and cache-heavy, Fable 5.1's effective cost per session may land nearer to Opus 5 than the sticker price implies, and Fable 5.1 beats Opus 5 by 3.5 points on Terminal-Bench 4.0 and by 23 points on Terminal-Bench-Science.

Do the arithmetic on your own traffic instead of trusting either of us. Pull a week of usage, split it into fresh input, cache writes, cache reads, and output, and reprice it both ways. If cache reads are over half your input volume, Fable 5.1 has probably just become your cheapest good option. If you are doing mostly one-shot calls with short prompts, none of this touches you and Opus 5 remains the sane default.

And if you are routing between models rather than picking one, which is what most serious production setups do now, this changes the routing table rather than the winner. Model routing with fallbacks exists precisely so a price change like this is a config edit instead of a migration.

The Safeguards Changes Are Better Than Expected

Three numbers from the announcement that matter if you have ever been refused something reasonable.

Cybersecurity filtering has 60% fewer false positives, and vulnerability discovery is now permitted while exploit generation is not. Biology safeguards trigger 85% less often for benign requests on elementary and medical topics. And Anthropic describes it as their most robust model to date on external prompt injection benchmarks.

The false positive numbers are the ones I care about. A safety system that refuses legitimate security work is not safe, it is just unhelpful in a way that pushes people to models with worse safeguards. Cutting false positives by 60% while keeping malicious-request refusal rates comparable is the right trade, and it is measurable in a way that "we take safety seriously" is not.

If you are building anything that takes untrusted input into a model, the prompt injection claim is worth verifying against your own threat model rather than taking on faith. I wrote about defending against prompt injection and the honest position has not changed: a more robust model reduces your exposure and does not eliminate it, and architecture is still doing most of the work.

One more change that will bite someone: new API accounts cannot manually edit prior context in multi-turn conversations. This is an anti-distillation measure, aimed at blocking documented model extraction techniques. If you had a legitimate reason to rewrite conversation history, and there are a few, check whether your account is affected before you upgrade.

The Bigger Picture

Two releases in a row now, Anthropic has shipped a model where the headline capability gains are concentrated in agentic work and the pricing changes are aimed at making agentic work affordable. The consumer-facing chat benchmarks moved three points. The "can this thing run unattended for two hours" benchmarks moved thirty percent.

That tells you what they think the product is. Not a chatbot that answers questions. A worker that runs a loop.

Whether that bet pays off depends on something outside Anthropic's control, which is whether the rest of us build systems that can actually supervise a model running unattended for two hours. Cheaper cache reads remove one obstacle. They do not remove the observability problem, which is still the thing that turns a promising agent into an incident nobody can reconstruct.

The model got better at not giving up. We still have to get better at watching it.

Frequently Asked

When was Claude Fable 5.1 released? September 1, 2026, alongside Claude Mythos 5.1, on the Claude API, Bedrock, Vertex AI, Azure, Claude Code, Claude Enterprise, Claude Cowork, and Claude.ai.

How much does Claude Fable 5.1 cost? $10 per million input tokens and $50 per million output tokens, unchanged from Fable 5. Cache reads are $0.25 per million, down 75% from $1.00.

What is the difference between Fable 5.1 and Mythos 5.1? The same model with different safeguard levels. Mythos 5.1 has reduced restrictions on cybersecurity and biology research and is available only through the Cyber Verification Program or Life Sciences Verification Program, currently US-only.

Is Fable 5.1 better than Opus 5? On agentic and terminal benchmarks, yes, by a clear margin. It is also twice the base price. Whether it is better for you depends on how cache-heavy your workload is.

What is the model ID? claude-fable-5-1.

Did SWE-bench scores actually hit 95%? Anthropic reports SWE-bench Pro at 81.2 in the system card. The 95% figure comes from third-party leaderboards measuring SWE-bench Verified, which is a different benchmark.

If you run agents, go pull last week's usage and reprice it before you do anything else. That number, not the benchmark table, is what should decide this for you.

I Built beseen.so Because Every AI Visibility Tool Sells You a Thermometer and Calls It Medicine

Alex Cloudstar — Sat, 05 Sep 2026 19:24:57 +0000

I Built beseen.so

Yesterday I published a post about zero-click search hitting 68%, and buried in the middle of it was a complaint I have been chewing on for months:

Every tool here tells you that a competitor got named for prompt seventeen. None of them tell you which page to change or what to put on it. You are left holding a diagnosis and no prescription.

I did not put that line in as a teaser. I put it in because it is the exact frustration that made me build something, and today that something is live.

It is called beseen.so. It tracks your Google positions and the prompts where AI assistants name a competitor instead of you. Then it writes the fix. You apply it. It re-checks what moved.

That last sentence is the whole product, and the middle third of it is the part that does not exist anywhere else.

The Problem, Stated Precisely

Here is the gap, as concretely as I can put it.

Rank trackers tell you where you sit in Google for a keyword. That has been a solved, commoditized product for fifteen years and it is increasingly answering a question that matters less every quarter, because 68% of searches now end without a click.

Citation trackers, the newer category, tell you how often an assistant names you. Profound, Peec, Otterly and the rest all do a version of this competently, at somewhere between $25 and $399 a month depending on how many prompts you want watched.

Neither one tells you what to do on Tuesday morning.

You open the dashboard. It says you were named in 12 of 25 prompts, down from 14. A competitor was named in 19. There is a chart. The chart is red.

Now what? You know you have a problem. You do not know which page caused it, what that page is missing, or what to write instead. So the realistic outcome is that you stare at it, feel bad, close the tab, and pay again next month for the same feeling with a different number on it.

That is a thermometer. It is genuinely useful to own a thermometer. It is not medicine.

What beseen Actually Does

Four steps, in a loop.

1. It scans. Your prompts run against ChatGPT, Claude, and Perplexity weekly, plus Gemini. It also pulls Google rank positions, refreshing the 25 most stale keywords from a tracked set of 50 per site. So you get both halves in one place, classic rankings and assistant citations, instead of paying two vendors to show you two thirds of the picture.

2. It finds who got named instead. Not just "you were absent." Which competitor got the slot, on which prompt, on which engine. That distinction matters, because "nobody was named" and "a specific competitor is named every single time" are entirely different problems with entirely different fixes.

3. It writes the rewrite. This is the part that does not exist elsewhere. For pages that already rank, you get a concrete rewrite: title, meta description, H1, and section structure. Not "consider improving your content." The actual text. For gaps where you have no page at all, you get a brief for the page you are missing.

Every fix comes two ways: as copy you paste, or as a prompt you hand to a coding agent. If you run Claude Code or Cursor against your own site, which is how I work on everything now, you paste the prompt and the agent makes the change. That is a two-minute job instead of an afternoon.

4. It re-checks. Next week's scan tells you whether the answer actually moved. That closes the loop, and the loop is the entire reason to pay for something monthly rather than buying a one-off audit.

The Thing I Refuse To Do

beseen never gets write access to your site. Ever.

There is a whole category of tools right now that will connect to your CMS and publish changes for you, and I understand the appeal. I am not building it. Two reasons.

The first is that handing an automated system publish rights to your website is a category of risk I would not accept on my own properties, so I am not going to ask anyone else to accept it on theirs. I have written before about AI-generated code and technical debt, and a model editing your live marketing pages unsupervised is the same problem with worse blast radius and no code review.

The second is that the rewrite is a suggestion and suggestions should be read. Half the value of getting a concrete rewrite is that you look at it and think "no, that is wrong about what we do," and fix that. If it auto-publishes, you never have that thought.

So: it writes, you apply. Always.

What It Deliberately Is Not

I would rather tell you what beseen does not do up front than have you find out after paying.

No backlink data. There are excellent tools for that and I am not going to build a worse one. If you want backlink analysis, buy Ahrefs.

No keyword research. Same reasoning. beseen tracks the keywords and prompts you care about. It does not brainstorm them for you.

No auto-publishing. Covered above. Never.

No one-off audits. This is built as a weekly loop, not a PDF. If you want a single snapshot report, the free checks will give you one and you should not subscribe.

No promise of results in two weeks. This one is important and it is the reason I put it on the pricing page rather than hiding it. Movement takes three to four weeks. An assistant answers from a live search, which means a rewritten page has to be crawled and indexed before it can be cited at all. Anyone selling you a two-week turnaround on AI answers is selling you a coin flip.

I would rather lose the sale to someone promising faster than have a customer churn angry in week two because I let them expect something physics does not allow.

Who This Is Actually For

Here is where beseen diverges from most of the category, and it is the part I find most interesting.

Almost every AI visibility tool is built for software companies, because software companies are where the category started and where the marketing budgets are. But the actual problem is much broader than that, and much less served.

Any business a customer can be pointed at by name has this problem. Restaurants. Hotels. Dental and legal practices. Plumbers. Garages. Gyms. Agencies. And the software companies, sure.

Think about what "which is the best physiotherapist in this neighbourhood" does now. Somebody used to search that and see ten results and pick one. Now they ask an assistant and get named three practices. If you are not one of the three, you did not rank eleventh. You were not in the conversation at all, and unlike a search result page there is no second page for you to be on.

That is a category of business that has never bought an SEO tool in its life, is not going to learn what a citation share metric is, and needs someone to hand them a sentence to put on their website. Which is exactly what beseen produces.

I am not pretending I have cracked distribution to that audience. I have not. It is a completely different motion from selling to developers, and I have written enough about distribution being the real moat to know that having the right product for an audience and being able to reach that audience are separate problems. But it is who the thing is built for, and pretending otherwise on the pricing page would be dishonest.

Pricing, and Why There Are Two Free Checks

Three tiers.

Starter, $99/month. One site. 25 prompts weekly across ChatGPT, Claude, and Perplexity, Gemini monthly. Rewrites for the pages that already rank, briefs for the pages you are missing.

Growth, $199/month. Five sites, 25 prompts per site, so 125 tracked prompts, all four engines weekly including Gemini.

Agency, $399/month. Ten sites, 40 prompts per site, 400 tracked prompts, weekly on everything.

Monthly, in advance, cancel whenever. No refunds as policy, though I look at problems individually because I am one person and I would rather sort out a genuine issue than win an argument. 30 days notice on any price change.

Before any of that: two free checks, no card, no expiry. One allowance per person, running Starter limits, so one site and 25 prompts across all four engines.

Two, specifically, and not one. The first check gives you the full diagnosis with rewrites and briefs. The second exists so that after you apply the fixes and wait, you can measure whether they worked, without having paid me anything.

That is deliberate. I am asking you to believe that page rewrites can change what an assistant says about you. That is a claim, and claims should be testable before money changes hands. Run the first check, do the work, wait a month, run the second. If nothing moved, you learned something real for free and you should not subscribe.

Nothing further runs until you pick a plan. There is no drip of value designed to make you forget you are on a free tier.

Why I Built This One and Not Something Else

I have shipped a lot of things this year. roastme.gg and ownthe.day were both built inside a week, largely for the fun of it, and I was honest in both posts about the fact that a novelty mechanic spikes and decays. justship.now was the opposite bet, the slow compounding kind, and it is currently the featured project on this site.

beseen is a third thing, and the honest reason it exists is that I kept hitting the problem myself.

When I shipped roastme.gg I ran it through ChatGPT's live search by hand, one prompt at a time, to see whether it would surface for anyone not already looking for it by name. That was a genuinely useful exercise and a genuinely stupid way to spend an evening. I did the same manual check for justship.now. And every time, I ended up with the same two thoughts in sequence: "so I am not being named," immediately followed by "so what do I write."

Nothing I could buy answered the second one. The tools that tracked it well cost $200 a month to tell me a thing I could figure out in an evening for free, and then stopped exactly where the useful part started.

That is a decent reason to build something. Not a market size projection. A problem I hit four times in six months, with a fix I could describe in one sentence.

Whether that turns into a business is a separate question and I have been wrong about it before. I killed MarketingNow. I watched Colaunchly flatline. I have a domain graveyard like everyone else who ships a lot. This might join them, and if it does I will write that post too.

What I Want From You

If you have a site and you have ever wondered whether an assistant names you when someone asks about your category: go run a free check. It costs nothing, it does not need a card, and worst case you learn that you are doing fine, which is worth knowing.

If it says you are not being named, look at the rewrite it gives you. That is the part I care most about getting feedback on, because the diagnosis is table stakes and the prescription is the whole bet. Tell me if it is wrong. Tell me if it is generic. Tell me if it wrote a title tag that misunderstands your business, because that is exactly the failure mode I need to hear about while it is still early enough to fix properly.

You can start here: beseen.so.

Frequently Asked

What is beseen.so? A weekly AI visibility and search tool. It tracks your Google positions and which prompts cause ChatGPT, Claude, Perplexity, and Gemini to name a competitor instead of you, then writes the page rewrites to change that and re-checks whether the answers moved.

How is it different from Profound, Peec, or Otterly? Those tools track and report. beseen tracks, then writes the concrete fix: title, meta description, H1, and section structure, delivered as copy to paste or as a prompt for a coding agent.

Which AI engines does it check? ChatGPT, Claude, and Perplexity weekly on every plan. Gemini monthly on Starter, weekly on Growth and Agency.

Does it publish changes to my site? No, and it never will. beseen has no write access to your site. Every fix is something you apply yourself.

Is there a free trial? Two free checks, no card required, no expiry, one per person. They run Starter allowances: one site, 25 prompts, all four engines. The first diagnoses, the second lets you measure whether your fixes worked.

How long until AI answers change? Three to four weeks, realistically. Assistants answer from live search, so a rewritten page has to be crawled and indexed before it can be cited.

Who is it for? Any business a customer can be pointed at by name. Restaurants, hotels, dental and legal practices, plumbers, garages, gyms, agencies, and software companies.

Does it do backlinks or keyword research? No. Use Ahrefs or Semrush for those. beseen tracks the keywords and prompts you already care about and tells you what to write.

Go run the free check on your own domain. Take the fifteen prompts a real customer would type, not the ones with your brand name in them, and see who gets named.

Startup Directory Submissions in 2026: What Actually Moves the Needle for SEO

Alex Cloudstar — Sun, 30 Aug 2026 20:34:24 +0000

Startup Directory Submissions in 2026: What Actually Moves the Needle

Every few months someone posts a list titled something like "1,000+ Directories to Submit Your Startup" and it makes the rounds in indie hacker circles again. I've submitted to a version of that list at least three times across three different products. I've also run a directory myself now, the "get featured" side of makers.page, and I review submissions for justship.now with my own hands. So I've seen this from both ends: the founder mass-submitting at 11pm hoping for a ranking bump, and the person on the other side deciding which of those submissions are actually worth approving.

I wrote a while back about what actually moved the needle for my own SEO, and I mentioned in passing that I spent months building "random backlinks" before realizing that wasn't the lever that mattered. Directory submissions are the purest version of that random-backlink instinct, so they deserve their own honest look instead of a footnote.

The Old Advice Is Not Entirely Wrong, It's Just Missing a Filter

Here's the annoying thing about directory submission advice: it's not actually false, it's just incomplete in a way that gets people to waste a weekend. The claim "directory submissions still work for SEO in 2026" is true. The unstated part that gets left out of every listicle is that it's only true for a specific kind of directory, and the mass-submission approach the listicles are built around is exactly the approach that stopped working years ago.

Low-quality directory spam, the kind that exists purely to host outbound links with zero actual traffic or editorial review behind them, doesn't just fail to help anymore. It can actively hurt you, because Google's link-quality models are specifically tuned to discount, and in some cases penalize, patterns that look like automated mass submission. Meanwhile, strategic placement in a smaller number of high-quality, niche-relevant directories that real humans actually browse is where the actual lift lives. Quality over quantity isn't a hedge here, it's the entire mechanism.

What the Data Actually Shows

The numbers floating around SEO circles this year put real shape on that claim, and they're worth stating plainly even though I can't independently verify every figure and you shouldn't treat any single number as gospel. SaaS products that submit to somewhere around 30 to 50 quality, relevant directories have reportedly seen domain authority lifts in the range of 5 to 15 points over a 3 to 6 month window. That's a meaningful swing for a metric that usually moves in single digits over that timeframe through content alone. For a brand new domain specifically, directory listings also create an early trust signal, something for a crawler to find besides your own homepage in the first few weeks before you've earned any organic links at all.

The highest-value tier is the small set of directories with genuinely high domain rating, places like G2 and Crunchbase sitting in the 90-plus range, where a single listing carries more weight than a dozen mediocre ones combined. Product Hunt is the odd one out on this list. It sits around DR 92, which sounds like the single best link you could get, but Product Hunt doesn't actually give you a dofollow link. What it gives you instead is a genuine traffic spike, somewhere in the range of 1,500 to 10,000 visits on a good launch day, which is a completely different kind of value than a backlink and shouldn't be evaluated on the same axis. I wrote about my own Product Hunt launch a while back, and the traffic and community exposure were the entire point, the backlink was never going to be the reason to show up.

Dofollow Is a Bonus, Not the Whole Point

This is the part that trips people up the most, including me for longer than I'd like to admit. A directory link is worth more than its dofollow status alone suggests, and less than a mass-submission list makes it sound. If you're only counting dofollow links as valuable, you're missing that a nofollow link from a directory with actual daily visitors, actual category browsing, and actual return traffic still does real work: it puts your product in front of people who are there specifically because they're looking for something in your category. That's a warmer visitor than almost any other channel, dofollow or not.

Conversely, if you're chasing dofollow status specifically and submitting anywhere that offers it, you're optimizing for exactly the wrong signal. A dofollow link from a directory nobody visits, with no editorial filter, sitting next to a thousand other unrelated submissions, is close to worthless, and in aggregate across enough spammy directories, it starts working against you instead of for you.

The Framework I'd Actually Use

Ignore the "submit to 1,000 directories" advice entirely. Here's the version that matches what the 2026 data and my own experience running two of these directories actually supports.

Pick 10 to 15 directories, not hundreds. Prioritize relevance to your actual category over raw traffic or raw domain rating. A mid-authority directory that's specifically read by people building the same kind of product you are will outperform a generic high-DR directory that happens to accept any submission.

Weight niche relevance above domain rating. A DR 40 directory that's the actual homepage bookmark of your exact audience beats a DR 70 directory that lists everything from dropshipping stores to enterprise SaaS with no distinction between them. Relevance is what turns a listing into actual clicks, not just an entry in a backlink report.

Treat editorial review as a feature, not friction. When I review submissions for justship.now, the ones I reject are almost always the ones that feel like a copy-pasted form response with zero specificity about what the tool actually does differently. If a directory requires you to write something real instead of pasting your tagline, that friction is exactly what's keeping the directory worth being listed in. Directories with zero review queue are the ones most likely to be the low-quality spam networks the data is warning you away from.

Don't skip the ones that don't give dofollow. Product Hunt is the clearest example, no dofollow link, and still worth showing up for, because the traffic and the social proof of a launch-day number are their own reward independent of what Google sees.

Diversify, don't stack. Directory submissions are one piece of a broader link-building strategy, not a strategy on their own. If directory links are the only backlinks pointing at your domain, that pattern itself looks unusual to the same models that are watching for mass-submission spam. Pair it with actual content, actual outreach, and actual mentions from people talking about your product because they want to, not because you asked them to fill out a form.

Where This Connects to Getting Cited by AI, Not Just Ranked by Google

I ran a live experiment a few weeks back testing whether fixing my own on-page content actually got me cited inside ChatGPT's search results, and one thing that stood out is that citation share in a crowded category leans heavily on other sites mentioning you, not just your own page copy. A directory listing is exactly that: a third-party site, ideally one with real authority in your category, stating that your product exists and describing what it does. That's not just a Google signal anymore. It's raw material for whatever crawls the web to answer questions inside an AI chat interface too. A good directory listing is doing double duty in 2026 in a way it wasn't five years ago.

What I'd Tell a Founder Deciding Where to Spend an Afternoon

Skip the giant submission lists entirely. Spend that same afternoon finding the 10 to 15 directories your actual target user has genuinely bookmarked, and write a real, specific submission for each one instead of a copy-pasted tagline. If a directory has a review queue and rejects lazy submissions, that's a point in its favor, not against it. And don't confuse "got a dofollow link" with "got in front of the right people," because those are two different wins and the second one is usually worth more.

If you're on the other side of this and you've built something worth listing, both directories I run take real submissions: makers.page for a featured profile with a dofollow link if you're approved, and justship.now if what you've built is a tool developers and indie hackers would actually reach for.

Frequently Asked

Do directory submissions still help SEO in 2026? Yes, but only for high-quality, niche-relevant directories with real editorial review. Mass submission to low-quality directory networks can hurt more than it helps.

How many directories should I actually submit to? Somewhere around 10 to 15, chosen for relevance to your specific category, not hundreds chosen for raw volume.

Is a nofollow directory listing worth it? Often yes, if the directory has real traffic and your audience actually browses it. Product Hunt is the clearest example: no dofollow link, still worth launching on for the traffic alone.

What actually moves domain authority, based on the current data? Submitting to 30 to 50 quality, relevant directories has reportedly produced domain authority lifts in the 5 to 15 point range over 3 to 6 months, though treat any single number here as a directional estimate, not a guarantee.

Does this help with AI search too, or just Google? It can help both. A directory listing is a third-party mention of your product, which matters for citation in AI answer engines the same way it matters for traditional backlink profiles, maybe more, since those engines lean heavily on what other sites say about you.

If you're deciding where to list your own product next, start with the directories your actual users already have bookmarked, not the longest list you can find.

Everyone’s Making Leaderboards Now: Inside outbid.lol’s Wild Week, and Why I Built ownthe.day Differently

Alex Cloudstar — Sun, 30 Aug 2026 20:34:23 +0000

Everyone's Making Leaderboards Now

Three days ago I wrote about shipping roastme.gg, a site where you pay money to get publicly insulted by AI, ranked on a wall by how much it hurt your wallet. Before that, I wrote about getting banned from Reddit and mass-reported off X and saying I'd stop over-investing in rented platforms.

I bring that up because in the middle of writing both of those posts, a German engineer named Jonathan Wilke spent three hours on a Saturday building something that would go on to make more money in two days than most SaaS products make in a year. He called it outbid.lol, and by the time I sat down to write this, at least a dozen people had copied it, remixed it, or built a leaderboard that ranks the leaderboards.

I have a personal stake in this story, because the mechanic outbid.lol runs on, pay real money to hold a public rank, is the same mechanic I already shipped for roastme.gg. So when it blew up, I didn't just watch it as a spectator. I watched it as someone who'd already built the thing next door and had opinions about what it got right and what it left on the table. Those opinions turned into a second project, ownthe.day, which I'll get to. But first, the story that's actually worth telling: how a three-hour weekend build turned into the fastest-growing web trend of August 2026.

What outbid.lol Actually Does

The idea is almost insultingly simple, which is exactly why it worked. You submit your app, your product, your website, or in some of the copycats, yourself, to a public directory. Rank on that directory is determined by one number: total dollars paid. Pay more than whoever's currently in first place, and you take first place. Someone pays more than you, you get bumped down. That's the entire product.

The rules underneath it are what keep it from collapsing into chaos the first day. The minimum bid is $2, in whole dollar amounts, no cents. If two entries tie on total spend, the older entry keeps priority, which rewards showing up early instead of just outspending everyone forever. If you've already got a bid in and someone outranks you, you don't have to match their full amount to get back to the top, you only owe the difference between your old bid and theirs, plus a dollar. That one rule alone is the difference between a leaderboard people abandon after losing once and a leaderboard people keep coming back to fight over.

There's also a premium move: pay five times whatever the current top bid is, and you lock the first page position for three straight hours, immune to being outbid during that window. It's a pressure valve. Without it, a determined bidder war between two well-funded founders could turn into a bidding ping-pong match that updates every ninety seconds, which is fun to watch once and exhausting to actually compete in.

Wilke also filtered for quality on the way in. Tracking parameters get stripped from submitted URLs, chat and referral links get blocked outright, because a leaderboard that fills up with spam links stops being a leaderboard and starts being an ad network nobody trusts. That distinction matters more than it sounds like it should, and it's the same lesson I learned the hard way tuning the roast quality tiers on my own site: the mechanic only works if what surrounds it stays clean.

The Numbers That Made It a Story

Here's what actually happened, and the timeline is the part that still doesn't feel real when I type it out.

outbid.lol launched on a Saturday. Within twelve hours it had logged more than ten thousand visitors, mostly from people sharing screenshots of the leaderboard in developer Slack channels and group chats. By the next morning it had crossed two hundred thousand visitors. Within fifty-four hours it passed one million visitors and more than $125,000 in revenue, all of it collected two and five dollars at a time from people paying to rank a link.

The top of the leaderboard turned into its own spectacle. Joni AI took the number one spot with a bid over $14,000. Tibo Maker was right behind at just over $13,000. Watching two real, funded products spend five figures apiece to sit at the top of a leaderboard that resets in value the moment someone outbids them is the kind of thing that doesn't need commentary, it just needs a screenshot, and screenshots are exactly what carried the whole thing across the internet in the first place.

Wilke reportedly turned down a six-figure acquisition offer before the first day was even over. Whether that offer was real or embellished in the retelling, I have no way to verify, but the fact that it's plausible tells you everything about how fast this moved. A three-hour weekend project generating acquisition interest before Monday isn't normal, even by indie hacker standards, and this happened during a summer that's already been unusually strange for anyone building software in public.

Why a Pay-to-Rank Board Works So Well

I already wrote about this exact psychology when I explained why I built roastme.gg the way I did, but it's worth restating here because outbid.lol is the cleanest possible proof of the theory.

A pay-to-rank leaderboard converts something abstract, "I want attention for my product," into something concrete and visible, a dollar figure sitting next to your name in public. That's a fundamentally different experience than a Product Hunt upvote or a star on GitHub. Those signals are free, which means they're cheap to fake, slow to earn, and easy to ignore. A dollar amount paid in real money and displayed publicly next to your name is none of those things. It's proof of conviction that anyone can verify at a glance, and proof of conviction is inherently more interesting to look at than a vote count.

It's also screenshot-native by design. A leaderboard where the top three spots just spent five figures fighting each other is a story that tells itself in a single image, no caption required. Nobody needs context to understand "these two people just spent $27,000 combined to be number one on a website," and that legibility is what let it travel through Slack channels and group chats faster than any post explaining it in words ever could.

And the build itself was small on purpose. One table, one payment flow, one sort order. No accounts required beyond what's needed to submit and pay. That's the same lesson I keep learning every time I ship something small: a complicated product is a complicated launch, and the products that spread fastest are usually the ones you can fully explain in one sentence.

The Clone Wave Arrived Within a Day

This is the part of the story that tells you the trend had officially become a trend. Within twenty-four hours of outbid.lol taking off, the copies started landing, and most of them tried to fix something about the original.

ClaimRank and WatchBid launched as near-identical clones chasing the same audience with a different name. betteroutbid positioned itself explicitly as an improved version of the original, which is a bold pitch for a category that's two days old. iamtherichest.lol took the mechanic and pointed it at people instead of products, a personal-status leaderboard where individuals bid to rank above each other, which is either the natural next step or the darkest possible version of the idea, depending on your mood that day. bottombid inverted the whole thing, lowest bid wins the top spot, which is a clever enough twist that I'm mildly annoyed I didn't think of it first.

Payluck.lol mutated the mechanic into something closer to a slot machine: every listing costs a flat $9.95, but before you pay you get shown a random coupon, and whatever discount you draw locks to your domain permanently. Bidboard.lol went the other direction and made the base listing free with a dofollow link included, charging only for the visible ranking on top of it, which quietly turns "pay to rank" into something closer to a legitimate advertising product with better manners. And then, because the internet cannot help itself, someone built outbidception.lol, a leaderboard that ranks the leaderboards. A meta-directory for a genre of website that's four days old. That last one is the clearest signal I've seen all year that a trend has fully lapped itself.

Most of these clones, according to the people covering the space in real time, are already struggling to hold traffic. And the reason why is the actual lesson buried in all of this: the value in outbid.lol was never really the mechanic. Anyone can copy a sort-by-dollars-paid query in an afternoon. The value was the concentration of visitors that showed up because it was first, because it was novel, and because the people bidding four figures wanted an audience that was already there, not one they'd have to build from zero on a clone. A leaderboard with no visitors isn't a leaderboard, it's a spreadsheet with a payment form bolted onto it.

I Built a Leaderboard Too, But I Changed the One Thing That Matters

Here's where I stop reporting on someone else's launch and admit I built one of my own, because I'd already been circling this exact category before outbid.lol made it the story of the month.

roastme.gg proved to me that a pay-to-rank mechanic is legitimately fun to build and legitimately fun to watch. But it also has a structural problem that outbid.lol inherited too, one that becomes obvious the moment a leaderboard has more than about ten entries on it: rank #47 means nothing. An infinite scrolling list of "people who paid some amount of money" turns into noise past the first page, and the only entries anyone actually looks at, screenshots, or talks about are the top three. Everyone below that is paying to be part of a list nobody reads.

So when I sat down to build ownthe.day, I kept the part of the mechanic that clearly works, real money, publicly visible, instantly legible, and I threw out the infinite list. There's no rank #2 through #500 on ownthe.day. There's exactly one slot.

How ownthe.day Works

The tagline says it plainly: today has one owner. There's no leaderboard column stretching down the page. There's a single spot, whoever holds it right now, and a countdown clock ticking toward zero.

You pay to take the spot, and the payment does two things at once, not one. It makes you the current owner, and it adds time back onto the countdown clock. That second part is the piece that changes everything about how the site behaves. On outbid.lol, the leaderboard just sits there passively until someone decides to act on it. On ownthe.day, the clock is always moving toward zero, whether anyone shows up or not, which means the site has a built-in expiration date baked into the product itself, not just a vibe.

And here's the twist that makes it more than a reskinned version of the same idea: if the clock hits zero before anyone pays to reset it, the site dies. Permanently. Whoever holds the spot at that moment gets immortalized as the last owner, frozen in place forever, and the game itself ends. Every day resets at midnight UTC into a fresh round, a brand new day with a brand new empty slot to claim, but the doomsday clock underneath it is real and it isn't decorative copy, it's an actual constraint on how long the entire project gets to exist. Every payment isn't just competing for status, it's literally keeping the lights on.

That's a genuinely different kind of stakes than "I paid more than the last guy." It's closer to a countdown-timer domain auction crossed with a dead man's switch, and it produces a completely different kind of tension than an infinite leaderboard does. On an infinite list, you're competing against everyone who's ever paid. On ownthe.day, you're competing against exactly one other thing: a clock that doesn't care who you are.

Why a Single Owner Beats an Infinite List

I want to be specific about why I think this is a real product decision and not just a different coat of paint, because it would be easy to wave my hands and say "mine's different" without explaining what that actually buys you.

An infinite pay-to-rank leaderboard has a scaling problem built into its own success. The more popular it gets, the more entries pile up below the fold, and the less any individual entry is worth, unless you're willing to keep spending to stay in the visible top few. That's great if you're Joni AI with $14,000 to spend on a Saturday. It's a much worse deal for the ten thousand people who paid the two-dollar minimum and now sit somewhere past page four, functionally invisible, having paid for a listing that nobody will ever scroll far enough to see.

A single-slot, clock-based mechanic doesn't have that problem, because there's nothing below the fold to disappear into. You either hold the spot right now or you don't. There's no rank #200 to be quietly forgotten in. And the daily reset means the game doesn't just run once and then decay into an ever-longer, ever-less-relevant list the way a permanent leaderboard eventually does. It's a fresh contest every twenty-four hours, which is a much more natural fit for the kind of recurring attention that keeps people checking back, the same reason a daily puzzle game outlasts a one-time viral quiz.

The self-destruct clock is the part I'm most attached to, honestly. It means the project can't just coast on inertia the way a lot of pay-to-play sites eventually do once the initial wave of attention moves on. Either people keep showing up and paying to keep it alive, in which case it's proof the mechanic still has real pull, or the clock genuinely hits zero and the site actually dies, with the last owner frozen in place as a permanent record of exactly when the run ended. There's no long, awkward decline where a leaderboard limps along with the same stale top three for six months. It either lives because people choose to keep it alive today, or it ends cleanly. I'd rather build something with real stakes attached to it than something that just quietly stops mattering.

What This Trend Actually Teaches Indie Hackers

A few things stood out to me watching this play out in real time, and they're the same lessons I keep relearning every time one of these small, sharp mechanics takes off.

Simple beats clever, almost every time. outbid.lol is one sort order and a payment form. ownthe.day is one countdown clock and a payment form. Neither product has a dashboard, a settings page, or an onboarding flow, and that's not an accident, it's the entire reason either one could be described, understood, and shared in a single sentence.

Real money is a stronger signal than any free interaction you can design. Likes, votes, and stars are free, which means they're abundant and cheap to interpret. The moment you attach a real price to a public action, even a two-dollar one, you've created a signal that's actually worth paying attention to, because someone had to mean it enough to reach for their card.

The mechanic isn't the moat, distribution is. I said this explicitly when I wrote about distribution being the actual moat for anything you build, and outbid.lol's own clone wave proved it inside of a week. A dozen people copied the exact mechanic within a day. Almost none of them kept the traffic, because the traffic was never really about the mechanic, it was about being first with an audience already watching.

Scarcity is a design choice, not an accident. outbid.lol's scarcity comes from being first. ownthe.day's scarcity is built into the product itself, one slot, one clock, one owner at a time. If you're building in this space, decide on purpose what makes your version scarce, because "infinite list, sorted by money" runs out of tension the moment the initial wave of attention passes.

Own the part of your project that's genuinely different, even if the category is crowded. I could have built a straight outbid.lol clone in an afternoon and probably picked up some of the overflow traffic while the trend was hot. Instead I built the version I actually wanted to exist, one with real stakes and a real ending built in, because that's the only kind of clone that has a shot at outliving the moment that made the category famous in the first place.

Frequently Asked

What is outbid.lol? A public leaderboard where you pay real money, minimum $2, to hold the top rank. Outbid someone and you take their spot; get outbid and you fall. Built by Jonathan Wilke in roughly three hours and launched in August 2026.

How much money has outbid.lol made? Over $125,000 in its first 54 hours, with more than a million visitors and top bids exceeding $14,000, according to reporting on the launch.

What's the difference between outbid.lol and ownthe.day? outbid.lol is an infinite leaderboard sorted by total dollars paid. ownthe.day has exactly one slot. You pay to take it and to add time to a countdown clock, and if that clock hits zero, the site is gone for good and the last owner is immortalized permanently.

Is ownthe.day actually going to shut down? Yes, that's the point. If enough time passes without anyone paying to reset the clock, the site dies for real and stops running. It's not a marketing line, it's how the product is built.

Are these pay-to-rank sites worth building right now? The mechanic itself is cheap to copy and mostly worthless without an audience already paying attention. If you're going to build one, the only reason it survives past week one is a genuinely different hook, not a faster clone of whatever's currently trending.

If you want to see whether today still has an owner, or you're willing to bet the countdown clock keeps running on your dime, go look: ownthe.day. Today has one owner. It might as well be you.

justship.now Is My New Front Door: Why a Curated Tools Directory Beat Out Another SaaS

Alex Cloudstar — Sun, 30 Aug 2026 20:33:50 +0000

justship.now Is My New Front Door

If you've read anything else on this blog, you know the pattern by now. I ship something, I write about why, and a few weeks later I'm explaining why I changed my mind about half of it. roastme.gg and ownthe.day were both built and shipped inside a single week, in public, warts included. This post is a quieter version of that same habit, applied to my own portfolio instead of a new product.

I just swapped the number one project slot on my own site. For a while that spot belonged to makers.page. As of this week, it's justship.now.

Nobody asked me to explain that swap. I'm doing it anyway, because the reasoning is more interesting than "I like it better now," and because a chunk of you reading this are indie hackers deciding what your own front door should say about you.

What justship.now Actually Is

justship.now is a curated directory of tools for developers, indie hackers, and startup builders, paired with a build-in-public blog I write myself. That's the one-line version, and it undersells it a little, so here's the longer one.

The directory currently runs across more than 20 categories: boilerplates, frameworks, UI and design, icons, component libraries, AI tooling, databases, ORMs, authentication, backend frameworks, APIs, internationalization, testing, jobs and queues, payments, accessibility, storage, hosting, CI/CD, DevOps, CMS, monitoring, logging, email, marketing, and analytics. Browse it at justship.now/browse and you'll find well over a hundred individual tools sorted into those buckets, each with a short, opinionated description instead of a generic one-liner pulled from the tool's own marketing page.

That opinionated part matters more than it sounds like it should. If an entry says a tool is "worth paying for," that's me telling you I've actually used it and think the price is justified, not a sponsor telling you that. If an entry says "open-source" or "MIT-licensed," that's a signal I put there because I know indie hackers specifically care about that detail before they care about feature lists. Nothing on the directory is a paid placement. There's no "featured" tier you can buy your way into. The ranking a tool gets is based on whether I think it's actually good, not on whether anyone wrote me a check.

Underneath the directory sits the blog, which is the part most directories don't bother with. It's not a changelog. It's build-in-public writing about the actual process of shipping things, including a post on mybutler, the local-first AI assistant I wrote about here too, and pieces on domain metrics and the harder truth that building software got fast while getting anyone to actually use it didn't get any easier. Same voice you're reading right now, just living on a second domain.

Why a Curated Directory Instead of Another Crowdsourced List

I looked at what already exists in this space before building anything, because "tool directory for developers" is not an empty category. It's a genuinely crowded one, and it's worth being honest about that instead of pretending justship.now showed up in a vacuum.

There are GitHub "awesome lists" for basically every stack imaginable, community-maintained, free, and often excellent, but they live and die by whoever's still willing to merge pull requests two years after they made the repo. There are aggregator directories like PeerPush and 1000.tools that organize submissions by category and let the crowd do the curating. There's Product Hunt, which is less a directory than a daily popularity contest, useful for a launch-day spike and mostly useless six months later once your listing has scrolled off the front page of anyone's memory. And there are directories that explicitly cap themselves, like the 1000-tool list that charges a small submission fee specifically to filter out low-effort spam, which tells you something honest about what happens to a directory once submissions are free and unmoderated.

Every one of those models solves a different problem than the one I actually wanted solved. An awesome list scales, but nobody's actually vouching for any individual entry beyond "it got merged." A crowdsourced directory scales even further, but the same lack of a real filter that lets it scale is what lets it fill up with dead links and abandoned projects nobody prunes. Product Hunt optimizes for launch-day noise, not for "what should I actually reach for in month six of building this."

justship.now doesn't scale the way any of those do, and that's the point, not the limitation. Every entry is something I've either used myself, watched a founder I trust ship with, or dug into closely enough to have an actual opinion about. That's a smaller list than a crowdsourced one will ever be. It's also a list where "it's in there" means something more specific than "someone filled out a form." If you've read my piece on why generic link-in-bio tools fail founders, this is the same argument applied one level up: a list of buttons tells you nothing, and neither does a list of tools nobody's actually vetted. Curation is slower and it's the only version of this that I'd trust enough to send a friend to.

Why It Beat makers.page for the Top Spot

Here's the part that's specific to my own site rather than the wider argument about directories. makers.page isn't going anywhere. It's still live, submissions for the featured directory side are still open, and I still believe in what it's building toward. But it currently has two halves that are in genuinely different states. The "get featured" side is fully open right now, free review, dofollow profile if you're approved. The Marketing Assistant MCP, the part that drafts channel-native social posts from inside the coding agents you already run, is still in early access and waitlist.

I didn't want the very first thing a visitor to my site clicks on to be something half-gated behind a waitlist, no matter how good the gated half eventually turns out to be. justship.now has no waitlist anywhere in it. You can browse the full directory right now, and if you're a builder with a tool worth listing, you can submit it right now too, no approval queue standing between you and being live on the page. The number one slot on my own portfolio is the one place where I want zero friction between "someone lands here" and "someone gets value," and right now that's justship.now, not the product still finishing its rollout.

That's not a verdict on makers.page long-term. It's a statement about what belongs at the very top of my site today, which is a different question, and one I plan on revisiting again the moment the answer changes. I've swapped this slot before and I'll swap it again.

The Submission Flow, for Builders Reading This

If you build tools and you want in, the flow is intentionally boring: there's a "Submit a Tool" link on the directory, you fill it out, and I review it myself. There's no fee, no sponsored tier, no fast-track for anyone. I'm not going to pretend that scales infinitely, a one-person review queue has an obvious ceiling, but the ceiling is the price for a list that means something. I'd rather have 300 tools I can vouch for than 3,000 I can't.

If you're on the other side of that trade, a maker deciding whether directory submissions are even worth your time, that's a bigger question than this post can answer honestly in a paragraph. I wrote a separate piece specifically on whether startup directory submissions still move the needle for SEO in 2026, with the actual data instead of vibes, because it deserves more than a drive-by mention here.

What This Says About Where I'm Spending My Attention

I've written before about distribution being the actual moat, not the build, and this is that argument showing up in my own priorities instead of someone else's launch. A tools directory with a blog attached isn't a flashy product. It doesn't have a payment flow or a leaderboard or a countdown clock daring people to keep it alive. What it has is something more durable: it's the kind of thing people bookmark, come back to when they're starting a new project, and share with someone else who's stuck picking a stack. That's a slower kind of growth than a viral leaderboard, and it's the kind that compounds instead of spiking and decaying.

Putting it in the number one slot on my own site is me betting on the slow kind, at least for the next chapter. I've been wrong about which project deserves that spot before, and I'll probably be wrong again eventually. For now, this is the one I'd point a stranger to first.

Frequently Asked

What is justship.now? A curated directory of 300+ tools for developers, indie hackers, and startup builders across 20+ categories, paired with a build-in-public blog. Browse it at justship.now/browse.

Is it free to submit a tool? Yes. There's a "Submit a Tool" link on the site, no fee, no paid placement tier. Every listing gets reviewed before it goes live.

Why did you make it your featured project instead of makers.page? makers.page still has its Marketing Assistant MCP gated behind early access and a waitlist. justship.now has nothing gated. I wanted the top slot on my own site to be something anyone can get value from immediately.

How is this different from an "awesome list" on GitHub or a crowdsourced directory like PeerPush? Those scale further than justship.now ever will, on purpose. Every entry here reflects an actual opinion I have about the tool, not a merged pull request or an unmoderated submission form.

Does listing on justship.now actually help with SEO? It can, if you're picking the right kind of directories in general. I broke down the real 2026 data on directory submissions and backlinks in a separate post.

If you want to see what's actually in it, go browse: justship.now. If you've built something worth listing, the submission form is right there too.

I Just Shipped My First Chrome Extension (And It Was Harder Than the Code)

Alex Cloudstar — Sun, 30 Aug 2026 20:33:49 +0000

Update: XPilot the Chrome extension is discontinued. The distribution problem continues at makers.page (get featured + Marketing Assistant MCP). The post below is the shipping story, kept as a build-in-public record.

I just shipped my first Chrome extension.

Not a tutorial toy. Not a "hello world" that never left chrome://extensions. A real Manifest V3 product with Sign in with X, local XP tracking, cloud sync, a privacy policy, and a listing live on the Chrome Web Store.

The product was called XPilot. It turned your activity on X into a game: XP for posts, replies, likes, and reposts. Levels. Streaks. A popup that showed your progress in one click.

It was free on the Chrome Web Store. Sign in with X, earn XP on the stuff you already do. No waitlist. No credit card. That experiment is over; the lessons are not.

This post is the story of what I expected, what actually broke, and what I would tell myself on day one.

If you are about to build your first extension, steal the lessons. Skip the landmines. If you want the current take on founder distribution: makers.page.

Why an extension (and not another web app)

I care about growth on X. Most tools in that space try to write for you. That was never the itch.

The real problem, for me and for a lot of founders I talk to, is consistency. You know you should reply more. You know streaks matter. You still flake when the day gets loud. I have written about why founders struggle on X before. This time I decided to build the habit into the browser instead of another dashboard.

So the bet was simple:

Make X feel like a game people already understand: XP, levels, streaks.

And the distribution bet was equally simple:

Put the product where the habit already happens. Inside Chrome. On x.com.

A dashboard you have to remember to open loses to a popup that opens when you are already posting.

That is why XPilot was extension first, website second. (And yes, this was the same XPilot domain after the earlier AI autopilot pivot. Different product. Same problem: showing up on X without burning the day.)

The stack (keep it boring)

I did not invent a framework.

Extension: WXT + TypeScript, Manifest V3.

UI: plain HTML, CSS, and JS in the popup. Fast, no React tax for v0.1.

Content script: detect my own activity on x.com and twitter.com.

Backend: Next.js on Vercel.

Auth: X OAuth 2.0 with PKCE, then an app JWT.

DB: Postgres on Neon, Drizzle ORM.

Sync: local-first, with a backup about every 12 hours.

WXT was the right call. It handles the annoying MV3 packaging, hot reload in development, and zip for the store. If you are starting today, do not hand-roll Webpack for an extension unless you enjoy pain.

What "done" meant for v0.1

I forced a tiny definition of done:

Sign in with X works
Popup shows XP, level, streak
Activity on X awards XP
Progress survives a reload
Privacy + Terms exist (store requirement)
A ZIP builds without localhost host permissions
A stranger can install from the store and log in

Everything else was a later problem. Opportunity radar, AI coach, seasons: later. Shipping was the boss fight.

Hard part 1: Manifest V3 is not "Chrome apps 2.0"

If your last mental model of extensions is Manifest V2, throw it away.

MV3 service workers go idle. You cannot assume a long-lived background page. Alarms exist for a reason. Persistent connections are not free.

Permissions matter more than you think. Every host permission is a trust tax on the listing review and on users. I kept production hosts to:

x.com / twitter.com (where the game runs)
xpilot.so / www.xpilot.so (where the API lives)

Dev-only: localhost:3000.

That last detail almost bit me in production. More on that below.

Hard part 2: Sign in with X inside Chrome

Browser OAuth is familiar. Extension OAuth is a different animal.

XPilot uses chrome.identity.launchWebAuthFlow. The flow looks clean on a whiteboard:

Extension opens your site's /api/auth/x
Site redirects to X
X redirects back to your callback
Callback redirects to https://<extension-id>.chromiumapp.org/?code=...
Extension exchanges the code for a JWT

In practice, three things tried to murder me.

1. Callback URL must match `APP_URL` exactly

Our production site redirects xpilot.so → www.xpilot.so.

If your OAuth redirect_uri is registered as one host and your app builds the other, X shows a vague "you weren't able to give access to the App" page. No stack trace. No mercy.

Fix: pick one canonical origin. Put it in APP_URL. Register that exact callback on developer.x.com. Stop arguing with DNS.

2. Do not put the exchange code in a URL hash

I originally returned the short-lived exchange code as a hash fragment (#code=...). Fragments are cute until redirects strip them and chrome.identity hands you an empty URL.

Fix: put the code in the query string (?code=...). Parse query first, hash as fallback.

3. Host permissions and CORS will gaslight you

Vercel logs told the truth:

OPTIONS /api/auth/exchange → 204
No POST after it

The store build talked to www, while the manifest only allowed the apex. Chrome fell back to CORS. Preflight "succeeded." The real POST never flew. The popup still showed Sign in with X like nothing happened.

Fix:

Default the production API base to https://www.xpilot.so
Allow both apex and www in host permissions
Add CORS for your published extension ID on the exchange and sync routes as a belt-and-suspenders layer
Pin ALLOWED_EXTENSION_IDS in production so random extensions cannot finish OAuth

Also: the popup often closes when the auth window opens. Your background script must finish login even if the UI is gone. When the user reopens the popup, auth should already be in chrome.storage.

Hard part 3: Detecting activity on a hostile DOM

X's frontend is not an API contract. It is a living organism.

Content scripts that award XP for replies have to survive:

Timeline composers
Modal composers
Cmd/Ctrl+Enter submits
Buttons that unmount before your observer finishes
False positives when someone cancels

I shipped a fail-closed version that broke real replies. Then a looser version that missed intermittent posts. Then a multi-signal version: busy state, clear state, dialog stack, keyboard submit.

If you are building anything on top of a third-party SPA, budget time for "the UI changed and nothing is wrong in your TypeScript."

Hard part 4: Local-first is why a free tier can stay free

I did not want a backend call on every like. I also did not want "free" to mean "runs my GPU bill into the ground."

So XP lives in the extension first. Sync is a backup, not the gameplay loop.

Rules that kept costs and complexity down:

Score actions locally
Sync when due (about every 12 hours), on startup, and after login
Cap what a sync can inflate on the server
Never make the free product depend on continuous API traffic

That architecture is why I can ship v0.1 as a free Chrome extension without feeling like every install is a liability. The game still feels instant when the network is sad. The expensive ideas (AI opportunity radar, deep coaching) can wait until people are actually addicted to the loop.

Hard part 5: The Chrome Web Store is a product surface

Shipping code is half the job. The listing is the other half.

Things that mattered more than I wanted them to:

Privacy policy URL (live on the site, not a Google Doc)
Terms of service
Clear permission justifications
Screenshots that show the actual popup
Category that matches how people browse (we used Social Networking)
A ZIP built for production (no localhost permission leftovers)
Version bumps when you fix auth (0.1.0 → 0.1.1 was not vanity)

Also: trader verification and regional phone issues can block you in weird ways. Budget calendar time for account admin, not just engineering.

What I would do differently next time

Canonical domain on day one. Decide www vs apex before OAuth.
Ship the store ZIP earlier to a private tester. Unpacked success is not store success.
Log the OAuth exchange path. "Still signed out" usually means the token never landed, not that the UI is haunted.
Write privacy/terms while the product is small. It is easier when the data story is short.
Keep v0.1 brutally small. Gamification of real actions beat five AI features I did not ship.

The emotional part (because shipping is emotional)

There is a specific moment when the listing flips from draft to public and the install link works for someone who is not you.

That moment hit harder than any green CI check.

I have shipped websites before. An extension feels different. It lives in the browser chrome. It asks for trust. It sits next to passwords and ad blockers. When someone clicks Add to Chrome, they are not bouncing through a landing page. They are installing you into their daily toolbelt.

That is terrifying. It is also the point. Building in public is one thing. Shipping something people install into their browser is another.

Where this went next

XPilot the extension is discontinued. The same founder-distribution problem continues at makers.page: get your indie startup featured, and a Marketing Assistant MCP that drafts channel-native posts from Cursor, Claude Code, and the agents you already use.

The Chrome Web Store experiment still taught the lessons below. v0.1 was free on purpose: if the habit is not sticky when it costs nothing, it will not be sticky when it costs €29.

Quick FAQ for builders

Do I need React for a Chrome extension?

No. For a small popup, plain HTML is fine. Use React when the UI complexity earns it.

Should I use the official browser APIs or a framework?

Use a framework like WXT unless you have a reason not to. Packaging and MV3 details are not where your product moat lives.

Is scraping a social network's DOM a good idea?

It is fragile and you must stay on the right side of ToS and user expectations. Track the user's own actions in their session. Do not build a stealth scraper and call it a growth tool.

What blocks store approval most often?

Missing privacy policy, unclear permissions, remote code, broken auth, and listings that do not match the binary.

How long did this take?

Longer than the happy-path tutorial. Shorter than "rewrite everything because MV3." Most of the calendar time was OAuth, store packaging, and edge cases on X's UI, not the XP math.

Closing

If you have been waiting to build your first Chrome extension, start.

Pick a problem that only makes sense inside the browser. Keep the first version insultingly small. Assume OAuth and packaging will take longer than your ego wants. Ship anyway.

I just did. The lessons above are free.

If you are solving founder distribution today, start at makers.page.

I Built roastme.gg, a Site Where You Pay to Get Publicly Roasted by AI

Alex Cloudstar — Fri, 21 Aug 2026 18:43:30 +0000

I Built a Site Where You Pay to Get Publicly Roasted by AI

The last time I wrote here, I had just been permanently banned from Reddit and mass-reported off X, and I said the plan going forward was to stop over-investing in rented platforms and build the durable side of my distribution instead. Own domain, email, long-form content, the boring stuff that compounds.

Then I went and built a product whose entire growth mechanic is "make something people want to screenshot and post on X."

That's roastme.gg. You submit your own X handle or website, pick a dollar amount, an AI writes a public roast of you, and it goes up on a wall ranked by how much you paid. Highest payer holds #1 until someone outbids them. I did tell myself I was done chasing rented audiences, and then I built a site that only works if people share it on the rented audiences I said I was stepping back from. I'm aware of the irony. I built it anyway.

This post is two things stitched together, because they happened in the same week and they're actually the same lesson. First, the build and launch, quick version, because you've read enough of those from me. Second, the more interesting part: I used the site as a live test case for everything I wrote about GEO a few months back, and I have real before-and-after data on whether any of it actually moves an AI answer engine.

Where the Idea Came From

I wanted something small. Not a SaaS with a dashboard and a pricing page and a churn problem, just a single, sharp mechanic that's fun to use once and fun to watch other people use. Pay-to-play public roast sites aren't a new category, there's a whole crowded field of them, but the ones I'd seen were either free (so no signal on how much someone actually wants this) or private (so no wall, no ranking, no reason to check back).

The idea was: charge for it, and make the price itself the leaderboard. A dollar gets you a playful jab. A thousand dollars gets you something with no ceiling, and the #1 spot on the wall, until someone pays more to take it from you. That single mechanic does three things at once: it's a real payment flow so it validates whether people will actually pull out a card for a joke, it's inherently shareable because nobody keeps a good public burn to themselves, and it gives me a live leaderboard that updates every time someone pays, which is its own kind of content.

The Build

Nothing exotic here, and that was the point. I wanted this shipped in days, not weeks.

Next.js on Vercel, App Router, server components doing the data fetching.
Stripe Checkout for payment. Five pricing tiers, Mild at $1 to $4 up through Scorched Earth at $1,000 and up, with no cap on the top end.
Claude generates the actual roast, tuned per tier so a Mild roast reads different from a Savage one, not just shorter or longer but genuinely a different register.
Neon Postgres through Drizzle for the roast records, ranked by amount paid.
A Stripe webhook fulfills the roast after payment clears, which is the only place the roast actually gets written, so there's no way to get a free one by poking at the client.

The whole thing took a few days of actual build time. The payment flow, the roast generation, the public wall, the share cards people can download and post. Small, sharp, done.

Tuning the Roast Itself

The tiers weren't just a pricing gimmick I bolted on after the fact, they're the actual product. A dollar and a thousand dollars need to feel like genuinely different experiences, or the whole "pay more, get roasted harder" premise falls apart the first time someone compares a Mild roast to a Savage one and can't tell the difference.

My first pass at the prompt just handed the model a one-line tagline per tier, things like "playful" for Mild and "we stop being nice to you here" for Savage, and let it infer the rest. The roasts came out fine, but they were safer than they should have been across the board. A tagline is a vibe, not an instruction, and a model that's been trained to be broadly agreeable will round every vibe toward the same mild center of gravity unless you tell it explicitly not to.

So I rewrote it. Every tier now gets its own explicit instruction on top of the tagline: Mild gets told to find one real, specific detail and land a clean, clever jab at it, not to hide behind being "cheap" as an excuse to be toothless. Scorched Earth gets told outright that if it reads like a Medium roast in disguise, that's a failure, because someone just paid four figures for it and a generic burn is the one thing that isn't allowed at that price. The instructions also carry consistent guardrails across every tier, no insults tied to physical appearance, race, gender, sexuality, disability, or religion, no real threats, because "paying to get roasted harder" and "actually harmful" are two different products and I only want to ship the first one.

It's a small thing, tuning five paragraphs of prompt instructions, but it's the difference between a novelty that people try once and a product where the price tag actually buys you something different.

Launch

I put it on Product Hunt and posted it on Show HN. Nothing dramatic to report yet on either front, both are still fresh as I write this, and I'm not going to pretend early numbers are a bigger story than they are. What I want to talk about instead is what happened after launch, because that's the part that actually taught me something new.

The Bug That Only Showed Up After Real Users Touched It

One thing worth admitting, because it's the kind of bug that only surfaces once real people are using a real product: the function that turns a submitted target into a URL slug stripped a leading @ for X handles but never stripped https:// for website targets. Submit https://example.com and the slug generator ran the whole string, protocol included, through a "replace anything that isn't a letter or number with a dash" pass. The result was URLs like roastme.gg/roast/https-example-com instead of the clean roastme.gg/roast/example-com you'd expect.

Nobody catches that in testing with a handful of manually typed handles, because you don't think to submit a raw URL with the protocol still attached until an actual visitor does exactly that. One real production roast came in with a URL target before I'd caught it. Fixed the slug function, added a permanent redirect from the one broken URL that was already live so it wouldn't 404 if anyone had already shared it, and moved on. Small bug, but it's a good reminder that the inputs you didn't personally test are exactly the ones a real launch will find for you.

The Real Experiment: Does Any of This Actually Get You Cited by AI

I've written before about SEO for indie hackers and about GEO, the practice of trying to get cited inside ChatGPT, Perplexity, and AI Overviews instead of just ranking in blue links. That post was theory, assembled from research. roastme.gg gave me an actual live subject to run the theory against, on day one, with a domain that had zero prior authority. So I ran the test for real.

Here's the method. I have an OpenAI API key with access to GPT-5's web_search tool, which does a genuine live web lookup, not a training-data guess. I asked it five realistic questions a real person might type, the kind of thing you'd actually search for if you wanted this product and didn't know it existed:

"What's a website where you can pay to get publicly roasted by AI?"
"AI roast my twitter account, is there a site for that?"
"Best AI roast generator websites 2026"
"Site where people pay money to get insulted by AI and posted publicly"
"What is roastme.gg" (the control, since this one only works if the engine already knows the name)

Before I'd touched a single meta tag beyond the basics, the results were exactly what you'd expect for a brand new domain with zero backlinks: roastme.gg showed up for precisely one of the five queries, the one where I asked about it by name. Every generic query returned a handful of competitors instead, most of them sites doing some flavor of the same "pay to roast, post it publicly" mechanic. A few were close enough to my exact positioning that seeing them cited instead of me was a little humbling.

So I looked at what was actually on the page, and the answer was: almost nothing. The homepage had a headline, a one-line subhead, and an interactive submission widget. That's it. No static sentence anywhere on the page explained what the pricing tiers cost, how the wall ranking worked, or what the rules were. All of that lived inside client-side component state that only renders once you start interacting with the form. To a crawler, or to an AI model reading the page to answer a question, that content might as well not exist. You can't extract a fact from a paragraph that isn't there.

What I Actually Fixed

Three things, roughly in order of how load-bearing they turned out to be.

Static content that actually says the thing. I built a dedicated /faq page with a plain-English "how it works" section (submit your handle or site, pick an amount, get roasted publicly) and a real FAQ block: what it costs, how ranking works, what can and can't be roasted, how many roasts are on the wall right now with the actual current numbers pulled live from the database. This sounds almost too simple to be a fix, but the research backs it up: a Princeton and Georgia Tech study found that adding inline citations and specific statistics to a page measurably increases how often AI answer engines cite it, somewhere in the 35 to 40 percent range depending on which change you're measuring. Specific claims and real numbers extract better than vague copy, whether the reader is a human or a model.

Structured data that mirrors the content. I added FAQPage JSON-LD to the FAQ page, a Service schema with an Offer entry for each pricing tier so the actual dollar ranges are machine-readable, and on every individual roast page, CreativeWork and BreadcrumbList schema. Worth being honest about this one: Google killed FAQ rich results back in May, so this isn't going to win you a search snippet on Google anymore. But Bing and Perplexity still parse FAQPage markup to understand Q&A content on a page, and ChatGPT's search backend runs on Bing. Structured data isn't the growth lever people think it is, but it's cheap, it's accurate, and it complements the visible text instead of trying to replace it.

What I deliberately didn't lean on. I already had llms.txt and llms-full.txt wired up, dynamically generated from the live roast data. I kept them, they're basically free to maintain, but I didn't treat them as a real lever, because they aren't one. Multiple independent studies in 2026, one covering over 300,000 domains, found zero measurable citation advantage from having an llms.txt file. As of this year, no major AI company has publicly committed to reading it in production. If you're an indie hacker deciding where to spend an afternoon, spend it on the visible page content instead.

What Moved and What Didn't

I re-ran the same five queries after deploying, twice, a few hours apart. The honest result: the four generic category queries still didn't surface roastme.gg. That part isn't surprising and I didn't expect it to be. ChatGPT's search index, running on Bing, typically takes one to three weeks to pick up genuinely new content, and citation share in a crowded category like this one leans heavily on third-party mentions, other people's sites talking about you, not your own page copy. That's the lever I haven't pulled yet, and it's the harder one because it requires actual outreach, not code.

But the fifth query, the control, told me the crawl itself is already working. Before the fix, asking "what is roastme.gg" pulled a generic answer sourced only from the homepage. After the fix, the same question pulled specific, accurate pricing tier data, quoted almost verbatim, and cited the new /faq page directly as the source, not the homepage. That's the signal that actually matters this early: the content exists now in a form the model can extract facts from, and it's already being read. Whether that content earns citations for queries where I'm not already the answer being searched for is a slower experiment, and I'll report back on it when there's actually something to report.

What I'd Tell Someone Else Shipping a Small, Fun Product

Ship the mechanic, not the platform. roastme.gg is one payment flow, one AI call, one leaderboard query. No accounts, no settings page, no onboarding flow. The entire product is legible in one sentence, and that's on purpose. A complicated product is a complicated launch.

Write the page in sentences before you build the interactive version. I built the submission flow first and the explanatory copy never followed, because the product felt self-explanatory to me, the person who built it. It wasn't self-explanatory to a crawler, and it probably wasn't fully self-explanatory to a first-time visitor either. If you can't describe your pricing and your rules in a few plain paragraphs, your interactive UI is doing work that static text should be doing too.

Test the thing you actually care about, not a proxy for it. I could have looked at Google Search Console impressions and called it a day. Instead I asked the actual questions a customer would ask, into the actual tool a customer would use, and got an honest zero for four out of five queries. That's a less flattering result than a rising impressions graph, and a much more useful one.

Don't let one channel closing convince you distribution is dead. I'm still banned from Reddit. I still don't have my X account back as I write this. Doesn't matter. There's Show HN, there's Product Hunt, there's AI search, there's whatever channel exists in six months that I haven't tried yet. The mechanic that gets people to share your product for free is worth more than any single platform you're locked out of.

Frequently Asked

Is roastme.gg live right now? Yes, at roastme.gg. Submit a handle or a site, pick an amount, and you're on the wall.

How much does it cost? Five tiers, Mild at $1 to $4 up to Scorched Earth at $1,000 and up with no ceiling. Full breakdown is on the FAQ page.

Did the GEO fixes actually work? Too early to call a full win. The crawl is demonstrably reading the new pages and citing them accurately when someone already knows the brand name. Whether it earns citations for cold, generic queries is a slower experiment that depends more on other sites linking to me than on anything I can fix in code alone.

Are you going to keep testing this? Yeah. I'll check back in a few weeks once there's been real time for the index to catch up, and if the numbers move I'll write the follow-up with real before-and-after data instead of a one-day snapshot.

If you want to see the actual product, or you're brave enough to submit your own handle: roastme.gg. Ranked by how much it hurt your wallet.