How to Build a Band Website Without Code, Step by Step
A band website without code starts as a description: who you are, what you sound like, where you play next. Zugo turns that text into a working site, boots it in a sandbox before handing it over, and publishes it to a live address you can put in every bio link. A single-page site is one build.
The reason to own a site at all, when your audience already lives on streaming and social platforms, is that those platforms decide what your page looks like and who sees it. A domain you control is the only address that survives a platform changing its mind.
What does a band website actually need?
Five blocks cover almost every working band. A hero with the name, the genre in one line, and the next date. A tour list with venues, cities, and ticket links. A music block with your streaming and video embeds. A short about section written for promoters and press, not for fans. Contact details split into booking and press, because those are different inboxes.
The tour list is the one that earns its place. Most visits to a band site are somebody checking whether you are playing near them, and every second spent hunting for that is a ticket not bought. Put the next date in the hero and the full list one click away.
The about section is worth writing twice. Fans want the story. A promoter wants the facts: how many people you draw, what you need on stage, who to email. Give the second version its own short block and you will get replies faster.
What should the prompt say?
Zugo builds from a description, so the description carries everything a designer would ask you in a first call. This template holds the parts a band actually needs:
Build a website for a [genre] band from [city].
Sections:
1. Hero: band name, one-line description of the sound,
next show with date and city, button "Tickets".
2. Shows: a list of upcoming dates with date, venue,
city, and a ticket link. Past shows collapsed below.
3. Listen: blocks where I paste embed codes from
streaming and video platforms, plus a short note per release.
4. About: two paragraphs for fans, then a short press
block with facts, a photo, and a downloadable bio.
5. Contact: booking email, press email, socials.
Tone: [restrained / loud]. Palette: [your colours].
One line is worth adding if you sell anything: "add a merch section with items, photos, prices, and a buy button." Another if you tour often: "make the shows list easy to edit as a table."
If starting from a blank field feels harder than starting from something, Zugo ships 25 ready-made templates, and a portfolio or landing starting point is closer to a band page than an empty prompt. The same prompt principles are covered in the guide on building a portfolio website with AI.
How do you handle music, video, and merch?
These three come from three different places, and mixing them up is the usual reason a band site takes a weekend instead of an evening.
| What you want | How it gets there | What to know |
|---|---|---|
| Streaming and video players | Embed snippets from the platform, pasted into a block on the page | Zugo has no dedicated connector for music platforms, so ask for a block and paste the code the platform gives you |
| Selling merch or tickets direct | Stripe for one-off payments | Real checkout, real card handling, on your own site |
| Mailing list signups | Resend delivers the message, Supabase stores the address | A form with nothing behind it collects nothing |
| Press kit downloads | Files hosted with the site, or Supabase storage | Keep a high-resolution photo and a plain-text bio in one place |
The mailing list distinction is the one bands get wrong most often. Resend sends email, so it can tell you a signup happened and confirm it to the fan. Storing the growing list of addresses is a database job, which is what Supabase is for. Build only the delivery half and you will discover, six months later, that you have no list. The newsletter signup guide covers that pairing in more depth.
How do you keep tour dates current without a rebuild?
Ask for the shows list as a table with editable rows, then change it with plain-text edits: "add 14 November, The Cluny, Newcastle, tickets at this link" or "move the Bristol date to the past shows list." An edit costs 3 credits, so a touring band updating dates twice a month is spending very little.
Two habits keep the page honest. Move sold-out shows to a clearly marked state rather than deleting them, because a sold-out list is proof you draw a crowd. Keep past shows visible but collapsed, since a promoter reading your page wants evidence you have played before, and an empty archive reads as a first gig.
What the site will not do on its own is pull dates from a ticketing platform automatically. That is a feed integration, which is a developer's job. For most bands the manual edit is faster than the setup would be.
What does it cost to build and keep online?
Zugo bills in credits per action. A site build costs 6 credits. An edit costs 3. A multi-page platform costs 12 credits plus 3 for each page past the first three, which is the bracket you reach only if you add accounts or a real store with a database behind it.
The Free plan gives 5 credits, which is enough to look around, and one build costs 6, so a real band site starts on Pro at $25 per month with 200 credits. Business is $99 per month. Hosting for the published site is included. Hi-Fi mode, which spends more effort on the visual pass, doubles both numbers: 12 for a build and 6 for an edit.
For a band splitting costs four ways, the comparison worth making is not against a web designer's quote. It is against the year you spend without a site because nobody in the band had a free weekend.
How do you publish it on your own domain?
Publishing is one action, and the site goes live at an address like yourband.zugo.run. Connect your own domain before you print it on anything, because the domain is the part of your online presence you keep when a social platform changes its rules. The setup is DNS records and nothing more.
Add Google Analytics at the same time. For a band the useful number is narrow: how many people click a ticket link, and from which city. That tells you where to route the next tour, and it is information no streaming dashboard gives you in the same shape.
If you outgrow the builder, GitHub export hands you the actual repository. The site is yours, so a friend who codes can pick it up from working files rather than starting again. Bands change members and change managers, and a site nobody can access is a site that quietly dies.
How do you know the build actually works?
Zugo boots every build in a sandbox before showing it to you, and a build that failed to load is reported as a failure rather than handed over as a blank page. That lowers the risk of shipping something obviously broken. It does not replace your own checking, because "the page rendered" and "the ticket link goes to the right show" are different claims.
Test four things by hand on a phone. Every ticket link. Every embed, since a broken player is the fastest way to lose a first-time listener. The booking email address. The mailing list form, submitted with your own address, checked end to end.
Do that on mobile data rather than on the venue wifi. Most people who open your site are standing somewhere with two bars of signal, deciding in a few seconds whether to buy a ticket, and a page full of heavy photographs behaves very differently there than it does on a laptop at home.
Where does an AI builder stop for a band?
Three honest limits.
There is no music-platform connector. Streaming numbers, release feeds, and automatic tour syncing are integrations, not prompts. Embeds and manual edits cover the ground for almost every band below arena level.
Photography and artwork are still yours. The builder writes layout and copy. A band site lives on its images, and no generator supplies your press shots.
A full fan-account platform is a project. Logins, gated content, and a members area are buildable with Supabase behind the site, but you reach them through a sequence of edits rather than one description. Zugo does not replace a development team on something that complex.
Everything below that line fits comfortably: a fast, well-designed site with real dates, working players, and a merch link, built in an evening and edited from your phone between soundchecks. If you want to sell direct rather than through a platform, the Stripe payments guide covers the checkout side. When you are ready, start at zugo.dev and describe the band in a paragraph.