Build a Music Teacher Website Without Code: Full Guide
A music teacher website without code takes one clear prompt: name the instruments you teach, the lesson formats and prices, and the action you want visitors to take. Zugo assembles the page in about a minute, boots it in a sandbox to check it opens, and publishes it to a live address you can put on a flyer.
This guide is narrow on purpose. It covers a private studio or an independent teacher, not a conservatory. Below: the pages that earn their place, the prompt to paste, how to take money for lesson packages, and the parts of running a studio that no builder handles for you.
What does a music teacher website actually need to do?
A studio site has one commercial job: turn a parent or an adult learner into a trial lesson request. Everything else is supporting evidence. If a visitor cannot tell within ten seconds which instruments you teach, at what level, and roughly what it costs, they close the tab and open the next teacher.
That reframes the build. You are not making a portfolio of your career. You are answering four questions in order: do you teach my instrument, do you teach someone my age, what does it cost, and how do I start. A site that answers those four in the first two screens outperforms a prettier one that buries them.
Zugo works from exactly that kind of description. You write what the studio is and who it serves in plain English, and the builder assembles a working site from it. Simple single-page builds land in about a minute. A multi-page site with a student area takes a few minutes, because there is more to assemble and more to verify.
Which pages belong on a private music studio site?
Six pages cover almost every independent teacher. Fewer is usually better than more: an empty "Blog" link hurts more than it helps.
| Page | What goes on it | Connector needed |
|---|---|---|
| Home | Instruments, ages taught, one line on your method, one button | None |
| Lessons and rates | Formats (30 / 45 / 60 minutes), in person vs online, package prices | Stripe if you sell packages up front |
| About | Training, performance history, who you have taught and for how long | None |
| Listen | Embedded recordings of you or, with permission, your students | None |
| Request a lesson | Short form: name, instrument, age, preferred days | Resend, so the form reaches your inbox |
| Student area | Practice notes, sheet music links, recordings behind a login | Supabase for the database and login |
The student area is the only piece that turns a site into an application. Skip it for version one. Publish the five public pages, get the first requests arriving, and add the login later as an edit rather than delaying launch for it.
What should the prompt look like?
Vague prompts produce generic sites. The fix is specificity about the things only you know: instruments, ages, format, price, and location. Here is a template that holds all of it.
Build a website for a private music teacher.
Instruments: [piano, classical guitar].
Students: [children 6-14 and adult beginners].
Format: [in person in Lisbon, plus online lessons over video].
Pages: home, lessons and rates, about, listen, request a lesson.
Rates: [45 min trial 20 EUR, single 60 min lesson 45 EUR,
package of 8 lessons 320 EUR].
Home page: instruments and ages in the first screen, one button
"Book a trial lesson".
Request form fields: name, email, instrument, student age, preferred days.
Tone: warm, plain language, no music-school jargon.
Two details in that template do most of the work. Naming the ages filters out the wrong enquiries before they cost you a reply. Naming the trial lesson gives the page a single low-commitment action, which converts better than "Contact me".
If starting from a blank field feels slow, Zugo ships 25 templates, and several service and portfolio layouts are close enough to a studio site to rewrite in text. The template guide walks through what each one is shaped for.
How do you take payment for lesson packages?
Connect Stripe and the generated site can charge for real. Paste your publishable and secret keys into the Stripe connector, then describe what you sell: a single lesson, an eight-lesson package, or a monthly subscription for a weekly slot. The checkout runs on Stripe's hosted page, so card details never touch your site, and the money lands in your Stripe account rather than passing through Zugo.
For a teaching studio, prepaid packages are the usual reason to bother. A parent who has paid for eight lessons cancels far less often than one paying week to week, and a "Buy 8 lessons" button removes the awkward monthly reminder. Monthly subscriptions work the same way through Stripe's recurring billing.
What Stripe does not decide for you: your refund policy for missed lessons, your tax registration, or whether you should take money before the trial. Those are business questions, and they stay yours. The mechanics of the connector, test keys and all, are covered in adding Stripe payments to an AI-built app.
Where do lesson requests go after someone hits send?
A form that renders but sends nowhere is the most common failure in a first build, and it is silent. Connect Resend and every submission arrives as an email in your inbox. If you also want a record you can sort and search, Supabase stores submissions in a table you own.
Pick one before you publish, then test it yourself from a phone. Send a fake request, wait for the email, and only then hand the link to anyone. The general pattern, including what to do when the email lands in spam, is in the guide to contact forms on AI-built sites.
Zugo boots every build in a sandbox before handing it over, and a build that fails to open is reported as a failure instead of being delivered. That lowers the odds of a blank page, it does not remove them, and it says nothing about whether your form is wired to the right address. Check that part yourself.
What does it cost to build and keep online?
Pricing is per action rather than per site. An edit costs 3 credits, a build 6, and a multi-page platform 12 for the first three pages plus 3 for each page after that. The Free plan includes 5 credits, Pro is $25 a month for 200 credits, and Business is $99 a month.
Run that arithmetic before you start. One build plus a normal round of edits already exceeds what Free carries, so a studio site you intend to publish and keep adjusting realistically lives on Pro. Publishing puts the site at your-slug.zugo.run, and you can connect your own domain when you want the address on a business card to be yours.
What will an AI builder not do for a music studio?
Four honest limits, so you do not spend an evening finding them yourself.
Real scheduling. Zugo's connectors cover database, payments, email, analytics, deployment, and domains. A calendar that knows which Tuesday slots are already taken is not among them. Most independent teachers are fine with a request form plus their own calendar, but if you run six teachers across two rooms, keep your booking tool and link to it from the site.
Video lessons. The site can explain that you teach online and link to your meeting room. It does not host or stream the lesson.
Anything unusual, in one prompt. Very specific logic, for example a credit system where a student's missed lesson rolls into next month under conditions, gets there through a series of edits rather than a single sentence. That is normal, and it is how the tool is meant to be used, but it takes more than one round.
A development team. For a genuinely complex product, an AI builder is not a substitute for engineers. A teaching studio site is not that product, which is why this approach fits it well.
Where to start this week
Write the five public pages first, publish, and put the link in your local parents' group and on your profile wherever students already find you. Add the student area only when someone asks for it. If you want to see how the same prompt-first workflow applies to a different service business, building an online store without code covers the version with a catalogue and a checkout.
The code stays yours either way: Zugo exports to GitHub as a normal repository, so a developer can pick it up later without a migration. When you are ready to write the first prompt, start at zugo.dev.