How to build an AI language tutor for your business with OpenAI Codex (no coding required)

Rule of thumb: if you want to learn a language yourself, do not build this. Any row above teaches you more for less than the weeks below cost, and a curriculum written by people beats a generated deck for a beginner. If you teach, run a school, train staff or want a product of your own, the seat is the bill, and a tutor on your own key turns a price per learner into cents per lesson. The honest middle case is a tutor for beginners in a language you do not speak yourself, and there the right answer is to build it and have a native speaker check what the model generates before learners see it.

* On this template the free-tier line to watch is the pause rather than storage. Nothing large is stored, because conversations are not saved and no files are kept, so a learner is a few rows of text. What bites is that a free project sleeps after a week without activity, and a tutor people open when they have ten spare minutes is exactly the sort that goes quiet. Pro, from $25/mo, ends the pause and keeps a daily backup for 7 days.

Prices and rates from supabase.com, developex.com and learn.chatgpt.com, checked September 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   Write AGENTS.md before anything is scaffolded

   Codex loads AGENTS.md at the start of every task, so the two rules that matter most on this build (the key never reaches the browser, every call is capped) are loaded before any code exists to break them.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind and the Supabase JS client, and this project is an AI language tutor. Fix the vocabulary (learners, target language, activities, streaks) and record two standing constraints: every call to the AI provider goes through a server-side function with the key in its secrets and a per-learner limit checked before the provider is contacted, and the browser never holds the key or decides the limit. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore.

   The two constraints are the ones worth writing down. Calling the provider from the browser and skipping the limit "for now" are both reasonable-sounding shortcuts, and both cost real money the first time a learner is generous with their practice.

2. 02

   Have Codex build the tutor and the ceiling in one task

   One function, one corrected reply, and the log and the limit built in from the first call. Read the prompt Codex writes for the model as carefully as the code, because that prompt is the product.

   PromptBuild the tutor function and the ceilingCopy

   Create a Supabase edge function called chat-assistant that calls my AI provider with the key held in function secrets. It takes the learner’s message, their target and native languages and the last ten turns, and asks the model to reply in the target language at the learner’s level and then, in the native language, to point out up to three mistakes and their fixes without rewriting the whole message. Before contacting the provider it writes a row to a calls table (learner, activity, model, tokens in and out, cost estimate) and checks that learner’s calls today against a limit read from a settings table, returning a friendly limit message when it is hit. Build one plain chat page that renders the reply as formatted text, with a placeholder learner id for now. Show me the system prompt you wrote before you run anything.

   Asking to see the system prompt first is worth the round trip. Whether the tutor teaches or rewrites is decided in that text, and it is far cheaper to argue with a paragraph than with a running function.

3. 03

   Have Codex write the schema, and read the SQL before it runs

   The data model is small and the rule is simple, which is exactly why it is worth reading rather than approving on trust. Everything later reads these tables.

   PromptWrite the data modelCopy

   Write the migrations for this app and show me the SQL before running it. A profiles table with the learner’s native and target languages, created by a trigger on sign-up. An activity_completions table recording each completed activity with its type and the learner’s local day. A user_streaks table with the current and longest streak per activity. A calls table and a settings table for the ceiling from step 02. Design every table with an owner column so the access rules in the next task are one line each.

   Reading the SQL here costs ten minutes. Finding a streak that was saved against the wrong learner costs a support conversation.

4. 04

   Narrow permissions, then add sign-in and the access rules

   This task touches authentication, which is exactly the kind of change worth scoping Codex down for rather than leaving whatever settings you use for routine edits.

   PromptAdd auth and access rulesCopy

   This task touches authentication, so narrow your permissions to just this one. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session and a useUser hook, and connect the profiles trigger. Enable row-level security on every table so a learner reaches only their own rows, with explicit WITH CHECK clauses on insert and update. Make every edge function, including the ones that only record activity or change settings, refuse a caller without a valid session at the gate rather than inside the function. Show me how to verify a second learner gets nothing back for the first learner’s rows.

   There are no roles here, which is right for a personal tutor. One ownership rule, watertight, beats three rules with a gap.

