A toy for everyone
We built the AI Bundestrainer —
so you learn how to build products with AI.
Yes, the AI Bundestrainer is a satire tabloid. But it is mostly one thing: a living example of how anyone can build a real product with artificial intelligence today — if you dare to start.
Why we do this
Sure: we want attention. For inzpyre.me, for our parent project, for our apps. And because we believe learning is allowed to be fun. A tabloid satire is an odd wrapper for an education promise — which is exactly why it works.
More important, though: we want to show you what AI actually does — not in PowerPoint slides, but in a real tool you can use in 30 seconds. Click through here and you see the whole range: research, write, judge, sharpen a punchline. Not flawless. But often faster than an entire newsroom.
That is one side: we want to put the capabilities of AI in front of you. The other: we want to show you how to build products with AI yourself — whether that is a web tool like the AI Bundestrainer, your own iPhone app, or a small automation on your laptop. Anyone could write their own software today with tools like Claude Code. But between a pretty demo and a tool that does not fall apart when 100,000 people tap on it at once sits a lot of work. Which problems are waiting, which traps are set, how you get past them — that is exactly what you will find further down in the logbook.
Our goal
From click to back-page headline in 15 seconds
Every generation runs the same play — a bit of AI research, a bit of algorithm, a bit of pure manager gut. And at the end, a piece of content you can actually share.
You make the calls
The frontend is the surface you tap — manager style, target, filters. We kept it deliberately simple so you never have to write a fiddly AI prompt. You decide what you want; we turn the rest into a prompt. Nothing else happens here.
AI pulls data from the web
We gather the candidates that fit your rules. Current form, stats, opponent breakdowns, market values — all loaded live and matched against your filters. This is where the real work happens.
The AI Bundestrainer decides
Your filters meet the data, then the verdict drops. Which eleven? What reasoning? What tone? "72% pass completion. Lets the ball do the talking instead of his mouth." Data first, tongue firmly in cheek.
You get the output
A short statement, a full squad, or a single-player rating — complete with data, facts, roles and the odd zinger. All in a few seconds, all shareable, all wrapped in a UX that is actually fun to use.
How to build your own AI product
Here is the workflow we used to build the AI Bundestrainer — and the one anyone can use today to build their own AI product: a web app like the Bundestrainer, an iPhone app, or a small automation on your computer. Three phases, a handful of tools, plenty of links — so you never have to guess where to start.
Note: We have no partnerships with any of the providers named here. We only recommend tools we actively use ourselves and think are worth it.
The tools we build with
We are hands-on people, not theorists. For every step of production there is now an AI tool that saves weeks of work. This is our stack:
Wispr Flow
Talk to the AI instead of typing
You speak faster than you type — and you toss out half-formed thoughts as easily as you would to a colleague. Wispr Flow runs in the background and drops your voice straight into any input field. Not a must-have for building a tool, but we recommend it, because we believe the future of working with AI is your voice, not your keyboard.
Claude Cowork
Concept and planning
Brainstorming, writing the spec, sketching the architecture. Before a single line of code there is a Markdown document we worked through with Claude Cowork — feature definition, edge cases, audience. Cowork is also our day-to-day colleague for marketing, content and research.
Claude Code
Coding — no coding skills required
From the first scaffold to the final deploy: Claude Code wrote all of the code, refactors included. We set the direction, Claude Code does the work — and pushes back when our idea is nonsense. The point: you do not need to know how to code for this. We are not techies ourselves.
GitHub
Version control and backup
GitHub keeps every state of your code in what is called a repository — a backup you can return to at any time. We recommend a private repository, so your code is not out there for everyone to read.
Supabase
Database and backend
We store data in a database — for the AI Bundestrainer that means newsletter sign-ups and the request cache, for example. We use Supabase for it: database, auth and storage in one. Only needed if your app needs a backend — some tools (pure automations, say) get by without one.
Vercel
Hosting the website
A website has to live somewhere. Vercel was the easiest choice for us: automatic deploys on every push, edge functions for the API routes, hosting effort close to zero.
Cloudflare
Fast delivery & security
Cloudflare sits in front of our site and handles two things: speed (a CDN, so content is served close to the user worldwide) and protection (DDoS defence, bot filtering, SSL).
Claude Design
Video and animation
The explainer animations and videos on this page were made with Claude Design. A brief and a few iterations turn into a self-running HTML bundle — no video editing, no After Effects.
Planning — you describe, Claude asks the questions
Main tool: Claude Cowork. You describe what your app should do, and you task Claude with grilling you until the concept actually stands up. At the end Claude generates a Markdown file with the finished concept — your brief for the coding phase.
Standard prompt for Claude Cowork — tweak and copy
I want to build a [web app / iOS app / Android app]. It should have the following features: [describe features here] The audience is: [describe audience here] Keep asking me questions about features, edge cases and audience until you fully understand the concept. Also work through the data and architecture side with me: - What data does the app store and process? - Which of it is critical (sensitive, confidential, regulated — e.g. health, finance, personal notes)? - Which data must WE own as the operator (server, database, backups)? - Which data should belong to the user only (local on the device, end-to-end encrypted, never on our servers)? - Which software architecture fits (pure frontend app with local storage, backend with auth + database, E2E-encrypted sync, ...)? Then build a Markdown file with the finished concept that I can share with Claude Code in the next step.
Why the data question? Software architecture 101
You no longer have to code yourself — but a basic grasp of software architecture still pays off. The most interesting question is almost always: what actually happens to the data? Which of it lands on your servers, which only on the user’s device, which must never leave the browser?
For the AI Bundestrainer this is fairly harmless — we process no sensitive user data, everything is public and satirical. But the moment you build an app handling critical data (health, finance, a diary, customer records ...), you should make that architecture call deliberately, before the first line of code is written. That is exactly what the data block in the prompt above is for.
Coding — Claude Code builds, you steer
Your tool: Claude Code. Before you dive in, you have to decide how you want to run Claude Code at all. There are three ways — pick the one that feels least like a server-room bunker to you.
But honestly: if you actually want to put a product live — your own domain, a deploy to Vercel/Netlify, a push to GitHub, a connection to Supabase & co. — the desktop app hits its limits fast. For real launch workflows we recommend Visual Studio Code or the terminal. The desktop app is great for getting started and for prototypes — but it is not a production tool.
Three ways to run Claude Code
Claude Code desktop app
Anthropic's own app, its own interface. Plus: the friendliest for non-techies, perfect for getting started and for first tests. Minus: less flexible the moment you want to look deeper into the code — and for production workflows (GitHub push, deploy to Vercel/Netlify, connecting external services) the app is not built for that yet, the way we see it. Once you actually want to launch, go for way 2 or 3.
In Visual Studio Code
A code editor with the Claude Code plugin. Plus: code, terminal and Claude in one window — perfect once you fancy reading along in the code. Minus: a bit intimidating at first, because you see everything at once.
In the terminal
A direct install, the fastest start for the tech-minded. Plus: maximum flexibility. Minus: the terminal is unfamiliar for non-techies — it can quickly feel like a hacker console.
Workflow
Create a project folder on your computer. Drop the Markdown file from Phase 1 into it. Open Claude Code in that folder and send it the following prompt:
Standard prompt for Claude Code — copy and use
Read the Markdown file I have placed in the project folder. Build the application based on this concept. If you have questions, please ask them before you start. Please code the app in several sprints — we only ever do one clearly bounded part at a time. At the end of each sprint, tell me what you built and what comes next.
Tip: use planning mode
When you fire off a prompt, Claude Code first plans what it intends to do in planning mode. You read it over, say „looks good“ — and only then does it start. Nothing happens straight away. Alternatively there is an auto mode that works right away.
Switching modes:
- In the terminal: cycle through the modes with the Shift + Tab keys. The active mode shows at the bottom of the input line.
- In the desktop app / VS Code: a toggle in the UI under the input line (the same shortcut usually works too).
Why sprints?
After each sprint you can close and restart Claude Code (or the desktop app, or the terminal). Two upsides: (1) you save tokens, because Claude does not have to re-read the entire history every time. (2) You can save your progress after each sprint — ideally in a GitHub repository (see right below). If the next sprint goes sideways, you can always roll back to the last good state.
Recommendation: set up a GitHub repository
GitHub keeps every state of your code — and doubles as your backup. You can commit after each sprint and return to an earlier state at any time. Important: make it a private repository, so your code is not publicly visible (think API keys, internal notes). Vercel and Netlify deploy straight out of GitHub — so the workflow pays off twice.
As a rule Claude Code also walks you through the rest of the process: after each sprint it asks „Shall we carry on with the next step? What would you like to do next?“ — and it flags things that are still missing, such as tools you need to connect or a database that is not wired up yet.
If you are not sure where to go next, just ask Claude Code: „What is still missing before I can use the app?“ or „What do I need to finalise before testing?“
Below you get an overview of everything we had to account for with the AI Bundestrainer — and what matters for you depending on your app type.
If your tool uses AI (like the AI Bundestrainer)
You need an API account with one or more providers — that is the interface your app uses to talk to the language model. Which provider fits depends on language, task and budget. We use Anthropic + OpenAI (model choice in detail in Phase 3).
If you want to store data
The moment your app remembers anything — newsletter sign-ups, caches, profiles, content — you need a database. We use Supabase (database, auth and storage in one, beginner-friendly). Other popular options are MongoDB Atlas, PlanetScale or Firebase. Pure automations with no stored data do not need this.
If you build a web app
A web app has to be hosted somewhere so it is reachable at a URL. We use Vercel — because it redeploys automatically on every code push (via GitHub), serves worldwide, and is free for small projects. A well-known alternative is Netlify, with a similar model.
If you build an iOS app
iOS apps are written in Swift — Apple’s own app language. As your dev tool you need Xcode (free on the Mac App Store): this is where you build, test and finally upload your app to the App Store — via App Store Connect. For that you need an Apple Developer account (≈99 USD/year).
Testing and optimisation — fine-tuning on the real tool
Up to here everything is still fairly easy. You talk to the AI, tell it what to do — and the AI handles the rest. The testing and optimisation phase is the most exciting part. This is where the real problem-solving lives: whether your tool actually does what it should. For us: naming the right players or landing the right statement. For you: solving the problem you built your tool for in the first place.
Web apps you test in the browser, iOS apps in the Xcode simulator. Once you spot problems, the fine-tuning begins. Typical questions that come up:
- Does the UX hold up even when the user does something unexpected? If they close the app quickly — does their data survive? After a refresh, does the right state load again?
- If you use AI: does your tool actually deliver the answers it is meant to — or is the model hallucinating?
- If you use AI: what token cost does each call rack up? How do you manage it so that going viral does not turn your tool into a money pit?
- Do you need to connect more APIs, because external tools give you better data?
- Are you using a search? Can you cache or pre-process the results in an intermediate step so the final answer holds up?
Below we show you the problems we ran into with the AI Bundestrainer — and how we solved them.
The token question: would going viral kill us?
Before we wrote a single line of code, we asked one question: what happens if the AI Bundestrainer goes viral? The answer was uncomfortable.
The projection
Picture 100,000 people trying the AI Bundestrainer in a single day. Each clicks twice — one squad, one statement. That is 200,000 generations. Each with ~8,000 input and ~8,000 output tokens.
On a premium reasoning model (GPT-4, Claude Opus) each generation costs roughly $0.78. Which adds up to:
Out of the question.
So: which levers do we have to bring the cost down?
Model choice
$0.78 → $0.002 per callThe biggest lever, and the first. Premium reasoning models are overkill for our use case — the AI Bundestrainer makes structured decisions from a predefined pool, this is not free-form philosophy. We switched to stats-optimised classes: OpenAI GPT-4o-mini for the squad, Claude Haiku 4.5 for statements and the half-time talk. Both cost sub-cent per call.
The $156,000 day suddenly becomes ~$400. From one single decision at the start.
| Model | Input / 1M tok | Output / 1M tok |
|---|---|---|
| Claude Opus 4 (premium reasoning) | $15 | $75 |
| GPT-4 (classic) | $30 | $60 |
| Claude Haiku 4.5· our pick | $1 | $5 |
| OpenAI GPT-4o-mini· our pick | $0.15 | $0.60 |
| Gemini 2.0 Flash | $0.10 | $0.40 |
| Qwen 2.5 72B (China) | $0.35 | $0.40 |
| DeepSeek V3 (China) | $0.27 | $1.10 |
Not meant to be exhaustive — these are the models we evaluated. Prices are rounded list prices per 1 million tokens. There are many more options on the market, and prices change fast.
What we learned: Chinese models are cheap on paper — but for German text generation in certain forms (squad statements in the manager’s voice, say) they are sadly unusable. The word choice slips into generic or into plain wrong fast. For structured picks (squad, line-up) GPT-4o-mini does the job — for satire and tone you have to stay with Claude Haiku. A single model for everything does not exist.
Our model story
Claude was too expensive for us. We tested the Chinese models and binned them (German satire not reliable). Then we tried Gemini Flash — fast, but our squad calls kept aborting, because the model threw schema errors and produced timeouts. In the end we switched to GPT-4o-mini for the squad and Haiku 4.5 for the satire copy. Value winner: GPT-4o-mini, where structure counts. Quality winner: Haiku, where tone counts.
Pre-computation — research once, reuse often
−98% web-search costTwo levels. The World Cup squad is already set — we researched the 108 candidates once, thoroughly, and stored them in a database. When generating, the AI just reads from it instead of searching again on every call. On top of that, one research call per World Cup match pulls current form, injuries and opponent analysis from the web. Every user feature picks the same context out of the database. Live data that changes hourly we fetch only once a day.
When every feature shares the same context, we do not just save money — we gain consistency. Every feature sees the same world.
Cache — same question, same answer
~65% of requests skip the AI entirelyLots of users pick similar combinations — for example "Klopp style + goal threat + Bundesliga only". If two people ask for the exact same thing, why make the AI compute it twice? On every request we check whether the same inputs have already come through. If so, we serve the finished answer from our database instead of starting the AI again. Valid for 6 hours. In the World Cup group stage that catches roughly 60–70% of all requests.
The bigger the rush, the more the cache kicks in. Virality gets cheaper, not more expensive.
Cap max tokens
−30% latencyThe model is allowed "up to 16,000 output tokens" — many models treat that as a free pass to ramble, even when the final JSON only needs 3,000. Hard cap at 7,000. The model reads that as a budget signal and trims itself automatically. No quality loss, because the real output volume sits below it anyway.
A side effect that matters later: the cap also helps against timeouts. When the model thinks forever, our web host cuts it off — more on that in a moment.
And here is where we are now
The $156,000 day has turned into about 65 dollars. Combined: −99.96%. Yes, that is still money. But for us the maths is clear.
If the tool goes viral: it brings us attention you probably could not even buy with paid ads:
- Screenshots on social media
- Chats over a pint
- Clicks on inzpyre.me
Paid ads with comparable reach would cost many times more.
If it does not go viral: we pay nothing either — with no usage, no token cost piles up. All that is left is the build effort. And with AI, building tools like this is no longer the hurdle it once was.
And if the maths does miss the mark: our budget at Claude and OpenAI is hard-capped. We can decide at any time how many generations we allow — when in doubt, we turn the tap down. Losing control is off the table.
What other challenges were there?
Cheap models are lovely — but they bring new problems. Three of them gave us the most grief.
Hallucinations
Problem
The model "invented" players outside our squad. Sometimes a Belgian, sometimes a Croatian, sometimes a fantasy name like "Sandro Duxch" — a merge of two real players. For the German national team, obviously nonsense.
Fix
A four-step defence: (1) We researched the World Cup squad once, cleanly, and stored it in a database — picks come from there, full stop. (2) A rule in the prompt: "Germans only. Playing in the Bundesliga does not make someone a German international." (3) When too few players match, the AI should pick from our satire squad rather than hallucinate. (4) A server-side name check: anyone not on the list is dropped automatically.
Timeouts
Problem
When the AI took too long, our web host simply cut it off after 60 seconds — the user saw no answer, just an error. The squad nomination in particular, where the AI builds 26 players plus reasons in one go, was a constant headache.
Fix
Three things at once. First we told the AI it could only spit out a set amount of text per request — better short and fast than rambling and aborted. Second we slimmed down the data we feed it — less input, less reading. Third we switched to a model that delivers structured answers faster. Result: no more timeouts, and it was the same lever as the cost-saving — solved once, won twice.
Tone of voice on a budget model
Problem
Cheap models can do facts, but they often sound generic. A half-time talk from Trapattoni has to sound like Trapattoni, Magath like Magath, Klopp like Klopp. No budget model nails that on its own.
Fix
We built a detailed voice profile for each manager — signature phrases, sentence structure, gestures, running gags, a negative heuristic ("he would never say that"). The profile goes into the system prompt on every call. Result: even on a budget model the tone stays surprisingly close to the original. Have a listen, you will notice.
The biggest lesson
With tools like Claude Code or Codex (the coding tool from OpenAI / ChatGPT), anyone can now build software. Knowing how to code is no longer an automatic advantage. What decides it is something else:
1 · Efficiency
How cost-efficient does your tool run?
Token usage = operating cost. Anyone who has not got models, caching and pre-computation under control gets flattened by the bill on the first viral day.
2 · Data
Which data do you make usable?
AI on its own is fluency without substance. Which existing data can you pull into your app so it gets smarter? For us: everything about the players.
3 · Creativity
How cleverly do you connect AI to your idea?
Anyone can use what AI can do. What matters is whether you connect a good idea with the right data and the right AI skills — to build a useful product, solve a problem, or create a genuinely good experience.
Think about how you can make the capabilities of AI usable inside your tool, to build products that delight people and solve problems.
- Research
- Analysing & interpreting data
- Drawing connections between topics and spotting patterns
- Generating language
- Personalisation & tailored recommendations
- Automating tasks
- … and much more.
The lever behind all the other levers.
Like what you have learned?
Then it is time to do. Try building something yourself.
You only understand how AI works once you use it yourself. A small tool with Claude Code, a weekend experiment, an internal script — it does not matter. You can ask Claude Cowork how to solve a problem any time. Starting beats reading.
Lifelong learning keeps us young
We build tools that make lifelong learning possible.
At inzpyre.me we want to help you understand the world of AI better. AI is the most interesting thing you can learn about right now — and the AI Bundestrainer is one of the experiments we use to show it.
If you want to see more from us, visit our website:
And you get the most important pieces in your inbox each month by subscribing to our newsletter:
The AI Bundestrainer is satire, inzpyre.me is serious.