Learn

Every system we use on this website, set up so you can do it yourself. Each one started with something that was causing us grief. That's the pressure point. Then you get the prompt and the steps to build your own.

Each guide says which model we'd use. Most of the time it's Sonnet, and Haiku for the simple, repeated jobs. When something is client-facing and the numbers have to be right, like a proposal going out, we use Fable 5.1, the most capable model. It costs about five times what Sonnet does, so I save it for the work that can't be wrong. I also had it run a full security check of this site overnight.

Systems

One guide for every system we run in Studio and on the engine.

Proposal review portal

Pressure point. Reviews on our proposals came in as dozens of WhatsApp voice notes and screenshots. We had to save every one to a drive, then paste them into the model one at a time to make the changes.

What you end up with. A page the reviewer opens on their phone. They tap any spot on the proposal, record a voice note, type, or suggest new wording, then press Send once. We get one file back with every note pinned to the exact line it's about.

What it needs. Hosting that runs PHP, a subdomain, and a model that writes code on your computer.

What the model can see. The model reads the document and your reviewer's notes. The voice notes sit on your server until you bring them home.

Recommended model. Claude Sonnet 5.5. A small site with sign-in and recording. That's everyday coding.

The prompt

I review documents with a colleague who sends feedback as WhatsApp voice notes
and screenshots. Build me a small web page for this, step by step:
- mobile first: the document shown page by page, readable on a phone
- tap anywhere on a page to drop a numbered pin
- each pin takes a voice note recorded in the browser, typed text,
  or suggested wording
- notes save on the phone as they go; nobody has to press Save
- one Send button saves the whole review on my server as a readable page
  and a data file I can work from
- only people I invite can open it
Use plain PHP and JavaScript that runs on ordinary shared hosting.
Ask me questions before you start.

The steps

1. You need hosting that runs PHP. We give each project its own subdomain.
2. Export the document as HTML, not PDF. With HTML the pins land on the exact line.
3. Put sign-in in from day one: one invite per person, and passwords only ever stored as hashes.
4. Test on the reviewer's own phone, early. Phones hang on to old versions of a page, so tell the model to stop the page being cached.
5. When the review comes back, bring it to your computer and let a speech model on your own machine turn the voice notes into text.

Watch for. Hosting security settings can block the microphone. The model has to allow it for that one page only. And keep every key and password out of the page itself.

A live team dashboard on one screen

Pressure point. Every day the team was checking the electricity tariff, the wholesale price, the weather and the industry news in four different places.

What you end up with. One screen that fits on a phone without scrolling. Each number gets a live tile with a small chart behind it, the weather is drawn as a little scene, and the latest headlines turn over. It refreshes itself every 30 minutes.

What it needs. Hosting that runs PHP and a scheduled task on the server.

What the model can see. Nothing private. It only reads public sources.

Recommended model. Claude Sonnet 5.5. Testing sources and wiring a cache is routine work.

The prompt

Build a one-screen dashboard for my team, phone first, no scrolling.
Tiles: [the numbers that matter to us], each with a small line chart behind it,
plus the weather and the three latest news headlines about [our industry].
Fetch every source on the server, keep a copy for 30 minutes, and let the page
refresh itself. Visitors' browsers should never call the outside sites.
First, find which public sources give this data without a paid key, test each
one, and show me what works before building.

The steps

1. Before building anything, get the model to research the sources and test them: government open data, the market operator, RSS feeds. Only build on the ones that actually answer.
2. The server fetches and caches everything, and the page only reads the cache. So it loads instantly, and the sources never see your team.
3. Keep the history as it comes in, one number per day. The charts grow on their own.
4. Lay the tiles out in a grid that shares the screen's height. Then check it on a small phone, a big one, and sideways.
5. Copy the news pictures to your own server instead of loading them from the news sites.

Watch for. Respect each source's terms. If a site says don't scrape it, leave it out. And a price that only changes once a quarter only needs checking once a day.

Meeting notes with the full transcript, in one place

Pressure point. The notes from every call landed in someone's inbox, and the full transcript sat in a separate document nobody ever opened.

What you end up with. A Meeting notes page. Every call has its summary, decisions, next steps, details and the word-for-word transcript, folded so you can read it in seconds.