5. 05

   Give the dashboard its own task, and the drills the next one

   The dashboard is the screen learners live in and the drills are four more functions behind it. Keep them as two tasks so each change is small enough to read.

   PromptBuild the dashboardCopy

   Build the learning dashboard as one page with a language picker and four tabs (Chat Practice, Flashcards, Quick Exercises, Dictionary), wire the Chat tab to the function from step 02 with the real learner id, and put my name and colours on it. Leave the other three tabs as empty states that say what they will do. Walk me through the component structure before you build it.

   PromptBuild the drills and the dictionaryCopy

   Add four more edge functions, each through the same key, the same sign-in check and the same per-learner ceiling as the chat. A get-flashcards function that generates a set of vocabulary cards for the target language and a chosen difficulty. A generate-exercise-sentence function that returns a fill-in-the-blank sentence at a chosen difficulty with its answer. A get-word-meaning function and a translate-text function. Wire them to their tabs: cards that flip and read the word aloud with the browser’s own speech synthesis, exercises checked as the learner types, and a dictionary with one tap to swap the two languages.

   Say "the same ceiling" out loud in the prompt. Four functions with four separate limits is the version of this that looks finished until the bill arrives.

6. 06
   Destination

   Hand streaks, settings and demo mode to a cloud run, then test it yourself

   Streaks, settings and the demo shell are self-contained and well specified, a reasonable set to hand to a cloud run while you do something else, provided you read the change before it merges.

   PromptAdd streaks, settings, demo, and testCopy

   Three remaining pieces. Streaks: an activity-completed function that records a completed activity for the signed-in learner and extends, resets or keeps that activity’s streak using the learner’s local day, a get-streaks function, counters on the dashboard, and a history page with a week view and charts. Settings: the learner’s languages, a password change and a usage panel showing calls and estimated cost this period. Demo mode: a visitor who continues without an account sees the dashboard shell with sample content and no function accepts a call from them. When they are in, run the app and take it end to end yourself: open the demo signed out and confirm nothing calls the provider, sign up, hold a ten-turn conversation with mistakes in it, drill cards and an exercise, check the streaks moved, hit the daily limit on purpose and read what a learner sees, and fix whatever does not hold up.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks everything above it: your database service key and your AI provider key belong on the server only, never in the app a learner downloads and never in a repository. If either escapes, treat it as compromised, check your provider’s usage page for what was spent with it, and replace it the same day.

Choose on two things, neither of them speed. First, whether the plan permits commercial use, because Vercel’s Hobby tier does not and a tutor with paying learners is a business. Second, whether a bookmarked link to the streak page opens the app for a learner arriving cold, because their own progress is the page they bookmark. The tutor itself never touches the host: every reply comes from your database’s functions, and the host serves one small static folder.

Add a calls table that records every model call (which learner, which activity, which model, how many tokens went in and came back, whether it succeeded, and a cost estimate) and write to it from every function that calls the provider, successful or not. Then add a ceiling: a limit per learner per day and a total across the whole app, both settings I can change without a deploy, checked inside the function before it contacts the provider and returning a friendly "you have reached today’s practice limit" rather than an error. Do not let the client send the limit or the cost, because both are read on the server. Then add a small usage panel in settings showing calls and estimated spend for the current period.

Add a microphone button to the chat and the exercises that uses the browser’s speech recognition to turn what the learner says in the target language into text, shows the transcript for them to correct before it is sent, and falls back to the text box in browsers that do not support recognition for that language. Then extend the tutor prompt so that when a message arrived by voice, the reply also comments briefly on any word the transcript suggests was mispronounced, without turning the lesson into a pronunciation drill.

Add a five-exchange placement conversation for a new learner in their target language, send the transcript to the ai function and ask for a level on a simple scale with a one-line reason, store it on the profile, and use it as the default difficulty for flashcards and exercises. Re-evaluate every twenty completed activities and tell the learner when their level changes, letting them override it.

Save every generated flashcard and exercise to the learner’s account with whether they got it right, then add a "Review" tab that schedules cards with spaced repetition: the ones they missed come back tomorrow, the ones they knew come back in a week, then a month. Ask the ai function to generate a fresh example sentence for each card on its review day so the same word is met in a new context, and show the learner how many cards are due today on the dashboard.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.