How to build an AI language tutor for your business with Claude Code (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 claude.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 Claude Code runs the commands.

1. 01

   Set up the project

   An empty app running against your own database, plus a notes file so Claude Code keeps the two rules this build depends on in front of it.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and the vocabulary for a language tutor (learners, target language, activities, streaks) and recording two standing rules: every call to the AI provider goes through a server-side function with the key in its secrets and a per-learner limit checked first, and the browser never holds the key or decides the limit.

   Write the limit rule down now. A function that calls the provider directly from the browser is the first thing any assistant will reasonably suggest, and it would put your key in every learner’s hands.

2. 02

   Get the tutor answering, with the ceiling in the same step

   One server-side function, one corrected reply, and the log and the limit built in from the first call. No accounts yet, so use a placeholder learner id and a small limit while you test.

   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, never in the browser. It takes the learner’s message, their target language, their native language and the last ten turns of the conversation, and asks the model to reply in the target language at the learner’s level, then, in the native language, to point out up to three mistakes in what they wrote and how to fix them, without rewriting the whole message. Before it calls the provider it must write a row to a calls table (learner, activity, model, tokens in and out, cost estimate) and check that learner’s calls today against a limit read from a settings table, returning a friendly "you have reached today’s practice limit" when it is hit. Then build one simple chat page that shows the conversation and renders the reply as formatted text. Use a placeholder learner id for now.

   Test it with a sentence that has a real mistake in it, in a language you know. A reply that quietly rewrites the sentence is a chatbot. A reply that says what was wrong and why is a tutor, and the prompt is where the difference lives.

3. 03

   Add accounts, the data model and the rules that keep them apart

   Now the ordinary application work. Sign-in, a profile per learner with their languages, the activity and streak tables, and access rules so one learner’s progress is theirs alone.

   PromptAdd auth, tables and access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a profiles row per learner created by a trigger on sign-up with their native and target languages, and a useUser hook. Then the data model as migrations. An activity_completions table recording each completed activity with its type and the day. A user_streaks table holding the current and longest streak per activity. Wire the calls and settings tables from step 02 to the real learner id. Enable row-level security on every table so a learner reaches only their own rows, with explicit WITH CHECK clauses on insert and update, and make every function, including the ones that only record activity, refuse a caller without a valid session at the gate. Show me how to verify a second learner gets nothing back for the first learner’s rows.

   There are no roles here, and that is right for a personal tutor. Ownership is one rule, which is exactly why it should be watertight.

4. 04

   Build the dashboard, the drills and the dictionary

   The screen learners live in. Four tabs on one dashboard, each behind its own function, all through the same ceiling.

   PromptBuild the dashboard and the drillsCopy

   Build the learning dashboard as one page with four tabs and a language picker at the top. Chat Practice uses the function from step 02. Flashcards calls a get-flashcards function that generates a set of vocabulary cards for the target language and a chosen difficulty, flips to reveal the meaning, and reads the word aloud with the browser’s own speech synthesis. Quick Exercises calls a generate-exercise-sentence function for fill-in-the-blank sentences at a chosen difficulty and checks the answer as the learner types. Dictionary calls get-word-meaning for a definition and translate-text for a phrase, with one tap to swap the two languages. Every function goes through the same key, the same sign-in check and the same per-learner ceiling as the chat. Put my name and colours on it.

   Ask that every function share the ceiling explicitly. Four functions with four separate limits is the version of this that looks finished until the bill arrives.

5. 05

   Add streaks and the history page

   The feature that brings learners back tomorrow, and the one that makes them angry when it miscounts. Decide the rule before it is written.

   PromptAdd streaks and historyCopy

   Add an activity-completed function that records a completed activity for the signed-in learner and updates that activity’s streak: consecutive days extend it, a missed day resets it, and the longest streak is kept. Treat a day as the learner’s local day, sent from the browser and validated on the server. Add a get-streaks function and show the four streaks as counters on the dashboard, then build a streak history page with a week view and charts of completions per day and per activity. Explain to me exactly when a streak breaks, so I can write it in the app’s help text.

   The time-zone question is the one to settle here. A learner in Tokyo whose streak resets at midnight in your city will stop trusting the number, and then the feature is worth nothing.

6. 06
   Destination

   Add settings and demo mode, then use it as a stranger would

   Finish with the pieces around the lesson, then open a private window and try to spend your key without an account.

   PromptAdd settings, demo, and testCopy

   Add a settings page for the learner’s languages and a password change, each through a function that checks the caller. Add a demo mode: a visitor who continues without an account sees the dashboard shell with sample content and clear prompts to sign up, and none of the functions accept a call from them. Add a usage panel in settings showing the learner’s calls and estimated cost this period. Then run the app and walk me through the whole thing: open the demo signed out and confirm nothing calls the provider, sign up, hold a ten-turn conversation with mistakes in it, drill a set of cards and an exercise, look a word up, check the streaks moved, then hit the daily limit on purpose and read what the app says, and fix whatever breaks on the way.

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 picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.