What it needs. A meeting app with automatic notes, a drive connection for the model, and hosting with sign-in.

What the model can see. The model reads your meeting documents through your drive, and every transcript passes through it.

Recommended model. Claude Haiku 5.5. Splitting a document by its own headings is a simple job you repeat.

The prompt

Our meeting tool emails notes and saves a document with a summary, decisions,
next steps, details and the transcript. Write me a small script that takes that
document as text, splits it into those parts without rewriting anything, keeps a
list newest first, and shows it on a page: summary, decisions and next steps
open, details and the transcript folded.

The steps

1. Turn on automatic notes in your meeting app, so every call makes the document.
2. Export it as plain text from your drive. The model can do this itself through a drive connection.
3. Let the script split it by the document's own headings. Nothing gets summarised again, nothing gets reworded.
4. Put the newest call on your team's home screen. Tap it and the full notes open.

Watch for. A transcript holds everything anyone said on the call. Keep the page behind sign-in.

Shrinking PDFs without wrecking them

Pressure point. Our finished proposals were 6 to 9 MB each. Slow to send, and slow to open on a phone.

What you end up with. The same documents at about a third of the size, and they look identical, page for page.

What it needs. Ghostscript, free, on your own computer.

What the model can see. Nothing. The files never leave your machine.

Recommended model. Claude Haiku 5.5. It only runs one free tool with the right settings.

The prompt

Compress these PDFs for email and phones with Ghostscript. Before you change
anything, render one page of the original and of the compressed file side by side
and show me. If anything looks different (shadows, colours, transparency),
change the settings and try again. Keep the original if the result isn't smaller.

The steps

1. Install Ghostscript. It's free, and it does the compression.
2. Start from the e-book setting. It brings images down to screen quality.
3. Compare a page before and after, every single time. Our first attempt turned the soft shadows into grey blocks.
4. What fixed it was converting the colour to plain RGB instead of the default colour profile. Same look, 60 to 75% smaller.
5. Keep both. The original stays the master, and the small one is what you share.

Watch for. Files heavy with photos barely shrink, and that's normal. Don't trust the file size on its own. Look at the page.

A helper character for your website

Pressure point. People get stuck on the same few things on a site, and a help page is the last place anyone looks.

What you end up with. A small character that sits in the corner of the site. It notices where someone is and offers the one tip that helps right there, with a button that does the fix.

What it needs. A character sheet you draw, and a site you can edit.

What the model can see. Nothing beyond the code of your site.

Recommended model. Claude Sonnet 5.5. A few triggers on a page you already have.

The prompt

Design a small helper character for my website, in the spirit of the old
office assistant, but quiet: it appears only when someone seems stuck (long
pause on a form, the same page twice), says one short helpful line about that
exact spot, and offers a single button that does the fix. Draw the character in
[my style] with a few poses (idle, pointing, celebrating). Respect reduced motion
and let people dismiss it for good.

The steps

1. Draw the character first. A sheet with idle, pointing and happy poses, on a transparent background.
2. Write down the five moments people get stuck. For each one, one line and one fix.
3. Have the model hook each moment to something the page can notice: time spent on a field, a repeat visit, an error.
4. When someone dismisses it, it stays gone for good. Then test it with someone who has never seen the site.

Watch for. A helper that talks too much becomes the problem. One line, one button, then it goes quiet.

Voice notes: thirty at once instead of one at a time

Pressure point. Thirty voice notes meant thirty uploads, one at a time. That was fifteen minutes of waiting and clicking for one review.

What you end up with. We drop the whole batch on one page. Each note gets transcribed on our own device, the language is detected, and we get one text file for the batch. Only the text is saved.

What it needs. A browser, a few hundred MB for the speech model, and ideally a graphics card.

What the model can see. Nothing. Transcription runs on your own device.

Recommended model. Claude Opus 5.5. Speech in the browser, background workers and audio decoding all have to fit together.

The prompt

Build me a page where I drop a batch of audio files (voice notes from my phone)
and get one text file back. Transcribe on my own device with an open speech model
running in the browser, using the graphics card when there is one. Keep the next
file decoded while the current one transcribes, so the model is never idle. Keep
the phone awake during a batch and warn me before I close the page mid-way.

