Idea library

15 teaching apps you can build today

Every one of these comes with a finished build prompt. Copy it, paste it into Google AI Studio, and you will have a working app in a few minutes. No code, no account beyond a Google one, nothing to pay for.

Nothing here is precious. Pick the one closest to what you teach, build it, then change the content to yours by asking in plain English. If you want to learn to write these prompts yourself, that is Part 1, and it is free.

Accounting and business Sort into categories

Cost classification sorter

Twelve cost items, four categories, feedback after every answer.

What students practise

Telling fixed, variable, mixed and step costs apart — and saying why.

Build prompt

Build a single-screen practice app for first-year management accounting students who can already define fixed and variable costs but hesitate on mixed and step costs. Show one cost item at a time. The student chooses one of four categories: fixed, variable, mixed, or step. Twelve items in total, three of each category, always in the same order. Write the twelve items in plain language, for example "Factory rent of 4,000 per month" and "A supervisor salary plus a bonus of 2% of output". Feedback appears immediately after each answer, before the next item: if the answer is right, say so and give a one-sentence explanation; if it is wrong, name the correct category, give the explanation, and add one line on why the chosen category does not fit. An answer cannot be changed once submitted. Show a running score in the form "4 of 7 correct". At the end, show the final score and list every item answered incorrectly with its correct category. A "Start again" button resets the score and returns to the first item.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Writing and research skills Find the error

Spot the citation error

One reference at a time, one mistake in each, click the broken part.

What students practise

Proofreading references closely enough to see what is actually wrong.

Build prompt

Build a single-screen practice app for undergraduates learning to proofread references. Show one reference at a time, formatted in APA style, with exactly one formatting mistake in it: a missing year, italics in the wrong place, authors out of order, or a full stop where a comma belongs. Break each reference into clickable segments so the student can click the part they believe is wrong. Ten references in total, with the type of error varying between them. When the student clicks, tell them immediately whether they found the error; either way, name the mistake, show the corrected version of that segment, and give a one-sentence rule explaining the convention. The student moves on with a "Next" button. Show a running score in the form "4 of 7 correct". At the end, show the final score and list every reference they got wrong with its error named. A "Start again" button resets the score and returns to the first reference.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Statistics and quantitative methods Estimate, then compare

Guess the correlation

A scatterplot, a slider, and ten rounds of calibrating your eye.

What students practise

Reading strength of relationship off a plot instead of guessing high every time.

Build prompt

Build a single-screen practice app that trains students to estimate correlation from a scatterplot. Each round, draw a scatterplot of about forty points generated to a hidden correlation value between -1 and 1. The student estimates that value using a slider running from -1 to 1 in steps of 0.05, then presses "Check". Reveal the true value, the estimate, and how far apart they were, and say in one sentence what the pattern shown is typical of, for example that points this scattered usually indicate a weak relationship. Ten rounds in total, with a spread of strong positive, weak, near-zero, and negative relationships. Show a running average error across the rounds. At the end, show the average error over all ten and one line of advice based on whether the student tended to over-estimate or under-estimate strength. A "Start again" button resets everything and generates fresh plots.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Nursing and health sciences Repeated practice

Dose Check

A dosage-calculation drill where a wrong answer shows the harm it would have caused, before it happens to a real patient.

What students practise

Working a dosage calculation carefully, and seeing what carelessness costs.

Build prompt

Build a single-screen dosage-calculation drill for nursing students. Show one prescription scenario at a time: the drug, the dose ordered, the concentration available, and the patient weight where it matters. The student types the volume or number of tablets to administer into a single answer box and presses "Check". Ten scenarios in total, ordered from a simple single-step conversion to a weight-based paediatric calculation. Feedback appears immediately. If the answer is right, confirm it and show the working in three short lines so the student can compare their method. If it is wrong, do not just give the number: state what the correct answer is, show the same three-line working, and add one sentence naming the clinical consequence of the amount they entered, for example that it would have been roughly ten times the intended dose. Accept answers within a sensible rounding tolerance and say so. Show a running score. At the end, list every scenario answered incorrectly with its correct working. A "Start again" button resets the drill.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Accounting and business Sort into categories

Debit or Credit?

A rapid-fire sorter with a running streak, so classification becomes reflex instead of a lookup table.

What students practise

Classifying transactions fast enough that it stops being a lookup.

Build prompt

Build a single-screen rapid-fire practice app for introductory accounting students learning double-entry. Show one transaction description at a time, for example "Paid the monthly electricity bill in cash" or "A customer settled an invoice from last month". The student presses one of two large buttons: Debit or Credit, answering for the account named in the prompt. Twenty transactions in total, mixed across assets, liabilities, income and expenses. Feedback is immediate and brief, because speed is the point: on a correct answer show a tick and advance after half a second; on a wrong answer show the correct side, one short sentence of reasoning, and wait for the student to press "Next". Keep a visible running streak of consecutive correct answers, and show the best streak reached. At the end, show the final score, the best streak, and a list of every transaction answered incorrectly with its correct side and reasoning. A "Start again" button resets the score and the streak.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

