You point your AI assistant at a URL, ask for a website teardown, and walk away. It comes back with a review of your marketing homepage: who it is for, what it claims, whether it proves it. Useful, except what you actually wanted was to know whether a new user can finish signup. That answer is not in a teardown, because a teardown never logs in. You just spent a turn getting the wrong study.
The split is simple once you see it. Public pages that anyone can read without an account get a website teardown or a pricing teardown. A product behind a login, where the thing you care about is whether a real person can do a task, gets a usability pass. Here are the mistakes that keep people on the wrong side of that line, and the fix for each.
Asking for a website teardown when the problem is behind a login
The website teardown, also called a positioning audit, renders public pages and judges what a cold visitor sees. Cobalt renders those pages itself, so the study runs start to finish from Claude chat with no browser and nothing for you to do. That is exactly why it cannot test a signed-in product: it never signs in.
So when you ask "run a website teardown of myapp.com" but the question in your head is "can someone actually complete onboarding," the study answers a different question than the one you asked. You get a positioning read on the front door, not a usability read on the rooms behind it.
The correction: if the task you care about requires an account, ask for AI usability testing instead. The usability pass has the AI play a first-time user on a product you own or may test. It signs up with a temporary test inbox, tries real tasks, and screenshots every point of friction. That needs an assistant that can drive a browser, which is the whole difference.
Expecting a public-page study to click buttons and submit forms
It is tempting to think any study can "just try it." The public-page studies (pricing teardown, website teardown, comparison) are built to read, not to act. They look at a rendered page and judge it. They do not fill a field, submit a form, or follow a flow across screens.
If you want the AI to walk a named flow step by step, including the emails it sends, that is a flow walkthrough, and it needs a browser too. A website teardown asked to "check that the signup works" will describe the signup page it can see and stop there, because clicking Submit is not what it does.
The correction: match the verb to the study. Reading a page means a public-page study. Doing a task means a browser-driving study (usability pass or flow walkthrough). If your sentence contains "sign up," "complete," "invite," or "check out," you want the browser.
Running a usability pass on a page a teardown would have nailed
The mistake runs the other way too. You ask for a full usability pass on your pricing page when all you needed was: can a buyer tell what they would pay and which plan is theirs. A pricing page teardown answers that directly. It works out the cost for a solo user, a team of 5, and a company of 25, checks the fine print, and checks the phone view. All from public pages, no browser, no stopping point.
Spinning up a browser-driving study for a public page you could have read is slower and heavier than the job needs. The usability pass also stops once for your go before it starts, so it is not a fire-and-forget study the way the pricing teardown is.
The correction: if the answer lives on a page a logged-out visitor can see, use the public-page study. Save the usability pass for what is actually gated.
Forgetting the usability pass needs your permission and a browser
People ask for a usability pass and expect it to behave like a pricing teardown: fire it and walk away. It does not. The usability pass signs up for your product, so it stops once for your go before it starts, and it needs an AI that can drive a browser. If you are running it from plain Claude chat with no browser, it cannot proceed.
The correction: run it where the browser is. Cobalt works in Cursor, Codex, and any assistant with a browser and MCP support. Connecting your coding agent over MCP is the setup step, and /workflows lists every study and exactly what to say. If you want a sense of what the pass catches versus a plain read, the difference between an AI usability test and a chat review spells it out.
Treating the two studies as interchangeable reports
They are not the same artifact. A website teardown tells you how your positioning reads to a stranger. A usability pass tells you where a real user got stuck. Sending the positioning review to an engineer who asked "why is drop-off high at step 2" wastes both your turns.
Both come back in the same review format: real screenshots of each thing it judged, findings ranked by what they cost, and the verdict at the top. You can share either as a review link, and you can re-run a study later to get a review that leads with what got fixed. The format is shared. The question each answers is not.
Both the manual capture flow and the AI studies are free to try with no password and no credit card. A review stays editable for 7 days, then goes read-only for you while the shared link keeps working for everyone you sent it to. Pro is $5 a month and keeps every review editable with no cutoff.
Before you type the request, name the task. If it needs an account, point an assistant that can drive a browser at it and ask for a usability pass. If it lives on a public page, let Claude chat read it. One sentence of clarity saves you a turn.