Judge Any Build

You've done it once. Now you know what to ask.

A week ago, "we built it with AI and it's nearly done" was hard to evaluate. Now you've seen how fast the first 80% goes and where it lies to you. These questions come straight from what you just did. They work on a team, a founder or a vendor, and none of them needs you to read code. If you were forwarded this page, you can use them today. They land harder once you've built something yourself.

10 Questions for Any AI-Built Project

Can you show me it running on your laptop right now? A good answer takes under a minute. Slides and screenshots are a bad sign. From Chapter 1
What did it ask permission for, and what did you approve? They should remember. "I approve everything" or "I turned that off" means nobody was watching. From Chapter 1
Show me the spec. What did you decide not to build? A short document with a clear out-of-scope list. No spec usually means the demo is the spec. From Chapter 2
Is there a CLAUDE.md, or something like it? Can I read it? You should be able to follow it. It tells you what they think matters, and what they've already been burned by. From Chapter 3
Run the checks in front of me. What happens with an empty file? They run on command, and bad input produces a clear message instead of a blank page or a wrong number. From Chapter 4
Has a test ever been deleted or weakened to make it pass? "Yes, and here's how we caught it" is a better answer than a quick "never". From Chapter 4
Who reviewed this, other than whoever built it? A person or a fresh session, with notes you can see. The builder's own "looks good" doesn't count. From Chapter 4
Where are the keys stored, and who can see them? Not in the code and not in a chat. They can tell you what happens if one leaks. From Chapter 5
Whose data is in it, who can see it, and which AI provider has seen it, under what terms? A specific answer, including the plan they're on. "It's all secure" isn't an answer. From Chapter 5
What breaks if 1,000 people use it, and who gets called when it does? A name, and an honest guess at the weak spot. "Claude will fix it" isn't a name. From Chapter 5

10 QUESTIONS FOR ANY AI-BUILT PROJECT

1. Can you show me it running on your laptop right now?
   A good answer takes under a minute. Slides and screenshots are a bad sign.

2. What did it ask permission for, and what did you approve?
   They should remember. "I approve everything" or "I turned that off" means nobody was watching.

3. Show me the spec. What did you decide not to build?
   A short document with a clear out-of-scope list. No spec usually means the demo is the spec.

4. Is there a CLAUDE.md, or something like it? Can I read it?
   You should be able to follow it. It tells you what they think matters, and what they've already been burned by.

5. Run the checks in front of me. What happens with an empty file?
   They run on command, and bad input produces a clear message instead of a blank page or a wrong number.

6. Has a test ever been deleted or weakened to make it pass?
   "Yes, and here's how we caught it" is a better answer than a quick "never".

7. Who reviewed this, other than whoever built it?
   A person or a fresh session, with notes you can see. The builder's own "looks good" doesn't count.

8. Where are the keys stored, and who can see them?
   Not in the code and not in a chat. They can tell you what happens if one leaks.

9. Whose data is in it, who can see it, and which AI provider has seen it, under what terms?
   A specific answer, including the plan they're on. "It's all secure" isn't an answer.

10. What breaks if 1,000 people use it, and who gets called when it does?
   A name, and an honest guess at the weak spot. "Claude will fix it" isn't a name.

Where to Go From Here

You’ve used a fraction of what’s there. Skills are saved instructions Claude can reuse, so a job you’ve explained once stays explained. Connectors link Claude to tools like your email or calendar. Scheduled tasks run on their own. None of this is only for code, either. I run Nexrizen on the same ideas you just used, with what we know written into files Claude reads, an approach I call a company brain. For a full reference, see the Claude Code cheat sheet. It’s written for developers, so go there when you want the details.

🏛 civilize.exe — Technology Advisor

_ □ ×

0 of 18 advances discovered

Beginner: done in this guide

First Build: A working page from one request, in a folder you control.
Undo: Rewind, or ask in plain English. Nothing is permanent.
Spec: Who it's for, what done means, what's out of scope.
CLAUDE.md: The briefing Claude reads at the start of every session.
Checks: Numbers you worked out separately, green or red.
Live URL: Only what you meant to publish, on a site you claimed.

Builder: your next few weeks

Second Project: Your own idea this time, with no prompts from me. It goes slower than you expect and teaches more.
Skills: Saved instructions. Explain a job once and reuse it by name.
Connectors: Link Claude to your calendar, email or docs. Read Chapter 5 again first.
Schedules: A job that runs on its own every morning. Start with something harmless.
Code Review: Type /code-review and read what it finds. Ask for anything confusing in plain English.
Engineer Check: Show someone good what you built. Ask what they'd worry about.

Operator: Claude across your work

Beyond Code: Notes, proposals and weekly updates. Most of what a company does is documents.
One Real Job: Pick one recurring job, and make it good before you add another.
A Teammate: Sit with one person through their first session. You'll learn what you skipped.
Shared Rules: A CLAUDE.md that a whole team reads, reviewed when it changes.
Company Brain: How your company works, written where Claude can read it.
Judge Builds: Use the 10 questions on a real project. Notice who gets uncomfortable.

Rather have it done for your company? I set up Claude for a team in 14 days, and the setup page explains how. The smallest way to start is Proposal by Morning, one job set up in 7 days.