World languages Beat the clock

Verb Sprint

A verb-conjugation duel against the clock, with instant correction instead of a red pen three days later.

What students practise

Producing the right conjugation under time pressure, not just recognising it.

Build prompt

Build a single-screen timed conjugation drill for language students. Pick one language and one tense and state both clearly at the top of the screen. Show an infinitive and a subject pronoun, for example "hablar / nosotros", and give the student a text box to type the conjugated form. A ninety-second countdown runs for the whole session. Each correct answer advances immediately and adds to the score; each wrong answer shows the correct form and a one-line note on the pattern it follows, then advances after the student presses "Next". Include at least twenty verbs, mixing regular verbs with the common irregulars, and draw them in a random order. Accept answers case-insensitively, and accept an unaccented answer but show the correctly accented form in the feedback. When the timer reaches zero, stop and show how many were answered correctly, and list every verb missed with its correct form. A "Start again" button resets the clock and reshuffles the order.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Chemistry and lab safety Find the error

Spot the hazard

A lab-safety simulation where the unsafe step has to be caught before anyone reaches for the wrong bottle.

What students practise

Noticing the unsafe step in a procedure that otherwise looks routine.

Build prompt

Build a single-screen lab-safety practice app for students about to start practical work. Show one short laboratory procedure at a time, written as four to six numbered steps, with exactly one step containing a safety problem: the wrong protective equipment, an incompatible storage choice, a missing fume hood, adding water to acid, an unlabelled container. The student clicks the step they believe is unsafe. Eight procedures in total, varying the kind of hazard. When the student clicks, say immediately whether they found it; either way, name the hazard, explain in one sentence what could happen, and give the correct version of that step. If they clicked a safe step, add one line explaining why that step is fine, so a wrong guess still teaches something. Show a running score. At the end, show the final score and list every procedure where the hazard was missed, with the hazard named. A "Start again" button resets the score and returns to the first procedure.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

History and social studies Choose a response

Turning point

A branching negotiation at a historical turning point, where every choice visibly changes what happens next.

What students practise

Weighing the pressures on a historical decision instead of judging it with hindsight.

Build prompt

Build a single-screen branching scenario that puts the student inside one historical negotiation. Open with three short paragraphs setting the date, who the student is, what they want, and what the other side wants. Then present a sequence of four decisions, one at a time, each with three defensible options and no obviously correct answer. After each choice, show two things: what happened next as a result, and one short paragraph on the real historical pressure that made that option attractive or costly at the time. The next decision follows from the choice made, so the path differs between runs. After the fourth decision, show an ending that reflects the accumulated choices, then a short debrief comparing the path taken with what actually happened historically, and note where the student diverged and why that mattered. A "Start again" button returns to the opening and clears the path so a different route can be tried.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Math Repeated practice

Fraction boss battle

A boss-battle style drill where each correct fraction problem lands a hit, and each mistake costs you a turn.

What students practise

Adding, subtracting and simplifying fractions without stalling on the denominator.

Build prompt

Build a single-screen fraction practice app framed as a battle. The student and an opponent each start with a health bar. Show one fraction problem at a time — adding, subtracting, or simplifying, with unlike denominators from the third problem onward — and give the student a text box for the answer in the form a/b. A correct answer removes a chunk of the opponent health bar and shows the working in two short lines. A wrong answer removes a chunk of the student health bar, shows the correct answer with the same two-line working, and names the specific slip, for example adding the denominators or forgetting to simplify. Twelve problems in total, increasing in difficulty. Accept an unsimplified but mathematically correct answer, and say in the feedback that it is right but not yet in simplest form. The battle ends when a health bar empties or the problems run out; show the outcome, the number answered correctly, and every problem missed with its working. A "Start again" button resets both health bars.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Corporate and compliance training Choose a response

Report it

A decision-tree scenario for reporting a workplace incident, with consequences that play out differently by choice.

What students practise

Knowing who to tell, in what order, and what not to do first.

Build prompt

Build a single-screen branching scenario for workplace compliance training. Open with a short situation: the student has witnessed something that may need reporting, described in a way that is genuinely ambiguous rather than obviously wrong. Present four decisions in sequence, one at a time, each with three plausible options covering who to tell, how soon, what to write down, and what to say to the person involved. After each choice, show what happens as a result and one short paragraph on the policy reasoning behind it, including why a defensible-sounding option can still be the wrong first move. The next decision follows from the choice made. After the fourth, show how the situation resolved, then a debrief listing the decision points, what the student chose, and what a careful reporter would have done at each. Keep the tone instructive rather than punishing — a wrong path should read as a lesson, not a verdict. A "Start again" button clears the path and returns to the opening.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Biology and ecology Change one thing, see what happens

Tipping point

A simulator where students nudge one variable in an ecosystem and watch the population curves respond in real time.

What students practise

Seeing that one change ripples through a system on a delay.

Build prompt