The steps

1. Run an open speech model in the browser, in a background worker, so the page doesn't freeze.
2. Decode each file into the simple audio format the model wants before you hand it over.
3. Pipeline the batch: while one note is transcribing, the next one is already being prepared.
4. Load the model once when the page opens. The browser keeps it for next time.
5. Save only the text. The audio never has to leave the device.

Watch for. The first visit downloads the model, which is hundreds of MB, so do it on wifi. On a graphics card, expect about ten minutes of audio transcribed per minute.

The video editor in Studio

Pressure point. For a short edit we were opening heavy desktop software just to make a few cuts. Sid has used editing software since film school and knows what he needs for a given job. We didn't need all the extra stuff, and we didn't want the model doing the editing for us.

What you end up with. An editor in the browser. You pick your frames from contact sheets, cut, join clips with glitch transitions, ramp the speed, and export exactly what you saw.

What it needs. Hosting, your clips uploaded to it, and a model that writes code on your computer.

What the model can see. The model works on your project files and footage on your computer.

Recommended model. Claude Opus 5.5. Many moving parts that must match frame for frame.

The prompt

Build a browser video editor in two steps. Select: each clip shown as a contact
sheet (12 frames per row); I drag along it to pick runs of frames, and each run
becomes a shot. Edit: a timeline with cuts, speed ramps and transitions. Use one
shared function for the preview, the editor and the final render, and prove
they match frame for frame.

The steps

1. Turn every clip into a contact sheet, so picking frames is a drag and not a scrub.
2. Play shots back by swapping between two video players. That keeps the cuts clean.
3. For the glitch joins, shrink the frames down to tiny greyscale images and find the closest matching frames between the two clips.
4. Use one piece of maths for the preview, the editor and the render. When we tested it, 48 frames matched with zero differences.
5. Lock editing while a render or a hand-over is running.

Watch for. Browsers cache scripts hard. Stamp every file on deploy (see Connections) or the editor breaks after an update.

Copy: checking every line of a website by voice

Pressure point. We needed to know every line on the site was really ours. That meant reading page after page and keeping track by hand.

What you end up with. Every core line of every site in one list, each one shown in its own site's design. We tick it, mark it Keep, Change or Cut, or just speak the new wording. A script file tracks every line as ours or generated.

What it needs. Hosting with sign-in, a browser speech model, and one script file listing every line.

What the model can see. Your recordings are saved on your own server. The model reads your notes to apply them.

Recommended model. Claude Sonnet 5.5. One list, one recorder, one script. It's clear, contained work.

The prompt

Make me a private page that lists every line of copy on my sites, in order,
each drawn in its own site's style. For each line: a tick, Keep / Change / Cut,
and a record button for dictating the new wording. Transcribe the recordings in
the browser. Keep one file that lists every line as mine or generated, and treat
that file as the truth: if the site disagrees, the site is wrong.

The steps

1. Build the list of lines from one script file. Never scrape the live pages for it.
2. Record with the browser's own recorder. It picks whatever audio type the phone supports.
3. Transcribe in the browser, and keep a button for the notes still waiting.
4. Apply the words cleaned only (ums and swearing out), mark them as yours, redeploy, then mark the notes done.
5. Never renumber the lines. Every note is pinned to a line's number.

Watch for. Keep it behind sign-in. A page of every line on your sites is also a map of your sites.

Story: a film builder

Pressure point. The film's beats, shots and takes lived in different notes. And with two tabs open, one could overwrite the other.

What you end up with. One place for the whole film: beats, then shots, then prompts and takes. Every save is versioned, and we can go live so invited guests watch us build.

What it needs. Hosting that runs PHP, with sign-in for you and approved guests.

What the model can see. Your story lives on your server. The model reads it when you build with it.

Recommended model. Claude Opus 5.5. Versioning, saves that can clash, and guest access are easy to get subtly wrong.

The prompt

Build a film planner: beats, shots under each beat, prompts and takes under each
shot. Save the whole story as one document with a version number; every save sends
the version it started from, and the server refuses a stale save instead of
overwriting. Add live sessions: I go live, visitors ask to join with a name, I let
them in read-only, and going offline ends every guest pass.

