Open Gemini
On the laptop you've brought, signed in on the account you actually use for work.
WorkshopGemini Canvas · 90 minutes · 27 July 2026
Today we're not writing text, we're building software. You'll leave having built a working app that pulls live data off the internet, and having seen the real trick: handing that data to a model and asking it to think about it.
No coding experience necessary
“The hottest new programming language is English”
Andrej Karpathy · January 2023
What this is
By the end of this you will have built something that works, without writing a line of code.
What we're using
Canvas, which is already part of Gemini in Workspace. Nothing to install, nothing to sign up for, no budget to ask anyone for. If you can open Gemini, you already have it.
What it gives you
Not an answer in a chat window but a working app: something you can open, use, change your mind about, and send to a colleague when it's doing what you wanted.
What it isn't
A developer's tool. Things like Claude Code go a great deal further and expect more of you. Canvas is narrower on purpose, and it's already set up, which is exactly why it's the one to start with.
Reading this on your own, rather than in a room with someone talking over it? Good. It was built to work that way. Go through in order, do the bits that say your turn, and click any prompt to copy it. Everything you need to paste is on the slides.
Before we start · Two minutes
Have a go at these now. If any of them doesn't work, put your hand up and we'll sort it out while I'm talking.
On the laptop you've brought, signed in on the account you actually use for work.
Click the + button, then More tools, then Canvas. A Canvas chip appears by the prompt box when it's on.
"Make me a button that says hello." If something appears, you're set for the next 90 minutes.
The session
The middle block is the point. Everything before it exists to get you ready to build for half an hour.
How to work today
None of these are about code. All of them are about not getting stuck.
Click any prompt card and it's on your clipboard, ready to paste. You'll see Copied appear in the corner. Nothing today needs retyping. The slides live here, and they're yours to keep.
Every time you ask for something, the model re-reads your entire conversation. A chat that has wandered through three different projects drags all of that into the fourth. Start a fresh one for each distinct thing you build.
Gemini is good at explaining and researching, not just building. Open a new chat with Canvas switched off and ask it anything: what an API does, why something broke, what you might try next.
Sometimes the preview window simply won't load. That's the tool having a moment, not your prompt being wrong. Start a new chat and build it again rather than trying to nurse it back.
It is faintly miraculous that you can build software with a probabilistic model at all, and it won't always work. If a project has drifted or gone down a dead end, don't argue it back. Start again. You'll get there faster.
Open Gemini, switch Canvas on under More tools, and let's build a working tool right now. No external data, no setup. The code does all the work itself.
Part 1 · Building live
Standalone means it needs nothing from the outside world: no data, no setup, nothing but the code it writes. And the prompt is one sentence, deliberately vague. Watch what it decides for itself.
Paste this into Canvas
Create an app that calculates the cost of a meeting.
Now actually use it. Put real numbers in. What did it assume without asking you? What's missing, and what's simply wrong? Hold on to that, because the next slide is about saying so.
Part 1 · Iteration
You don't edit the code, you say what you want instead. Pick whichever of these your version needs, or invent your own. Click any of them to copy it.
Make it live
"Make the total tick up live while the meeting runs, with Start, Pause and Reset buttons."
Make it look better
"Make this a dark-mode dashboard with one big headline number."
Make it honest
"Assume an 1,800-hour working year, and show me the assumption on screen."
Make it easier
"Let me pick a salary band from a dropdown instead of typing a number."
Make it sting
"Underneath, tell me what else that money could have bought."
Make it useful
"Add a button that copies a one-line summary I can paste into an email."
Ask for one thing at a time. If you stack five changes into a sentence you'll get four of them and no idea which one it dropped.
Part 1 · No data needed
If you're looking for something more interesting than a meeting cost calculator, here are ten more ideas for standalone apps. None of these need anything from the internet, and each one is a single sentence away. Click any of them to copy it.
The tools we just built work perfectly, but they live in a bubble. They only know what we coded in, or what the user types.
Part 2 · Where the facts come from
An app built on what the model already knows might be perfectly fine. You can't be sure, and neither can it: those facts came out of training data of uncertain vintage. Two things worth doing before you build.
Open a separate chat and ask where the reliable version of this actually lives. Then either collate what you find and hand it over, or point your app at the page itself. Ask for an app on entry requirements for visitors to the UK and you'll get one, built from whatever the model absorbed in training. Ask it first for the official gov.uk page and you have something checkable.
"Which official UK government page sets out entry requirements for visitors, and what's the URL? Don't summarise it, just tell me where it lives."
Often the reliable version is already yours: a spreadsheet, a PDF, a report somebody sent you. Upload it and have the app work from that rather than from the model's memory. You know exactly where that data came from, which is the whole point.
"Here's our team's on-call rota as a spreadsheet. Build me something that shows who's on this week and who's next."
Both still need checking. A source you chose is far easier to verify than one you didn't, but neither approach makes the output true. Whatever you build, spot-check it against the original before you trust a number that comes out of it.
What an API is
“A tap you can plumb directly into your app. You send a request, and structured data comes back.
Application Programming Interface. Nobody has ever needed the full name.
Part 2 · The language of APIs
The question
https://geocoding-api.open-meteo.com/v1/search?name=Tokyo&count=1
"Is there a place called Tokyo, and if so, where exactly is it?"
The answer
{ "results": [ {
"name": "Tokyo",
"country": "Japan",
"country_code": "JP",
"population": 9733276,
"timezone": "Asia/Tokyo",
"latitude": 35.6895,
"longitude": 139.69171
} ] }
What you're looking at
Nobody is meant to read the answer. It's ugly for us and trivial for an app, which is the whole point. Every project this afternoon starts by asking a question like this one and seeing what comes back.
Part 2 · Before you plug anything in
Everything in today's list is free and keyless: no sign-up, no password, safe to use straight away. Out in the wild, some APIs ask for more. Three things to know.
A key is a password an API gives you when you register with it. They exist mostly so nobody can abuse or overload the service, and so usage can be traced back to whoever signed up. That person is you. Share it and someone else can run up your bill, or get you cut off.
Never
Give your key to Gemini, or let it write the key into the code. Anyone who opens the app can pull it back out.
Instead
Ask Gemini to have the app request the key from whoever is using it, so it's typed in fresh and never stored.
Free endpoints cap how many requests they'll answer, so thirty people hammering the same one can trip a shared limit. Spreading out across different APIs keeps everyone's apps working. Some APIs won't talk to a browser at all. If you're not sure what one will and won't do, ask Gemini to explain the API's limits and what you can build with it before you start.
The share link you'll generate at the end is readable by anyone who has it. Perfect for a weather app. Never for anything carrying internal or sensitive data they don't already have access to. We'll come back to this before you share.
Watch the whole arc once, slowly, before you try it yourself. Three beats: the base build, a second source, and the handoff.
Part 3 · Beat 1 · The base build
Exactly the same move as the meeting calculator: say what you want, in plain English. The only new ingredient is naming a source of live data. There is no code in this prompt and no jargon, just a description of what the app should do.
The base build
I want to use the Open-Meteo geocoding API to build an app where I type a place name and it shows the country, population, timezone and coordinates along with the country's flag. Tell the user when the app is loading and if there's an error.
"the Open-Meteo geocoding API"
Naming a real source is what forces it to go and fetch. Leave this out and it will happily build the same app from numbers it half-remembers, and you'd struggle to tell the difference by looking.
"Tell the user when the app is loading and if there's an error."
Fetching isn't instant, and sometimes it fails. One sentence buys you the difference between a blank screen you can't read and an app that says whether it's working, waiting, or broken.
Part 3 · Beat 2 · Add a second source
Almost every genuinely useful app pulls from more than one place. Ours already knows the facts about a location. Something else can tell it what the place is actually like. Joining the two together costs one more sentence.
What we now have
Type a place name and the app comes back with the country, its flag, the population, the timezone and the coordinates. All of it fetched live, none of it typed in by us. It works. It's also a little dry.
Making it richer
Wikipedia has an API too, and it's one of the most useful on the internet. Give it the name of almost anything and it returns a photograph and a plain-English paragraph. Nothing you could ever calculate, and free to use.
Say exactly this
Now let's add more detail. After the place loads, use the Wikipedia API to get the photo and the first paragraph about the place and show it underneath the card.
Part 3 · Now try to break it
Play with it. Think about what would trip you up, and ask it exactly that. Not every problem announces itself with an error message: some just quietly hand you the wrong answer.
Does it match what you know?
Start here. Search somewhere you know intimately, your home town or wherever you grew up. You'll spot a wrong population or the wrong county straight away, and you would never catch the same mistake in a city you've only read about.
Which one did you mean?
Plenty of place names turn up more than once, in different countries. Newcastle is the obvious one. How does your app deal with that? It may offer you the choice. If it doesn't, it has picked one for you without mentioning it.
Do the data sources relate?
You're pulling from two places at once and nothing guarantees they're describing the same thing. Search Deal and you may get the Kent town alongside a Wikipedia entry for the New Deal. Check the photo and the paragraph actually belong to the place you asked for.
How does it handle the unexpected?
Push it. Type something unrelated, half a word, a question rather than a place. You're not hunting one particular failure here, just finding out how it behaves when you take it somewhere it wasn't built for.
Over to you
What did yours get wrong, and how would you fix it?
Part 3 · Beat 3 · The handoff
Until now the app has only fetched facts. This puts an LLM inside it, so it can think about what it found. Almost anywhere else that needs a paid API key of your own. In Canvas it's already wired up: nothing to sign up for and nothing to paste, so there's no key here to keep safe in the first place.
The key move
Add a button labelled "Briefing". When clicked, send the place's name and key facts to Gemini and ask it to write a friendly 3-bullet briefing for a colleague travelling there for work. Show the response under the card.
And it doesn't have to be a briefing
Part 3 · The other side of the handoff
Everything so far has come straight from an API. Your app can still ask the wrong question, but if the source is sound and the question is right, so is the data. A transformation by an LLM works differently.
What comes with it
Ask a model to summarise, rewrite, judge or explain and you take on everything that comes with one: it can invent things, it smooths the specific into the general, and it is only ever as good as your instruction.
Check every transformation
Anything the model rewrote, summarised or judged needs reading against the data it was handed. Not once on the day you built it. Every time it matters.
Tell it to use only what you gave it
Put it in the prompt: only use the data in the card, and say so if the answer isn't there. It won't stop invention altogether, but it removes a lot of the room for it.
Feed the errors back
If it gets the same thing wrong twice, that's a pattern, not bad luck. Say so in the chat and ask it to handle that case specifically. The feature gets better as you go.
Show the source, not just a warning
A note saying the text is AI-generated moves the risk onto the reader without helping them. Keep the raw figure beside the sentence written about it, so anyone can check at a glance. Warn them as well, if it's going wide.
The point of the whole session
“The API gives you the facts. The LLM allows you to transform and illustrate them in interesting ways. The magic is in the handoff.
And you can wire those two things together with a sentence.
First we'll find you something to build with. Then you get half an hour and I'll be walking the room.
Part 4 · Where to start · 1 of 2
All free, all keyless, all browser-friendly. Click any name to see exactly what it sends back. Do check before you build: free APIs quietly die.
| API | What it returns | What it could answer |
|---|---|---|
| Open-Meteo↗ | Live global weather for any coordinates | "Should I cycle to work? Answer in one line." |
| UK Carbon Intensity↗ | Live grid CO₂, from very low to very high | "Explain in a sentence whether now is a green time to use power." |
| Postcodes.io↗ | Region, council and constituency for any UK postcode | "Summarise what this area is known for." |
| UK Bank Holidays↗ | Official England, Scotland and Wales holidays | "Suggest a long-weekend trip around the next one." |
| Frankfurter↗ | European Central Bank exchange rates | "Explain what moved this rate this month." |
| USGS Earthquakes↗ | Live global quake feed | "Summarise the last 24 hours of activity." |
Part 4 · Where to start · 2 of 2
These return words and pictures rather than live figures, which makes them the easiest to hand straight to a model. Free and keyless, like the first list.
| API | What it returns | What it could answer |
|---|---|---|
| Open-Meteo Geocoding↗ | Country, population, timezone and coordinates for any place | "Write a 3-bullet primer for a colleague travelling there." |
| Wikipedia REST↗ | Plain-text article summaries and a photograph | "Rewrite this so a 12-year-old understands it." |
| Art Institute of Chicago↗ | High-resolution art images and metadata | "Tell me one surprising thing about this piece." |
| Free Dictionary↗ | Definitions, phonetics and audio | "Use this word in three sentences in different tones." |
| Datamuse↗ | Synonyms, rhymes and tip-of-the-tongue words | "Pick the best fit for a formal email and explain why." |
| Open Food Facts↗ | Nutrition and eco-score by barcode | "Flag anything worth knowing about this product." |
Part 4 · Or find your own
The two lists will keep anyone busy. But if there's a subject you actually care about, this will go and find you something to build with.
Use a new chat
This one isn't a build, it's a question. Open a fresh Gemini chat and ask it there. Canvas is off by default in a new chat, so you'll get an answer rather than an app, and whatever you've already built stays untouched in the other one.
Ask this in a new chat
Give me three completely free, open APIs that need NO API key, work from a browser, and return data about [TOPIC]. Explain in plain English what data this API returns, and three realistic things I could build with it.
Your turn
Activity 1
Your starter prompt
I want to use [NAME YOUR API]. Build an app that uses it to [TELL IT WHAT YOU WANT].
Activity 2 if time allows
Your starter prompt
Add a button that sends this data to Gemini and asks it to summarise what it means in three bullets. Show the answer under the card.
You have something that works. Now find out what it actually does, where it falls over, and what it still needs. This is the part that turns a demo into something you'd use on Monday.
Part 5 · Understand it, then improve it
In order. The first one matters most, and everybody should do it before touching anything else.
Actually use it. Feed it awkward things, ask it questions you suspect it can't handle, and go looking for the answers it gets wrong. You'll understand what you've built far faster this way than by reading a line of the code.
"What happens if I leave it blank? Or type something that doesn't exist? Or ask for somewhere with two names?"
Now fix what you found, and make it look like something you'd want to open. You are allowed to be fussy. It costs you a sentence.
"Make this a dark-mode dashboard." · "Move the result box to the top." · "Can it show three cities at once instead of one?"
For the confident. Wire in something genuinely new, or feed one API's answer into another the way we did with the place and its weather.
"Take the coordinates from this response and feed them into Open-Meteo to show the weather there too."
Two or three of you on the main screen. Volunteers, or I'll pick.
Part 6 · Before you send anyone a link
Before you share
Building something that works in twenty minutes is a thrill. It is not the same as having something tested. If it does anything that matters, spend real time checking it, look hard at what it actually outputs, and show it to one person who knows the subject before you go any wider.
Choose named people, not anyone with the link. If the app touches anything internal or protected, everyone you send it to must already have access to that data. Sharing the app must never become a way of sharing the data.
Part 6 · What to take away
Part 6 · When an API needs a key
Plenty of genuinely useful APIs want one, which is why we left them out today. Here's how to use one properly when you're back at your desk. The rule from Part 2 hasn't moved: the key never goes to Gemini, and it never goes in the code.
Never
Paste the key into the chat, or let it be written into the app. Anyone who opens that app can pull it straight back out, and Gemini has seen it either way.
Instead
Ask for a box in the app where you type your own key each time you use it. The app can reach the API; the key was never in the code for anyone to find.
Ask for it like this
This API needs a key. Add a box where I type my own key when I open the app, and use that. Don't write the key into the code.
If you share the app, everyone needs their own key. That's the whole point of the box: each person supplies theirs, and yours stays with you. Never send someone your key to get them started. The usage bills to you, it can be used without your knowing, and you can't take it back once it's out.
That's the session
Thanks.
You're keeping this deck, so every prompt from today comes with you. Click any of them.