**B.U.I.L.D.** could become the practical framework attendees take home: - **B — Begin with a real problem.** Pick one small frustration you understand. - **U — Use your own words.** Tell your coding AI who needs the tool, what they do, and what a good result looks like. - **I — Iterate with confidence.** Try it, notice what feels wrong, and ask for specific changes. - **L — Launch a useful first version.** Put it somewhere people can open and try. - **D — Develop it with others.** Gather feedback, improve it, and inspire someone else to build. That follows your intended progression: **try something yourself, make it useful, then bring others along.** It also gives the live demo a clear storyline—you can explicitly move through each letter as the app takes shape. Q2: **Would you prefer the live build to solve a problem you choose beforehand, or let attendees choose from two or three small school problems you’ve prepared?**

That gives us a good structure: **invite their problems first, offer three prepared choices if needed, and keep one rehearsed build in reserve.** For the live suggestions, we can use a quick filter: one clear user, one main task, and a useful result we can demonstrate within 20–25 minutes. Ideas needing school credentials, complex integrations or sensitive records can become follow-up projects. Three possible prepared choices: - **School Event Checklist:** enter an event and date; create, assign and track preparation tasks. - **Resource Finder:** turn a scattered collection of useful links into a searchable, categorised school resource hub. - **Duty Swap Board:** post a duty needing cover, offer a swap, and show its status using fictional staff. I’d rehearse **School Event Checklist** as the back-pocket build. It’s familiar across educator roles, visually satisfying, and easy for attendees to improve with suggestions. Q3: **Will attendees build alongside you on their laptops, or mainly watch and contribute ideas while you build?**

Then we’ll make it a **participatory demonstration**: you operate the coding AI, while attendees help define the problem, suggest requirements and test the result. They still practise the thinking behind BUILD. At three points, you can invite input: - **Before building:** “Who is this for, and what should it help them do?” - **After the first version:** “Try this scenario—what’s missing or confusing?” - **Before launch:** “Is this useful enough for someone to try?” They leave with a small starter prompt and the BUILD framework to try independently afterward. Q4: **Which coding AI will you use for the live build—Codex, Claude Code, or another tool?**

Claude Code can carry the live build, with Codex appearing briefly in your app showcase to demonstrate that BUILD works across tools. I’d keep the live demonstration in one tool so attendees can follow the conversation from idea to launch. Showing the same prompt in both tools could be an optional extra if time allows. Q5: **How much of the setup do you want to show—starting from an empty project with accounts already signed in, or also explaining account creation, installation and Cloudflare connection?**

Yes—survey them early, but use the result to **adjust your explanations and examples**. Keep Claude Code as the rehearsed default, with Codex available if the audience strongly favours it and you’re equally comfortable demonstrating there. Ask: **“What have you used to build something?”** - Claude Code - Codex - Another AI builder - ChatGPT or Claude for chat only - Haven’t tried yet That last distinction matters: using an AI chatbot doesn’t necessarily mean they’ve used a coding agent. If most are beginners, your prepared demonstration will help more than following a tool majority. **Would you feel equally confident doing the entire live build and deployment in either Claude Code or Codex?**

That’s a useful personal preference to share: **“I’m comfortable with both. I particularly like how Claude Code presents clarifying questions—it helps me make decisions as we build.”** You can connect that to **U — Use your own words**: attendees don’t need a perfect specification upfront. The AI’s questions can help them work out what they mean, while they remain responsible for the decisions. We’ll keep both tools available and let the opening survey influence your choice. Q5: **Should the live demo begin with an empty project and accounts already connected, or include the account and deployment setup too?**

Yes. **Start from an empty project, with the infrastructure ready.** That preserves the “from zero” experience while keeping account setup from consuming the demonstration. Your live starting sequence can be: 1. Create a new folder on your local drive. 2. Open it in the chosen coding AI. 3. Describe the audience’s selected problem. 4. Confirm the existing Cloudflare connection. 5. Build, refine and deploy to a prepared demo address. We’ll explicitly explain that Cloudflare provides the place where the app runs and becomes accessible through a link. Account setup and authorising the coding tool take preparation; AI can guide that process. The eventual presentation will have a separate **“Prepare your own build”** branch with pages for accounts, local tools and folders, Cloudflare authorisation, and first deployment. You can briefly visit it during the talk, and attendees can follow it afterward. Q6: **For the live app, is a working prototype with fictional data enough, or do you want to demonstrate saving data so it remains there after refreshing or reopening the app?**