The steps

1. Keep the whole story as one versioned document, and add every save to a history.
2. Reject a stale save and hand back the newer copy. Then tabs never wipe each other out.
3. Let anyone watching ask for just the changes since the version they already have.
4. For guests: they send a request with a name and a note, you approve it, they get read-only access, and their passes are stored only as hashes.

Watch for. Limit join requests per hour, so nobody can flood a public page.

A community sign-in portal built on Discord

Pressure point. The community's tools were all over the place: Discord, raid sign-ups, logs and a calendar, each one somewhere different. And we didn't want the responsibility of setting up passwords, a login page and a database of accounts.

What you end up with. One portal. Members sign in with Discord, see everything in one place, sign up for events, and every update gets announced back in Discord.

What it needs. A Discord server, a Discord app with sign-in turned on, and hosting.

What the model can see. Members share their Discord name and roles with your site. The model works on the code, not their data.

Recommended model. Claude Opus 5.5. Sign-in, roles and consent are security work.

The prompt

Build a members' portal for my Discord community. Sign in with Discord (OAuth),
and use Discord roles as the single source of truth for who sees what. Access:
member of the server, in it for at least [N] days, and agreed to the terms, all
checked by one function. Mirror our event sign-up tool into the portal every few
minutes, both ways. Ask for consent before reading anyone's messages, and when
someone says no, delete what we hold and never pull it again.

The steps

1. Use Discord sign-in instead of building passwords. Then there's no password database to protect.
2. Let roles decide everything, through one access function the whole site calls.
3. Sync your event tool on a schedule, and push sign-ups made on the site back to it.
4. Version your consent. When the terms change, bump the version and everyone gets asked again.
5. Block open redirects on the sign-in return path.

Watch for. Consent is the part people remember. Make it easy to say no, and once someone says no, it stays no and they can see it.

Programming an image: a concept from your own photos

Pressure point. If you just ask a chat app for a picture, you get something generic. For a proposal we needed an indicative concept of the client's real place, built from work we've actually done. So it's less about getting a free image and more about programming the image.

What you end up with. An indicative concept image. We took a photo of the real site and composited in installations that match photos of our own finished projects, so the client sees what it would look like.

What it needs. A photo of the place, photos of your own past work, and an image service that takes several references (Higgsfield here).

What the model can see. Your photos go to the image service. If the model drives the website for you, it acts in your signed-in account.

Recommended model. Claude Sonnet 5.5. Writing the brief and checking the result against the real site.

The prompt

I need an indicative concept image for a proposal. Attached: a photo of the
site, and photos of installations we have built. Use an image model that takes
several reference images. Keep the site exactly as it is, and add panels that
match our installations: same mounting, same colour, same scale. Give me two
options and tell me what you changed. Before anything that costs credits, stop
and tell me the model, the count and the cost.

The steps

1. Start from real photos of the place itself, from the angle the client knows.
2. Pick reference photos of your own finished work, as close as you can get to the same roof or ground.
3. Use an image model that takes several references. We used Nano Banana Pro on Higgsfield, on its free Unlimited setting in the website.
4. Write the brief the way you would for a retoucher: what stays, what changes, what it has to match.
5. Check the result against the real site: edges, shadows, scale. Then label it indicative.
6. Ask before every paid run. The free setting can switch itself off when the page reloads.

Watch for. It's a concept. Not a survey, and not a photo of finished work. Label it indicative every time.

3D characters from a concept sheet

Pressure point. Building characters in Blender through the model gave us rough, blocky figures that looked nothing like the concept art. So we found a way to work around it.

What you end up with. High-detail characters that look like the concept art, rigged and ready to animate. Credits only get spent after each step passes a look.

What it needs. Tripo (about 55 credits for the model, 40 for retopology, 20 for the rig), Blender, and the model controlling your browser.

What the model can see. The model uses your browser while you are signed in to Tripo, so it can spend credits on that account. Ask before each paid step.

Recommended model. Claude Sonnet 5.5. Driving the steps and checking each result before the next one.

The prompt