Build a single-screen ecosystem simulator with three populations — a plant, a herbivore, and a predator. Draw all three as line graphs on shared axes, with time running along the bottom, and run the simulation continuously so the curves move. Give the student three sliders: rainfall, hunting pressure on the predator, and initial herbivore population. Changing a slider changes the curves from that moment on, without resetting the history, so the effect of the change is visible against what came before. Below the graph, show a one-sentence plain-language reading of the current state that updates as it changes, for example that the herbivore population is climbing because predator numbers fell two cycles ago. Include a short panel naming three things worth trying and what to watch for in each. If any population collapses to zero, say so clearly and explain in one sentence what caused it. A "Start again" button resets all sliders and clears the graph.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

EMS and paramedic training Beat the clock

Triage under pressure

A timed triage scenario — multiple patients, one responder, and a scoreboard that rewards the right priority order.

What students practise

Ordering casualties by urgency when there is no time to treat everyone at once.

Build prompt

Build a single-screen triage practice app. Present a scene with six casualties, each shown as a short card with age, mechanism of injury, breathing, circulation, and responsiveness. A three-minute countdown runs for the whole scene. The student assigns each casualty one of four triage categories by pressing a button on that card. Assignments can be changed until the student presses "Confirm scene" or the timer runs out. When the scene ends, reveal the correct category for each casualty, and for every one the student got wrong, give a one-sentence explanation anchored to the specific finding that determines the category — the respiratory rate, the capacity to walk, the absence of a radial pulse. Score the scene on how many were categorised correctly, and separately flag any casualty under-triaged, since that is the error that matters clinically. Show the final score and the corrected scene together. A "Start again" button generates the same scene with the casualties in a different order.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Ethics, law and professional practice Choose a response

What would you do?

One short workplace dilemma, three plausible responses, and the principle behind whichever one you pick.

What students practise

Naming the principle a decision turns on, not just picking the nice option.

Build prompt

Build a single-screen ethics discussion starter. Show one short workplace dilemma at a time — six sentences at most — in a field where the right answer is genuinely contested. Offer three responses, each defensible, with no obviously correct option. Whatever the student picks, do not mark it right or wrong. Instead show three things: the likely consequence of that choice, the ethical principle it prioritises, and the principle it trades away. Then show what the other two options would have prioritised, so the student sees the full trade-off rather than only their own path. Six dilemmas in total, varying which principles are in tension — honesty against loyalty, individual against collective, short-term harm against long-term good. At the end, show which principles the student consistently favoured across all six, stated as an observation rather than a judgement. A "Start again" button returns to the first dilemma. This is designed for the opening five minutes of a seminar, so keep every screen short enough to read aloud.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Engineering and physics Match pairs

Formula match

Pair each quantity with the formula that produces it, against a shrinking board.

What students practise

Recognising which relationship applies before reaching for the formula sheet.

Build prompt

Build a single-screen matching drill. Show two columns: on the left, ten physical quantities or situations described in words, for example "the energy stored in a stretched spring"; on the right, ten formulas in shuffled order. The student clicks one item from each column to pair them. A correct pair locks in place, greys out, and shows a one-sentence note on when that relationship applies and what its units are. An incorrect pair flashes briefly, separates again, and shows one line on why those two do not go together — usually that the units do not work out. Both items return to the board so the pair can be tried again. Keep a count of incorrect attempts rather than a timer, so the pressure is on accuracy. When all ten are matched, show the number of incorrect attempts made and list the pairs that took more than one try. A "Start again" button reshuffles the right-hand column and clears the board.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Study skills and exam prep Reveal and answer

Mystery box review

A grid of hidden questions, uncovered one at a time, for the last class before an exam.

What students practise

Retrieving material cold, in the order the class picks rather than the order it was taught.

Build prompt

Build a single-screen revision game for the last class before an exam. Show a grid of twelve numbered boxes. Clicking a box flips it to reveal one short revision question, and the box cannot be chosen again. The student, or the class, answers out loud, then presses "Show answer" to reveal a model answer of two or three sentences, followed by "Next" to return to the grid. Write the twelve questions to span recall, application, and one deliberately harder synthesis question, and mark each revealed box with its type once opened so the spread is visible as the grid empties. Keep a simple count of boxes opened out of twelve. When the last box is opened, show a summary listing all twelve questions with their answers, so the whole set can be read back or screenshotted at the end of class. A "Start again" button resets the grid and shuffles which question sits behind which number.

Keep it to one screen, with no menus, tabs, or other pages to navigate to. Everything the app needs, including the questions, examples, answers, and feedback, must be built into the app itself. No sign-ins or student accounts, nothing saved after the page is closed, no connections to other websites or services, no AI running while students use it, and nothing that costs money. It should work on a phone as well as a laptop, be easy to read, and easy to reset and start again.

Build exactly what is described above and nothing else. Do not add extra features, screens, settings, or options, however useful they might seem. If something is unclear, choose the simplest version of it rather than the more capable one.

Not on the list?

If you can describe the moment your students get stuck, you can build a tool for it. Part 1 walks you from that description to a working app on a live URL, and it is free.

Start Part 1