Questions people ask before reading.
What Ceiling is, who it's for, how to use it, and what it isn't. Short answers, written plainly.
Is this a course?
No. There are no lessons, no exercises, no certificates. Ceiling is a library of teardowns. Each one is a short essay on a specific AI interface pattern and what it does well or badly. If you want a structured course with a syllabus and graded work, this isn't that.
Who is this for?
Mostly designers, PMs, and engineers building AI products who feel they keep having the same arguments without shared vocabulary. People deciding how a composer should behave, how a plan preview should render, when to show a tool call, how to phrase a confidence cue. Heads of design who want a reference shelf to point at in planning. Founder-designers without a senior peer to argue with.
How long will it take?
Each teardown is a short read, around ten minutes. The library is meant to be read across weeks, one or two patterns at a time, with a pause to look at how your own product handles the same thing. If you binge it in an afternoon, you'll forget most of it. That's not specific to this site, it's just how reading works.
Why is it free?
There's no upsell or paid tier hiding behind it. I wanted this to exist and didn't want a paywall in the way. If you find it useful, the best thing you can do is send it to a designer or PM who'd benefit.
How should I use this?
Pick one pattern, read the teardown, then go look at how your product handles the same pattern. Argue with the teardown if you disagree. The point isn't to agree with me, it's to have shared language for the debate inside your team. Reading without applying is fine for context, but the patterns get sharper when you push back on them in your own work.
Is any of this legal, financial, or professional advice?
No. None of it. Everything here is educational. If you're making a decision with real money, contracts, hiring, or compliance attached, talk to a qualified professional who knows your specific situation, like a lawyer, an accountant, or someone who has actually shipped what you're about to ship. Don't substitute reading a chapter on a website for that.
Are you guaranteeing this will work for me?
No. I can't see your product, your team, your model, your users, your timing, or your luck. Every situation is different. Reading this on its own won't change what you ship. Applying it might. There's no promise of better retention, better metrics, a better launch, or any other specific outcome, and you should be careful with anyone who guarantees those things.
What if there's a mistake, or I read something the wrong way?
There almost certainly are. One person, AI is my smart intern, an editing pass that missed things. References age, frameworks shift, examples get edge cases wrong. Treat anything here as a starting point, not a final answer. Pressure-test against your actual work and your actual peers. If you spot something wrong, send it along and I will fix it.
Am I taking on any risk? Should I do my own research?
Yes, and yes. You're using this at your own risk. Whatever you decide based on what you read here, the responsibility for that decision and its outcome is yours. I'm not liable for what happens when you apply this in your product, your team, or your work. Every situation is different, so always run patterns against your real users, your real model, and your real constraints, talk to people who've actually shipped what you're about to ship, and pressure-test before you commit. Be careful. Be mindful. Humans, including me, make mistakes.