Turn this character turnaround into a rigged 3D model in Tripo: first clean
the views (A-pose, hands empty, props removed, plain grey background), then
multiview from front, left and back. Show me the high detail model front and
back before paying for anything else. Then retopology, then a humanoid rig.
Tell me the credits for each step before you run it.

The steps

1. Clean the turnaround first: A-pose, empty hands, props separate, plain background. A prop fused to a hand breaks the rig.
2. Multiview from front, left and back. A side view facing left goes in the Left slot, or a face shows up on the back.
3. Generate the high-detail model and look at it front and back. Use the free retry before you pay for anything else.
4. Then retopology (about 10,000 quads), then the humanoid rig. Preset animations and exports are free.
5. Bring it into Blender through the model's Blender connection to check the poses and fix the weights.

Watch for. Auto-rigging glues long robes to the hands. Fix the arm weights with a short script.

Connections

How the pieces talk to each other, so you're not moving files around by hand.

Connect the model to your email and Drive

Pressure point. Proposals, attachments and meeting notes all live in an inbox and a shared drive. To give the model context we were downloading files by hand and uploading them again.

What you end up with. The model searches our email and Drive itself, reads the thread or the meeting notes, and drafts replies for us to check and send.

What it needs. A model app with connectors, and the Gmail and Drive accounts you choose to connect.

What the model can see. The model can read the mail and files in every account you connect.

Recommended model. Claude Sonnet 5.5. Finding the right thread and drafting a reply.

The prompt

Using my Gmail and Google Drive connections, find every email from [client]
about [project] in the last 30 days. List the attachments, summarise what is
still open, and draft a reply for me to check. Don't send anything.

The steps

1. In your model app, open the connectors and add Gmail and Google Drive. Sign in with the account that holds the work.
2. Ask in plain words. For example: find the latest meeting notes for the marketing call and list the next steps.
3. Keep sending in your own hands. The model writes the drafts; you read them and press Send.
4. If a file is too big to pass through a chat, sync the drive to your computer and point the model at the folder.
5. Keep accounts apart. A client's mailbox and your own should never be the same connection.

Watch for. Only connect the accounts the job needs, and remove the connection when the work is done.

Pull proposals and their context from a work email

Pressure point. Every proposal meant hunting through email for the drawings, the bills and the client's questions, then downloading them one by one.

What you end up with. One ask pulls everything about a project out of the inbox: the thread, the attachments and the open questions, ready to build from.

What it needs. The email connection above, and one project folder per client.

What the model can see. The model reads that mailbox, including attachments and client details.

Recommended model. Claude Fable 5.1. This brief turns into a proposal a client reads, and the numbers in it have to be right.

The prompt

Search my work email for everything about [site or client] since [date]:
threads, attachments (bills, drawings, load data) and any questions the client
asked. Save the attachments into [project folder] with clear names, and write a
one-page brief: what we know, what is missing, what the client asked.

The steps

1. Connect the work mailbox to the model (see the guide above).
2. Set up one project folder per client, on your computer or your drive.
3. Ask for the brief, then check it against the thread once.
4. Use that brief as the first step the next time you build a proposal.

Watch for. Bills and drawings are the client's data. Keep them in the project folder, never anywhere public.

A notification on your phone when something lands

Pressure point. We kept checking an inbox or a page to see if a review had come in.

What you end up with. Our phone buzzes the moment someone presses Send. It says who it was and how many notes, and nothing private.

What it needs. The free ntfy app on your phone, and a server that can send a web request.

What the model can see. The short message passes through ntfy's servers. Keep it bland.

Recommended model. Claude Haiku 5.5. One short message sent when something lands.

The prompt

When [event] happens in my app, send a push notification to my phone using
ntfy (free, no account). Use a long random topic name so nobody else can
subscribe. Put only who and how many in the message, never names of clients,
prices or note text.

The steps

1. Install the free ntfy app on your phone.
2. Let the model make a long random topic name on your server and show it to you once.
3. Subscribe to that topic in the app.
4. Have your app send one short line when something lands, with a link to open it.

Watch for. Public notification services pass your messages through their servers. Keep the message bland.

Letting the model deploy to your own server, safely

