How to Build a Language School Website Without Code

A language school website sells one thing before it sells courses: the trial lesson. In Zugo you describe the levels, the schedule, the teachers, and the booking form in plain text, get a sandbox-checked build in about a minute, then refine it by chat and publish it to a live address in one click.

What follows is the specific version of that: which blocks convert a browsing parent or adult learner, a prompt you can copy, how to wire booking and payments, what it costs in credits, and where this approach runs out.

What does a language school site need that a generic site does not?

Three things, and none of them are on a standard business template. A level structure that a visitor can locate themselves in. A schedule with group times and formats. And a booking path that ends in a specific trial lesson slot, not a generic contact form.

Level structure is the one people skip. A visitor who does not know whether they are A2 or B1 will not choose a course, they will close the tab. Naming levels with plain descriptions solves it: "you can order coffee and ask directions" is more useful than "A2" on its own.

Format matters as much as level. Group of six, one to one, online, in person, intensive, and kids versus adults are different products with different prices, and a visitor filters on format before anything else. If your school runs both children's and adult programs, they usually deserve separate pages rather than one long page trying to speak to both audiences at once.

What should the prompt say?

Write the prompt as a list of blocks in reading order. The first build follows it closely, and specifics about levels and formats matter more than adjectives about quality.

Build a site for a language school, [name], teaching [languages] in [city].
Pages:
1. Home: hero with languages taught, "Book a free trial lesson" button,
   3 format cards (group, one-to-one, online), 4 teacher cards, 3 reviews.
2. Courses: table of levels A1 to C1, each with a plain-language description
   of what the student can do, hours per week, group size, price per month.
3. Teachers: photo placeholder, languages, qualifications, one-line bio.
4. Schedule: weekly grid of group times by level and format.
5. Trial booking: name, email, phone, language, self-assessed level,
   preferred time, "how did you hear about us".
Tone: warm, concrete, no stock phrases about "immersive experiences".

If starting from a blank prompt feels heavy, Zugo ships 25 ready-made templates, five of them games and the rest sites and apps. Clone the closest one and rewrite it. The general flow is covered in the guide on making a website with AI; this page is the language school version.

How do you handle levels, a placement quiz, and the schedule?

A placement quiz is the highest value block on a language school site, and it is well within what an AI builder handles. Ten multiple choice questions, a score, and a level result with a link to the matching course. Ask for exactly that in a chat edit after the first build rather than cramming it into the initial prompt.

The quiz has a second job beyond placement: it collects an email in exchange for a result, which is a fairer trade than a naked newsletter box. Ask for the result to display on the page and to be emailed as well, so the visitor has a reason to give a real address.

The schedule is the block most likely to go stale. Two honest options: a static weekly grid you update by chat edit each term, or a database-backed schedule using Supabase, where you change a row instead of the page. Static is cheaper and fine for most schools. Choose the database only if the timetable really moves weekly.

How do students book and pay?

Booking and payment are two separate decisions and they cost different amounts of effort. For booking, the minimum that works is a form wired to email through the Resend connector, so a trial request reaches a human the same hour. Supabase adds a database and login when you want requests stored, assigned, and tracked.

Payments run through Stripe, which handles both one-off charges and subscriptions. That distinction matters for a school: a single intensive course is a one-time payment, while a monthly group is a subscription, and mixing them into one payment link causes billing problems later. The setup is walked through in the guide on taking Stripe payments.

If you want student accounts, materials behind a login, and progress visible per student, that is an application rather than a site, and Supabase is the part that makes it real. Build the marketing site first and add the student area as a second project once the school is actually selling.

What does it cost to build?

A language school site is usually a multi page build: home, courses, teachers, schedule, and booking. Hosting on a your-project.zugo.run address is included in the plan, and a custom domain connects on a paid plan once the school is live. Stripe, Supabase, and Resend bill on their own side with your own accounts, and each has a workable free tier at small volume.

Edits are the cheapest action, which is the number that matters for a school. Prices change once a term, the schedule changes more often, and both are chat edits rather than rebuilds.

Where does an AI builder fall short for a school?

Zugo does not replace a development team on a complex product. A full learning management system with assignments, grading, and cohort analytics is a real piece of software, and past a certain size you want an engineer or an off the shelf LMS.

Live video lessons are not something you build here either. Schools use Zoom, Meet, or a dedicated classroom tool, and the site links out to them. Trying to build video conferencing into a generated site is the wrong project.

Very specific logic arrives through edits rather than one prompt. Automatic slot allocation that checks teacher availability against a booked calendar is achievable, but through a sequence of edits with a database behind it. And the sandbox check confirms a build boots and renders before you see it, which lowers the risk of a broken page rather than eliminating it.

What is the fastest path to a live site?

1. Open Zugo and paste the prompt with your languages, levels, and city filled in.
2. Let the build finish. A single page takes about a minute, a multi page platform takes a few minutes, and the process log shows what is being written.
3. Edit by chat: "add a placement quiz with ten questions", "put prices on the course table", "make the schedule grid scroll on mobile".
4. Connect Resend for the booking form and Stripe if you sell courses online.
5. Publish, then attach your domain. If you want the code, one click exports the project to GitHub and it belongs to you.

Schools that publish a rough site this week and fix it as students ask questions do better than schools that wait for a perfect one. The neighbouring builds in this cluster share the shape: a membership site is the same idea with content behind a login. Start on free credits at zugo.dev.