Build your ownEmployability & Enterprise
← The talk
That's the whole idea from the talk. AI writes the actual code — your job is knowing which piece to ask for. Here's each of the four, with no jargon, plus a prompt you can copy and paste into any AI to try it yourself.
The list of what's on the page.
An HTML file is a plain text file that a web browser knows how to display. It's a series of labelled boxes — <h1>a big heading</h1>, <p>a paragraph</p>. Each label is called a tag. That's genuinely most of it.
Every tool, widget or page you'll ever make is, at heart, one HTML file. Once you know that a page is just a list of parts, "build me a tool" stops being scary — you're really asking for a tidy list with a bit of behaviour attached.
Ask any AI (ChatGPT, Claude, Copilot, or the helpchat 👀) for this. You'll get a single file back.
Save what it gives you as test.html, double-click it, and it opens in your browser. That's a working web page. You made it.
Embedding (iframes). An iframe is a window that shows one web page inside another. It's how a tool built once can appear inside Target Connect (drop it into a custom page or content block), SharePoint, Canvas or a Teams tab — you paste one line and your widget shows up where students already are:
Hosting (GitHub Pages). To get a public link, your file needs to live somewhere online. GitHub Pages hosts plain files like these for free:
The look, kept in its own file.
CSS is a list of style rules: this heading is blue, buttons are rounded, the font is bold. The question is where those rules live — and that choice is the whole game.
There are two ways styling ends up on a page:
AI defaults to inline styles unless you say otherwise — it's the easy path for a single file. The moment you're building more than one thing, tell it to use a shared file instead. That one instruction is what turns a pile of tools into a platform.
Because the look sits in one shared file, every tool you build can point at the same one. Change your brand blue in that single file and thirty tools re-brand themselves at once. It's also why each tool stays tiny: it holds almost no styling of its own. This is the difference between twelve mismatched gadgets and one platform that looks like it belongs together.
AI can't guess your colours. Tell it once, clearly, and it'll get it right every time. Keep a short "brand brief" like the one below and paste it at the start of any build:
When you ask AI to build a new tool, add one sentence:
That single instruction keeps every tool sharing one wardrobe. Six months and thirty tools later, one edit still restyles the lot.
Your content, in labelled boxes, kept out of the tool.
A JSON file holds data — a list of events, founders, questions, whatever — as labels and values:
When the content lives in a JSON file and the tool just reads it, the two come apart. Want to add an event or change a number? Edit the data. Nobody touches the tool, nothing breaks, and — crucially — you stop being the only person who can update it. That's when a tool stops being yours and starts being the team's.
Here's the real-world snag: most of your colleagues won't edit a JSON file — it looks like code, and one stray comma breaks it. So don't ask them to.
Instead, let them fill in an Airtable — a friendly online spreadsheet — and have a small automatic job turn that into the JSON for you, overnight, forever:
A door into someone else's system that you're allowed to knock on.
APIs are how live, always-up-to-date information gets into your tool without you keeping any of it yourself. Salary data, news headlines, job feeds — you ask the API, it replies, your tool draws the answer. None of the data is yours; you just know how to ask.
Some APIs give you a key — a password that proves the requests are yours. A key must never sit in an HTML file, because anyone can read a web page's code. But your static tool has no "backend" to hide it in. So how?
The trick is a tiny middleman called a Cloudflare Worker (free). It's a few lines that live in the middle: your tool asks the Worker, the Worker holds the secret key and asks the real API, then passes the answer back. The key never leaves the middle. Your site stays a pile of simple files.
Knowing which keys are secret and which aren't is one of those small bits of knowledge that changes what you can safely build. A brand colour is public. An API key is not. That's the whole rule.
Three steps, in order. That's it.
Target Connect strips out a lot of code when you paste it into a content block — it will quietly remove scripts, some styling, and anything it considers unsafe. Something that works perfectly as its own file can look broken, or do nothing, once it's inside Target Connect.
So the rule is simple: always test in UAT first, inside the real Target Connect page, before it goes anywhere near students. What survives isn't always obvious, and the safest fix is usually to host the tool as its own file and pull it in with an <iframe> (see the HTML section) — an iframe is a sealed window, so nothing inside it gets stripped.
↩ Back to the talk