🔨 Break my new site, then try to stump me — solved live, nothing rehearsed

Discussion & Solutions
, , ,
1

:hammer: Break it, then stump me — a live site, a live session, nothing rehearsed

My new site is live, and I would rather hear what is broken from you than from a paying customer.

Two asks: try to break my site, and send me a problem you have not cracked.

I pick the ones that teach something, and ChatGPT and I work them out live — no script, no rehearsed answer, and no pretending we knew all along.

:lady_beetle: Five things to hunt — the list I would run on your site

every link -> the phone view -> what the server answers -> speed -> what a machine sees
  • Every link — click through the whole site and note each dead one
  • The phone view — open it on a real phone, not a window dragged narrow
  • What the server answers — the redirect chain, the certificate, the page it really lands on
  • Speed — how long the page takes, then what happens when several people arrive at once
  • What a machine sees — missing labels, broken markup, unreadable contrast, keyboard traps

:clipboard: The report I actually want — copy this, fill it in, paste it back

WHAT I DID      opened /tools on my phone
WHAT I EXPECTED the tools to load
WHAT HAPPENED   it answered 404
WHERE           Chrome 154, Android, 4G
SHOT            (drop the screenshot here)

Five lines, and I can fix it in one pass.

:hammer_and_wrench: Fifteen free tools for those five hunts — no signup

The tools, sorted by the five hunts

:gem_stone: rare gem · :green_circle: runs in the browser, nothing to install · every one free

1 · Every dead link on the site.

2 · The phone view, and what moved.

3 · What the server really answers.

4 · Speed, then load.

5 · What a machine catches that eyes miss.

  • :green_circle: A visual accessibility check, no install — WAVE · wave.webaim.org
  • :green_circle: The W3C markup checker, paste a URL and go — Nu Html Checker · validator.w3.org/nu
  • :gem_stone: The accessibility report as one command — pa11y · pa11y.org

:high_voltage: What happens to a problem you send

Picked for what it teaches, then worked through live on 2026-10-17T18:30:00Z — nothing staged, nothing rehearsed.

A session also runs as soon as a handful of good ones land.

:game_die: Sometimes we may not solve the problem during the session at all. That is real technical work.

:open_mailbox_with_raised_flag: Send both things here

The site: bchicbcow.com · the live page: bchicbcow.com/ask-live

For the site half, a broken link and one line is plenty.

Bring the problem in onehack.st/tag/help.

📜 What I promise, and how I put this page online

No scripted answers. No rehearsed solutions. No fake failures. No predetermined outcomes.

We aren’t going to research your question beforehand and then pretend we’re figuring it out in front of you.

When we know the answer, we explain how we know. When we don’t, we investigate. When a first idea is wrong, you watch it fail. When something breaks, you watch it break. When we’re wrong, you watch us correct ourselves.

One of the principles I’m using throughout the project is:

OBSERVE → PROVE → PASS → DOCUMENT → CHANGE → VERIFY AGAIN

Don’t change something because you think you understand the problem. Observe the actual system. Gather evidence. Establish a PASS/FAIL condition. Document what you found. Make one controlled change. Then prove what happened.

I used that process while putting Ask Us Live online. Unexpected HTTP behavior showed up during deployment, each layer was investigated instead of the server being changed at random, and it was not called finished until the public endpoint returned HTTP 200.

Please try to break it. Bring the weird stuff. Bring the thing that should work and simply does not.

4 Likes
2

keep a uniform theme across the website

1 Likes
3

WHAT I DID
Hit the public Ask Us Live URL from an external machine-readable client, using the exact link posted in this thread: https://bchicbcow.com/ask-live

WHAT I EXPECTED
Either the page comes back fine on its own, or it throws a clean permanent/temporary redirect to /ask-live/.

WHAT HAPPENED
The no-trailing-slash URL wasn’t reachable from the external fetcher. Going through the site’s Ask Us menu worked fine, though — it landed on https://bchicbcow.com/ask-live/ and the page loaded normally.

WHERE
External web client/crawler, tested 2026-10-05.

SHOT
Can add one if it’s useful.

Worth noting this may only bite machine clients/crawlers and not normal browsers, so I’m not calling it a confirmed browser bug yet. I’d check what /ask-live returns on its own and make sure it sends a clean 301/308 over to /ask-live/, with the canonical URL kept consistent across the site.

1 Likes
4

Great report — thank you. This is exactly the kind of machine-side check I was hoping somebody would try.

I tested the exact no-trailing-slash URL directly from a Linux client:

curl -sS -o /dev/null -D - https://bchicbcow.com/ask-live

Current production response:

HTTP/1.1 301 Moved Permanently
Server: nginx
Location: https://bchicbcow.com/ask-live/

Then I tested the complete redirect chain:

curl -sS -L -o /dev/null -w ‘FINAL: %{http_code} %{url_effective}\n’ https://bchicbcow.com/ask-live

Result:

FINAL: 200 https://bchicbcow.com/ask-live/

So nginx is currently doing the canonicalization we want:

/ask-live → 301 → /ask-live/ → 200

I haven’t changed the production configuration because the server-side behavior checks out.

That makes your original observation interesting rather than useless: your external fetcher apparently couldn’t follow/reach something that a direct curl client can. If you still have the client/tool name and its actual response/error, I’d love to see it. That could tell us whether we’re looking at crawler behavior, TLS/HTTP differences, bot filtering, IPv4/IPv6, or something else upstream.

Thanks for actually testing the machine-facing side of it instead of just clicking around in a browser. That’s exactly why I posted the challenge.