Cómo crear una web de profesor de música sin código
La web de un profesor de música sin código empieza con una descripción: qué instrumento enseñas, a quién, y qué pasa cuando alguien quiere una clase de prueba. Zugo construye el sitio a partir de ese texto, lo arranca en un sandbox para comprobar que abre y lo publica en una dirección real.
Lo difícil no es el sitio, es decidir a qué alumno te diriges. Lo que desaparece con un constructor es la semana de elegir plantilla, pelear con un calendario y configurar alojamiento antes de publicar la primera frase sobre tus clases.
¿Qué tiene que conseguir la web de un profesor de música?
Una sola cosa: que una persona concreta pida una clase de prueba. No demostrar tu currículo a otros músicos, no listar todo lo que sabes tocar. Un padre que busca piano para un niño de siete años y un adulto que quiere retomar la guitarra leen la misma página con expectativas opuestas.
Por eso la primera decisión es editorial, no visual. Elige el alumno que quieres tener más y colócalo arriba. Si das clase a niños por la tarde y a adultos por la noche, eso son dos audiencias y merecen dos bloques separados con llamadas a la acción distintas.
La segunda decisión es la prueba. Un profesor de música se elige por confianza, y la confianza se construye con material concreto: un audio o vídeo tuyo tocando, una explicación de cómo es una clase real, y qué pasa el primer día. Ese bloque vale más que cualquier lista de titulaciones.
¿Qué debe decir el prompt?
Nombra el instrumento, el alumno objetivo, el formato de la clase y la acción final. Un prompt vago produce una página genérica de servicios. Uno específico produce algo lo bastante cercano como para editarlo en lugar de discutir con ello.
Crea una web para un profesor de [instrumento] en [ciudad].
Secciones:
1. Portada: mi nombre, a quién enseño, si es presencial u online,
botón "Reservar clase de prueba".
2. Clases: [N] formatos con duración, nivel y precio por sesión.
3. Sobre mí: foto, formación, cómo es una clase conmigo.
4. Método: qué toca el alumno el primer mes, cada cuánto se practica.
5. Preguntas frecuentes: edad mínima, si hace falta instrumento propio,
política de cancelación, clases online.
6. Formulario: nombre, instrumento, nivel, horario preferido.
Tono cercano y claro. Sin jerga de conservatorio.
La línea de preguntas frecuentes es la que más trabajo te ahorra. Cancelaciones, instrumento propio y edad mínima son las tres consultas que llegan por mensaje una y otra vez, y responderlas en la página convierte conversaciones en reservas.
Si partir de cero se te hace cuesta arriba, Zugo incluye 25 plantillas listas y una de servicios profesionales suele estar más cerca de tu caso que una página en blanco.
¿Cómo gestionar la reserva de la primera clase?
Aquí es donde la mayoría de webs de profesores se complican de más. Un calendario con disponibilidad en vivo suena bien y casi nunca es lo que necesita alguien que da entre diez y veinte clases por semana.
| Forma de reservar | Qué conectas | Cuándo tiene sentido |
|---|---|---|
| Formulario de contacto | Resend, para que llegue a tu correo | La opción correcta para casi todos al empezar |
| Enlace a tu calendario externo | Nada, es un enlace | Ya usas una herramienta de citas y funciona |
| Agenda propia con horarios | Supabase detrás del sitio | Muchos alumnos y horarios fijos que cambian poco |
| Reserva con pago por adelantado | Stripe más formulario | Clases de prueba que te cancelan a menudo |
El formulario gana casi siempre al principio, porque la primera clase de música se acuerda hablando: hay que ajustar horario, nivel y si el alumno tiene instrumento. Si prefieres montar una agenda de verdad, la guía sobre webs de reservas entra en el detalle de esa versión.
¿Clase suelta, bono o cuota mensual?
La estructura de precios cambia la página entera, así que decídela antes de la primera construcción. Cada modelo pide un bloque distinto y atrae a un alumno distinto.
| Modelo | Qué muestras en la web | Efecto real |
|---|---|---|
| Clase suelta | Precio por sesión y duración | Entrada fácil, agenda inestable |
| Bono de sesiones | Paquetes con precio por clase | Menos huecos, cobro por adelantado |
| Cuota mensual | Precio al mes y clases incluidas | Ingresos previsibles, más compromiso |
| Prueba gratuita o reducida | Un solo botón destacado | Más contactos, más filtrado por tu parte |
Publicar precios reduce el número de mensajes y mejora su calidad. La consulta que pierdes al escribir la cifra la ibas a perder igual al responderla, solo que tres correos después. Para cobrar bonos o cuotas se conecta Stripe, y la guía de pagos con Stripe cubre el modo de pruebas y el primer cobro real.
¿Cuánto cuesta en créditos y cuánto tarda?
Zugo cobra por acción, así que puedes calcular el proyecto antes de empezar. Una web de profesor con portada, clases, método y formulario es una construcción normal de una página. Pasa a plataforma multipágina cuando añades área de alumnos con acceso.
| Acción | Créditos |
|---|---|
| Edición en el chat | 3 |
| Construcción de una página | 6 |
| Plataforma multipágina, primeras tres páginas | 12 |
| Cada página adicional | 3 |
| Edición en modo Hi-Fi | 6 |
| Construcción en modo Hi-Fi | 12 |
El plan Free da 5 créditos, suficientes para mirar, y una construcción cuesta 6, así que un sitio funcionando empieza en Pro por 25 dólares al mes con 200 créditos. Business cuesta 99 dólares al mes. El alojamiento del sitio publicado está incluido.
Una construcción simple tarda alrededor de un minuto, y una plataforma multipágina tarda varios minutos. Lo que realmente te llevará tiempo es grabar el vídeo tocando y escribir tu método, y ese trabajo existe con cualquier herramienta.
¿Cómo se publica en tu propio dominio?
Publicar es una acción y el sitio queda en una dirección del tipo tunombre.zugo.run. Sirve para enseñárselo a alguien, pero un profesor que cobra clases gana credibilidad con dominio propio, y conectarlo está soportado. La guía de dominio personalizado explica los registros DNS.
Añade Google Analytics el mismo día y vigila un solo número: cuántas personas que abren la sección de precios llegan al formulario. Esa proporción te dice si falla el precio o falla la petición, y cada cosa se arregla de forma distinta.
Si algún día el constructor se te queda corto, la exportación a GitHub te entrega el repositorio real. El proyecto es tuyo, así que un desarrollador puede continuar desde código que funciona en lugar de empezar de nuevo.
¿Dónde se detiene un constructor con IA en este caso?
Tres límites que conviene decir en voz alta antes de empezar.
No es un sistema de gestión de alumnos. Fichas, historial de progreso, control de asistencia y facturación recurrente son una aplicación con cuentas detrás. Se puede construir con Supabase a base de ediciones, pero es un proyecto, no un prompt.
El material didáctico sigue siendo tuyo. El constructor escribe estructura y textos. No graba tus vídeos, no digitaliza partituras y no sabe cómo enseñas.
La lógica muy específica se afina editando. Descuentos por hermanos, tarifas por desplazamiento o reglas de cancelación distintas por formato salen en varias ediciones, no en la primera respuesta.
Dentro de esos límites tienes una página rápida, clara y con una petición concreta, hecha en una tarde y editable con una frase cuando cambies de horario. Describe tus clases en un párrafo en zugo.dev y mira la primera construcción.