Who this is for
Product managers, founders, operations leads, designers, analysts. Anyone whose job now expects them to show a working demo rather than describe one, and who has been waiting on an engineering team to find the time.
Job postings have started saying it in plain language. A recent Head of Product listing asked candidates to "prototype and iterate using AI-native tools to go from idea to working demo yourself." That expectation is now normal, and almost nobody teaches the skill.
You do not need to know how to code. You will not learn to code either. Three hours does not do that, and anybody promising it is selling something. You will learn to describe what you want, judge whether you got it, and recover when you did not.
What you will build
One small, finished, genuinely useful thing. You bring the idea, or I bring one from your world if you would rather not decide on the day.
It runs in a browser, it lives at a real URL, and you can send that link to a colleague or an interviewer the same afternoon. It is a prototype on purpose: it exists to make a decision cheaper, not to be shipped to customers.
The program
Three hours, with one break. Remote over a video call, or in person around San Diego. Here is the whole thing, minute by minute, so you know exactly what you are buying.
| Time | What happens |
|---|---|
| 0:00 | Setup and framing. Confirm your tools run. What these tools actually are, what they are not, and the one rule for the session: you type everything, including the parts that go wrong. |
| 0:20 | Build the first working version. You describe the user and their situation before you describe any feature, which is the habit that produces better output and happens to be how you should think anyway. Then you send it and watch. Before you accept anything, you read what changed. That single habit is the most transferable thing in the day. |
| 0:45 | Find out what it assumed. It will not ask you a single question, which feels like your description was perfect. It was not. It silently chose a dozen things. You will ask it what it decided, disagree with one, and change it. This is where people stop trusting output on sight. |
| 1:00 | Break. Ten minutes. |
| 1:10 | Change it, four or five times, your ideas. Describe a change, check it, refresh. This loop is the actual skill and everything else is detail. Somewhere in here I will break something without warning you, and you will recover it, because that is what Monday looks like. |
| 1:50 | Put it on the internet. From a file on your laptop to a public URL you can paste into an email. What deploying does and does not mean, and why this version is safe to show people and not safe to run a business on. |
| 2:20 | Where it lies to you. The failure playbook. Real breakages, what they looked like, and the exact wording that recovered each one, including how to check the one number that matters before anybody else sees it. |
| 2:45 | What to do on your own, and how to talk about it. Where to take it next, and how to describe this work to a stakeholder or an interviewer without overclaiming. That last part matters more than people expect. |
For a team session the shape is the same, with everyone building their own thing in parallel rather than one shared project.
What makes this different
You type. All of it.
Most training of this kind is a demonstration. You watch an expert move quickly, feel encouraged, and discover on Monday that you cannot reproduce any of it. Here you drive from the first minute, including the parts where it goes wrong. Especially those.
The failure playbook
These tools are fast, confident, and quietly wrong in ways that survive a casual look. I recently had one build a small timing tool: everything visible worked, it demoed beautifully, and the clock never actually started, so every number derived from it came out as zero.
Nothing in the code looked wrong. You catch that class of problem by knowing to ask, not by reading harder. That is the part of the day that transfers, and it is the part nobody else teaches.
You leave with the materials
A written reference sheet, a library of prompts that actually work, and the failure playbook itself. Yours to keep and to circulate internally.
What it costs
One to one
$600
Three hours, just you
Your idea, your pace, and time to go deeper on the parts you care about. Best if you are preparing for interviews or have a specific thing to build.
Team
$1,800
Three hours, up to 8 people
Private session for one company. Capped at eight, because past that somebody ends up watching, and watching does not work.
Both include the reference materials and two weeks of follow-up by email after the session, for when it goes sideways on your own. It will, and that is when the lesson actually lands.
Remote anywhere, or in person around San Diego. Fixed price, agreed before we start.
What this is not
- Not a coding bootcamp. You will not come out an engineer, and you do not need to be one to get value from these tools.
- Not production software. What you build is a prototype. Treating one as production is a real and expensive mistake, and knowing the difference is part of the day.
- Not me building it for you. If you want something built, that is a different conversation and a different price.
- Not a sales pitch for one tool. The tools will change. The judgment is what you keep.
Questions
- What do I need before we start?
- A laptop and about fifteen minutes of setup, which I will send in advance and help with if it gives you trouble. Most of the tools have a free tier that runs out quickly, so budget roughly $20 for the month if you plan to keep going afterwards.
- Do I need to be technical?
- No. It helps to be comfortable describing what you want precisely, which is a product skill rather than an engineering one.
- Is there an age requirement?
- Yes. The mainstream AI coding tools require users to be 18 or over in their own terms of service, so this is an adult workshop. For a parent and teenager who want to do it together on the parent's account, get in touch and we will work something out.
- Can we do this for a whole department?
- Not in one session. Eight is the ceiling for a single workshop because everyone has to be building. For larger groups, several sessions.
- What if I already use these tools a bit?
- Then skip the setup and tell me what keeps going wrong. The failure playbook is the part experienced users get the most from.
Book it
Email me with whether you want one to one or a team session, rough dates, and what you would like to build. I will reply with a straight answer and a fixed price, no qualifying call required unless you want one.