Pressure point. Every change meant copying files to the server by hand and hoping nothing broke.

What you end up with. One command per site. The model packs the files, checks them on the server, backs up the old version and swaps the new one in.

What it needs. Your own server with SSH, an SSH key, and one deploy script per site.

What the model can see. The model holds a key to your server and can change anything on it.

Recommended model. Claude Opus 5.5. It holds the key to your server, so use the most careful model.

The prompt

Write me a deploy script for this site: pack the files, send them to a staging
folder on my server, check every PHP file for errors there, back up what is
live, then swap the new version in. Stop at the first error. Keep data folders
outside the public web folder and never touch them.

The steps

1. Give the model access to the server with an SSH key. Never a password.
2. Keep each site's files in one local folder, with its own deploy script.
3. Always stage, check, back up, then swap. If a check fails, nothing live changes.
4. Keep anything private (data, keys, user lists) in folders the web can't reach.
5. After a deploy, have the model load the page and make sure it answers.

Watch for. On Windows, scripts can turn server paths into local ones without telling you. Check the first run line by line.

Running a speech model on your own computer: free and private

Pressure point. Transcribing on someone else's server costs money, and it sends private recordings away.

What you end up with. The same tools running on our own computer, offline. Recordings never leave the machine, and it costs nothing per minute.

What it needs. A computer that can run the speech model, ideally with a graphics card.

What the model can see. Nothing. Everything stays on your machine.

Recommended model. Claude Sonnet 5.5. Local paths and a small server on your own machine.

The prompt

Run my tools locally on this computer: a small local server that only answers
this machine, with the speech model files saved on disk instead of downloaded each
time. Pull data from the live site read-only; pushing back must show me what
changes and ask yes or no, back up the live copy first, and stop on conflicts.

The steps

1. Keep the model files on disk and point the tools at a plain local path. A web address won't work.
2. Run a local server that only answers this computer.
3. Pull from the live site read-only, and back up your local data first.
4. Push only data, never code. Show the changes, ask, back up, then push.

Watch for. Keep a lock, so the live site and the local copy can't both be edited at the same time.

A Discord bot with slash commands, and announcing every update

Pressure point. Members kept asking what had changed, and settings like opting out lived on a website they hardly ever opened.

What you end up with. Slash commands right inside Discord, and an automatic post in the server for every update the moment it ships.

What it needs. A Discord app with a bot, its public key, and hosting.

What the model can see. The bot's secret lives on your server, out of the public folder.

Recommended model. Claude Sonnet 5.5. Signature checks and a setup script. Well-trodden ground.

The prompt

Add a Discord bot to my community site. One endpoint receives slash commands and
checks Discord's signature on every request. Commands: [/optout, /optin, ...].
After each live deploy, post every changelog item newer than the last one posted,
as an embed with a screenshot. Give me a dry-run flag to preview before posting.

The steps

1. Check Discord's signature on every command that comes in, and refuse anything unsigned.
2. Register the commands with a setup script, and run it again whenever the commands change.
3. Hook the announcements to the deploy, and only post what's newer than the last item posted.
4. Keep a dry-run flag and a skip flag for the quiet deploys.

Watch for. Never put the bot's secret in the website's public folder.

Beating stale caches: stamping every file on deploy

Pressure point. After an update, visitors were still running week-old scripts, and the editor broke.

What you end up with. Every update shows up straight away for everyone, without asking anybody to refresh.

What it needs. A deploy script you or the model can edit.

What the model can see. Nothing beyond your site's files.

Recommended model. Claude Haiku 5.5. Hashing files and rewriting links is mechanical.

The prompt

In my deploy script, rewrite every reference to a script or stylesheet as
file.js?v=<first characters of its content hash>, so a changed file gets a new
address and browsers fetch it fresh. Unchanged files keep their address.

The steps

1. At deploy time, hash the contents of each shared file.
2. Rewrite the references in the pages to include that hash.
3. Leave unchanged files alone so they stay cached.
4. Back up the live folder before any risky deploy, and keep the old addresses redirecting until you're sure nothing uses them.

Watch for. Hosting often caches scripts for a week. If something breaks for some people and not others, suspect the cache first.