On this page
In short
- Your website is read by two audiences now: buyers, and the AI systems that answer buyers' questions about you. Both take your claims literally.
- Ours contradicted itself. The problem wasn't the design: decisions moved, and nothing carried them to the page.
- The fix wasn't a redesign. It was governance: one description, honest labels, and a named owner with an approval path.
- No file or format guarantees that an AI will cite you. What you control is whether what it reads is accurate and consistent.
We sell judgement, and the cheapest way to show judgement is to point it at yourself first. So before rebuilding graylemon.io, we read the previous version the way we'd read a client's: slowly, literally, and with the assumption that every sentence would be believed. It didn't survive the reading. This is the teardown, written in the format we use for any product, including the part where we say what we might be wrong about.
01Why tear down our own website?
Because it's the one product every buyer reads before they talk to us, and increasingly the one an AI system reads before it describes us to someone else. A founder asking an assistant "what does Graylemon do?" gets an answer assembled from whatever the assistant can find. The website is the largest thing it can find.
There's a second reason. One of our operating principles is that we work in public and change our minds in public, including when we were wrong. A teardown of someone else's product proves we can see problems. A teardown of our own proves we'll say so when the problem is ours.
A teardown of someone else's product proves you can see. A teardown of your own proves you'll say so.
02How does a buyer read a site, and how does a machine?
We read the old site twice, once as each reader.
The buyer reads fast and forms a view early. They want four answers: what do you do, is it for someone like me, is it true, and what do I do next. They forgive a plain page. They don't forgive a page that contradicts itself, because a contradiction on the website predicts a contradiction in the proposal.
The machine doesn't skim and doesn't forgive. It extracts claims: what the company is, what it sells, to whom, where, and at what stage its products are. It doesn't weigh tone or notice that one section is older than another. When two claims conflict, it has to choose one, and you don't get a say in which. That's the idea behind Machine Legibility, our framework for how AI systems read and describe a company: one description, crawlable content, machine-readable documentation, and genuine mentions elsewhere.
03What did we find?
Eleven problems in all. Here are the ones that mattered most, with what each one told a reader.
| What the site said | What a reader concludes | Kind of problem |
|---|---|---|
| Two demo pieces, made for the website, sat in a list of what our engagements produce | They've delivered work they haven't | Honesty |
| Two ventures were labelled as further along than they were; one hadn't started | The stage labels can't be trusted | Honesty |
| otlo, which has paying customers, was labelled "in validation" | The strongest proof is weaker than it is | Understated proof |
| A ticker advertised a free diagnosis and an offer we had retired | Which offer is real? | Contradiction |
| A price band was published, while our own policy is no prices in public | They don't follow their own rules | Contradiction |
| The last stage of our own framework was named differently from everywhere else | Even their method isn't settled | Inconsistency |
| Audience lists welcomed founders who hadn't built anything, on the page that turned them away | Am I a fit or not? | Contradiction |
Then there was the headline: "We help tech founders, AI enterprises and agencies build creative, strategic, and agentic solutions." Take our name off it and any studio in the world could publish it unchanged. That's the test we apply to everyone else's copy, and our own headline failed it.
We're not naming the ventures whose labels were wrong. They're paused or haven't started, and a venture at that stage doesn't appear on our site at all now. That rule is one of the fixes.
04What does a machine do with contradictions like these?
A person who reads "in validation" next to a ticker for a free diagnosis gets a vague sense that something is off. A machine gets two facts. It can record that the studio offers a free diagnosis, which was no longer true, and that its main venture is still in validation, which understated it. Nothing on the page tells it which sentences are current.
We should be precise about what we're claiming here. We don't know what any particular assistant said about us from those pages, and we're not going to invent it. What we know is what was there to be read, and that a system summarising it faithfully would have repeated our mistakes faithfully.
A machine doesn't read your tone. It reads your claims, and it can't tell which contradiction you meant.
This is why we treat accuracy as a distribution problem, not only an honesty one. A buyer who meets you through an AI answer has already heard your claims before they reach your site. If those claims are wrong, you start the first conversation by correcting them.
05Why did it happen?
Not through bad design. Almost every problem on the list began as a reasonable local decision. Demo pieces made for the website ended up in a list about engagements. Stage labels weren't kept in step with the ventures. A ticker kept advertising offers after they changed. Offers were retired, and nothing retired them from the website.
Put in terms of our own Foundation Matrix, the problem wasn't in the cell where it showed up. It showed up in Creativity × Distribution, the narrative and the assets that travel. It started in Strategy × Judgement: decisions about what we sell and to whom kept changing, and nothing carried each decision to the page.
Insight
A brand without a named owner and an approval path drifts one sensible change at a time. Governance isn't a nicety. It's the part of a brand that stops it contradicting itself.
That's the fifth layer in Brand OS Layers, our framework for what makes a brand hold together as it grows: strategy, verbal, visual, motion, and governance. We had the first four. We didn't have the fifth.
06What did we change?
The rebuild you're reading is the answer, and most of the changes are rules rather than designs.
- One description, used everywhere. Graylemon is an AI-native product and venture studio based in Ahmedabad, India. We pair the name with the city on purpose, because an unrelated company has a similar name.
- Every piece of work is labelled own venture, client or sample, with its stage. Demo work is never shown as engagement work.
- Ventures appear at their true stage. otlo reads "In market, paying customers". apprn reads "Live test with salons". Ventures that are paused or not started don't appear.
- No prices anywhere. The website says "milestone-based" and nothing more, which matches what we actually do.
- A service appears only when published work backs it. If there's no proof yet, the service or capability waits.
- Answers live in the page as text, with structured data that describes only what's visible and true, and a sitemap of every public page.
- The build refuses to publish mistakes. Our site generator stops if a page contains an unfinished placeholder or links to a page that doesn't exist.
The Machine Legibility page walks through this site layer by layer, as its worked example.
07How do you run the same teardown on your own site?
You don't need us for this part. Block out a morning, print the key pages if it helps, and read them literally.
- The find-and-replace test. Remove your name from the headline. If a competitor could publish it unchanged, rewrite it.
- List every claim of fact: stages, clients, numbers, offers, prices, dates. Check each one against today.
- Label every piece of work as your own, a client's, or a sample.
- Search for retired offers in banners, tickers, footers and old landing pages. They hide in the places nobody redesigns.
- Check your policies against your pages. If the policy says one thing and a page says another, the page is what gets read.
- Write one description of who you are and use it word for word on the site, your company profiles and your press kit.
- View the key pages with scripts turned off. Anything that disappears may be invisible to crawlers that don't run them.
- Mark up only what's visible and true. Structured data that claims more than the page shows is a contradiction of its own.
- Ask the main AI assistants the questions a buyer would ask: what you do, who it's for, where you're based. Compare their answers with your description, and note which pages they cite.
- Name an owner and an approval path. Whoever retires an offer also retires it from the site.
For the AI check in step 9, use the questions a buyer would really type, not your brand name alone: what does the company do, who is it for, is it a fit for a specific situation, where is it based, and how does it charge. Ask each assistant the same set, note which of your pages it cites, and repeat it after every significant change. The point isn't to game the answers. It's to find out which of your own pages is doing the describing, and whether it's the one you'd choose.
08What might we be wrong about?
Every teardown we publish ends here, because a diagnosis that can't be wrong isn't a diagnosis.
We may be giving the machine reader too much weight. Google's own guidance says that optimising for AI answers is still ordinary search optimisation: first-hand content and technical clarity, with no special file or format required. We agree with that, and we haven't added any tricks. The case for this work doesn't depend on AI at all. The buyer reading cold was always the first reader, and they were misled first.
We may also be wrong that governance is enough. A named owner stops drift. It doesn't stop a bad decision from being published accurately. That part still takes judgement, and no approval path can supply it.
09Questions teams ask
How do AI assistants decide what to say about a company?
In broad terms, they find pages and other sources about the company, often through a search index, and summarise what they find. Nobody outside those companies controls exactly what they say. What you control is whether the sources they read are accurate, consistent and easy to read.
Do we need an llms.txt file to appear in AI answers?
Google says its search ignores llms.txt, and it isn't a substitute for consistent, crawlable pages. It's harmless to add if another service you care about uses it. It won't fix contradictions on the pages themselves.
What is machine legibility?
It's how easily AI systems can read and accurately describe you. We break it into four layers: one description used everywhere, content a crawler can read without running scripts, machine-readable documentation such as structured data and a sitemap, and genuine mentions on other sites.
How often should we check our own site?
Whenever a decision changes what you sell, who you sell to, or what stage a product is at, and on a fixed rhythm besides. Our own rule is a monthly check of the live site against what we actually offer.
Where this fits