Good—fictional demo data will make the prototype feel useful immediately and give attendees scenarios to test. We’ll build that into the live prompt. One distinction to keep open: demo data can still be saved between visits. We can choose whether to demonstrate that once the app idea is selected. Q7: **Which apps from your August–September builds are must-show examples, beyond THE NEST and the visitor request workflow already named in your session description?**

I’d use **one approachable public tool, one richer public example, and THE NEST as the staff-only centrepiece**. The [KEYSTONE gallery](https://keystone.wasbkk.workers.dev/) becomes their take-home directory rather than a tour of all 16 apps. | Example | Why I’d show it | Time | |---|---|---:| | **[Signature Studio](https://wasbkk-email-sig-gen.ateneo.workers.dev/)** | A small, recognisable problem with an immediate visual result: enter details, preview, download. It makes “I could build something useful” feel achievable. | 2 min | | **[GCSE Options Hub](https://gcse-hub.wasbkk.workers.dev/)** | Directly relevant to educators: subject introductions, resources, search and a personal shortlist. Shows how scattered material can become a coherent experience. | 3 min | | **THE NEST — staff-only** | Your strongest sustained example: show the interactive calendar, then how a Builder controls published content. This demonstrates the step from a useful page to a working school system. | 5 min | **Support Desk would be my optional fourth example**, shown briefly if the audience leans toward school operations. Its multi-department workflow illustrates how an app can grow through iteration, but explaining it could eat into the live build. Keep the visitor workflow as a short before-and-after story, since it’s named in your session description. For attendees exploring public apps, I’d direct them to browsing the GCSE hub; Signature Studio is open to view but explicitly intended for WASBKK signatures. For staff-only demonstrations, prepare fictional records or selected screens. One detail to verify before framing the showcase: **the GCSE hub contains May event dates, so we should establish which apps were first built in August and which were developed further during August–September.** Q8: **Do Signature Studio → GCSE Hub → THE NEST feel like the right progression, or would you rather replace the GCSE example with Support Desk?**

Then let’s include them—they give the showcase a strong pupil-focused thread. I’d group the apps into **three stories**, rather than demonstrate each separately: - **Small tools, immediate usefulness:** Signature Studio or GCSE Options Hub as a quick public example attendees can explore. - **A better start for each pupil:** Admissions Herald, Pupil 360° and Pupil View together. Explain the distinct problem each solves, then show one memorable interaction from each. - **A shared home for staff:** THE NEST, with its calendar and Builder controls. That could fit into **10–12 minutes**, leaving the live BUILD demonstration as the main event. Support Desk can stay in reserve. Q8: **In your words, what distinguishes Herald, Pupil 360° and Pupil View—and which feature in each makes you most proud?**

That gives us a strong shared theme: **make existing school information easier to use.** - **Pupil View:** “The current pupil data is in iSAMS. I wanted a simpler way for colleagues to reach it.” - **Admissions Herald:** “A new pupil is joining. How do we make announcing their arrival easier?” - **Pupil 360°:** “The admissions information is in OpenApply. How do we share it in a clear, simple view?” These are compelling BUILD examples because the starting point is your understanding of school work. You recognised the friction and could describe what would help. I’d show the three together, then position **THE NEST as the shared staff home**, with one brief public example attendees can explore afterward. Q9: **For these pupil apps, do you already have fictional demo records available, or would we need to prepare a demonstration version before the conference?**

We’ll put **demo data preparation** on the conference checklist. A useful approach would be one fictional new pupil appearing across all three apps: - **Pupil 360°:** share their admissions information from OpenApply. - **Admissions Herald:** announce their arrival to colleagues. - **Pupil View:** make their current pupil information easy to access in iSAMS. That gives your showcase a connected story. We’ll first confirm how each app can display fictional records safely; it doesn’t require an automated connection between them. Q10: **What’s the conference date, and do you know whether you’ll have reliable internet and a screen readable enough to show the coding AI’s conversation?**

Great—**10 October 2026**, with internet and a suitable screen. That gives us time to prepare the fictional pupil story and rehearse the live build. We’ll still keep screenshots or a short recording of the showcase and rehearsed build available, so a slow deployment doesn’t interrupt the session. Q11: **How much should attendees see of the AI’s work—mainly your prompts and the resulting app, or also the generated code, terminal commands and errors as they happen?**

Then the demonstration should follow a visible rhythm: **your request → the AI’s questions → the app → your feedback → an improved app.** You narrate the decisions: “That’s what I meant,” “This needs changing,” and “Let’s check it with our example.” Code and terminal activity can stay in the background, with a brief explanation when deployment happens. That makes **BUILD** the main lesson, while the tools support it. Q12: **What would count as success for the live build—a deployed app that performs one useful task well, or a more polished prototype with several features?**

Then **a working link is the finish line**. The live build succeeds when an attendee can open the deployed app and use it for one clear task. We’ll aim for a small first version, deploy it early, then improve it with audience feedback if time remains. That makes **L — Launch** a visible moment in BUILD. Q13: **Would you be comfortable deploying a deliberately simple first version after about 10–15 minutes, then spending the remaining demo time refining it?**

Good. We’ll structure the live build as: - **First 10–15 minutes:** define one useful task, build it with fictional data, and deploy. - **Next 10 minutes:** let attendees open it, suggest a change, and watch you refine it. - **Final moment:** revisit the working link and connect what happened to BUILD. That shows both the speed of a first version and the judgment involved in improving it. Q14: **What’s one misconception or hesitation you most want this session to change—“I can’t code,” “AI-built apps aren’t useful,” “deployment is too technical,” or something else?**

That’s the opening story: **“I didn’t begin knowing these platforms. I began with a real problem, researched what I needed, and experimented.”** It directly answers the three hesitations: - **“It’s too technical.”** You learn the next necessary step while working toward something useful. - **“It’s for geeks.”** Knowing how your school works gives you a valuable starting point. - **“I don’t know where to begin.”** Begin with one frustration you can describe clearly. We should make that journey visible, including a moment when you were unsure or the first attempt wasn’t right. That will help attendees see themselves in the process. Q15: **What was the first real problem that prompted you to start building—and what did you try first?**

That makes **the GCSE site your opening example**. It connects directly to an educator’s familiar task: > “I was asked to make a presentation from subject videos and course information. I thought: could this work better as a website? I started experimenting, discovered Cloudflare, and initially handled the publishing steps manually—even with AI helping. Then I asked the AI: can I connect you to Cloudflare so you can publish directly?” That last question is a memorable turning point. You didn’t need to know the whole process beforehand; you recognised a repetitive step and asked whether there was an easier way. The session can follow that same journey: **a familiar request → a different possibility → experimentation → a deployed tool**. Later, the pupil apps and THE NEST show where that first experiment led. Q16: **Which AI were you using for that first GCSE build, and roughly when did it happen?**

Then your story starts **around March 2026 with ChatGPT and the GCSE website**, followed by the concentrated August–September period when you built out the wider app collection. That’s a stronger narrative: one experiment opened a door, and your confidence grew through solving more school problems. We’ll distinguish that early beginning from the recent showcase period. Q17: **What changed between March and August that helped you move from one website to building so many apps—your tools, your confidence, the problems coming your way, or a combination?**

Your journey gives the session a natural progression—**each real request introduced the next thing you needed to learn**: | When | Project | What you learned | |---|---|---| | Around March | **GCSE website** | Turn videos and course information into a website; discover Cloudflare and direct publishing with AI. | | May–June | **Family Pass** | Move beyond displaying information to accepting photo submissions and storing files and records with R2 and D1. | | Started earlier, completed August | **Visitor app** | Handle email, QR scanning, permission routing and Microsoft 365 sign-in through Entra. | | August–ongoing | **THE NEST** | Build a growing staff portal with a CMS/admin workspace so colleagues can manage content. | The message becomes: **“I didn’t learn an entire technology stack and then find something to build. A school problem gave me a reason to learn the next piece.”** The CMS deserves a clear moment in the demonstration: *the public-facing app is what people use; the admin side is how authorised people keep it useful.* We can encourage attendees to ask their AI, “What will someone need to update, and can they do that through an admin screen?” A small app may only need a simple editor. For authentication, you can explain your Microsoft experience and acknowledge that you haven’t tried Google setup. Q18: **For the live build, should we aim to demonstrate a small admin/editor screen too, provided the first version is already deployed?**

The new-school context gives your story a clear purpose: **setup began in January 2026, and Wycombe Abbey International School Bangkok opened on 24 August.** You were discovering needs while helping establish how the school would work. You could say: > “As we prepared to open a new school, real problems kept arriving. Each one gave me a reason to experiment—and learn the next piece.” For the live build, we’ll keep a **small admin screen as an extension after deployment**. Ideally, it changes something attendees can immediately see: edit an item, update a category, or adjust the app’s appearance. Every control should actually work. Statistics could be another option if the chosen problem makes them useful. Q19: **What’s one memorable time the AI misunderstood your request—and how did you explain it differently to get the result you wanted?**

That’s a useful part of **I — Iterate with confidence**: when the result is wrong, you clarify the intent and try again. A wrong layout—or even the wrong data structure—is a moment to inspect and correct. Your use of a separate AI adds a practical technique: > “Sometimes I use Gemini or another AI to organise my thoughts before taking the request back to my coding AI. I ask it to make the instructions clearer, then check that it still says what I mean.” We can give attendees a reusable prompt: > “Help me organise this app idea into clear instructions. Identify the users, their main tasks, the information needed, and what success looks like. Flag ambiguities and ask me questions. Don’t add features I haven’t requested.” Q20: **When the app looks right, how do you decide it actually works—do you test realistic scenarios yourself, involve colleagues, ask the AI to check it, or combine those approaches?**

Your **80 → 90 → 99** description could be one of the session’s most memorable ideas—as your experience of the process, rather than a measured completion scale: - **First 80%:** the idea becomes a working app surprisingly quickly. - **Next 10%:** bigger corrections and changes take longer. - **Last 9%:** repeated refinements improve how it feels and works. - **100%:** there’s always another useful improvement; you don’t treat the app as permanently finished. Your finish line is practical: **users are happy, the functions work, and the app serves its purpose.** That also gives **D — Develop it with others** substance. At around 80–85%, you involve colleagues, observe how they use it, gather feedback, return to the coding AI, and test again. The live demo can mirror that loop once attendees open the first deployed version. Q21: **When you ask the AI to review an app, which parameters do you normally give it—for example ease of use, layout, permissions, reliability or maintainability?**

That gives attendees a review prompt they can reuse: > “Review this app against its purpose, the context where it will be used, and its intended users. Check ease of use, layout, permissions, reliability and maintainability. Explain the most useful improvements, prioritise them, and ask before implementing changes.” Your central question is **“Does this work well for these people, doing this task, in this setting?”** Colleague testing supplies the real experience; the AI review adds another perspective. Q22: **Would you like attendees to leave with a take-home section on the presentation website containing BUILD, starter prompts, setup guidance and a first-project checklist?**

We’ll make **“Build your first app”** a substantial companion section on the eventual presentation website, designed for attendees to use afterward. It will include: - **Start here:** choose a manageable school problem, with three example projects. - **BUILD framework:** practical steps, questions and examples for each letter. - **Prepare your tools:** coding AI, local project folder, Cloudflare account, authorisation and first deployment. - **Prompt library:** describe an idea, clarify requirements, correct misunderstandings, request an admin screen, and review an app. - **Test and improve:** fictional data, realistic scenarios, colleague feedback, permissions and checks before real use. - **Troubleshooting:** what to do when the layout is wrong, the data structure doesn’t fit, or deployment fails. - **Keep it useful:** content editing, maintenance, backups and handing the app over to others. - **Your examples:** the story behind each showcased app and links attendees can explore. We’ll distinguish your demonstrated Microsoft sign-in experience from Google setup, which you haven’t tried. Q23: **Should this companion section assume attendees have never used a terminal or coding tool, with an optional deeper path for those who already have?**

We have enough now—**no more questions are needed to establish the plan.** I let the Q&A run too long. The companion section will assume **no terminal or coding-tool experience**, start with a very simple project using fictional data, and explain each step in plain language. More advanced guidance will be optional. We’ve established the session’s story, BUILD framework, showcase, live deployment goal and robust take-home guide. Nothing will be built until you ask me to start.