Cómo crear la web de una startup sin escribir código

Para crear la web de una startup sin escribir código, describe qué problema resuelves, para quién, cómo funciona el producto y qué quieres que haga el visitante. Un constructor con IA entrega la primera versión en torno a un minuto, y a partir de ahí iteras el mensaje escribiendo, que es exactamente lo que hace falta en las primeras semanas.

En una startup temprana la web no es un activo terminado, es un instrumento de medición. Cambia cada vez que aprendes algo de una llamada con un cliente, y su valor depende de con qué rapidez puedes cambiarla, no de lo bonita que quedó en el lanzamiento.

¿Qué tiene que hacer la web el primer mes?

Antes de hablar de secciones conviene fijar el trabajo. Una web de startup temprana casi siempre hace tres cosas y ninguna más, y confundirse aquí produce sitios preciosos que no sirven para decidir nada.

• Explicar qué haces en una frase. Si un visitante no lo entiende en cinco segundos, ninguna otra sección se lee. Esa frase se reescribe muchas veces, y por eso importa poder cambiarla en un minuto.
• Capturar interés. Lista de espera, demo o prueba. Un solo objetivo por página, porque dos botones compitiendo reparten la atención y ninguno gana.
• Dar señales de que existís. Nombres del equipo, forma de contacto, algo que demuestre que hay personas detrás. En negocios B2B esto pesa más de lo que parece.

Lo que no hace falta el primer mes: un blog, una página de prensa, un mapa de ruta público o traducciones a tres idiomas. Todo eso se añade después, cuando haya algo que atraiga a alguien a leerlo.

¿Qué escribir en el prompt?

El prompt tiene que llevar tu posicionamiento ya decidido. La IA maqueta y escribe código real, pero no sabe a qué segmento apuntas ni qué objeción bloquea la compra.

Crea la web de [nombre], un producto que ayuda a
[público] a [resultado concreto].
Una sola página: portada, problema, cómo funciona en tres
pasos, precios, preguntas frecuentes y contacto.
Portada: titular con el resultado, subtítulo con para quién
es, formulario de una línea para entrar en la lista de
espera y una captura del producto.
Cómo funciona: tres pasos numerados con un icono cada uno.
Precios: dos planes con lista de características.
Preguntas frecuentes: seis preguntas de objeción real.
Estilo: limpio, mucho espacio en blanco, un color de acento,
tipografía técnica, modo claro.

Fíjate en que el titular habla del resultado y no de la tecnología. "Cierra la contabilidad del mes en dos horas" convierte mejor que "plataforma impulsada por IA para automatizar procesos financieros", y esa diferencia se prueba cambiando una línea y mirando el número de registros.

¿Landing de una página o sitio de varias?

Es la primera decisión de coste y casi siempre se resuelve mal por exceso. Esta tabla compara los dos caminos con las cifras reales.

La recomendación honesta para la mayoría: empieza por la landing. Si dentro de dos meses necesitas páginas por segmento, se añaden sobre el mismo proyecto. Publicar siete páginas que nadie visita el primer mes es gastar créditos en decorado.

¿Cómo se recogen los registros de la lista de espera?

Hay dos niveles y conviene elegir el que corresponde al momento. Con Resend conectado, cada registro te llega por correo y lo vas apuntando donde quieras. Es suficiente cuando esperas decenas de altas, no miles.

Cuando el volumen crece, o cuando quieres segmentar y contar, la lista se guarda en una base de datos con Supabase, que también aporta el inicio de sesión si más adelante das acceso a un panel. Ese cambio no exige rehacer la web: se pide como una edición sobre el mismo proyecto.

Un aviso poco cómodo pero útil: una lista de espera de 800 correos no valida nada por sí sola. Lo que valida es cuántos de ellos responden a un mensaje pidiendo una llamada. Si la web es tu único instrumento de validación, estás midiendo curiosidad, no demanda.

¿Cuánto cuesta iterar cada semana?

El plan gratuito da 5 créditos, que sirven para entrar y mirar la herramienta por dentro; una landing cuesta 6, así que la cuenta hay que hacerla antes. Pro son 25 dólares al mes con 200 créditos y Business son 99 dólares al mes. Cada edición cuesta 3 créditos, así que un ritmo de cuatro o cinco cambios semanales cabe de sobra en el plan de pago más pequeño.

Cada construcción y cada edición se ejecutan en un entorno aislado antes de llegarte, y la que no abre no se entrega. En una startup eso importa por un motivo concreto: los cambios se hacen a las once de la noche antes de una demo, y el fallo aparecería justo cuando nadie va a mirarlo.

El sitio publicado vive en una dirección tipo tuproducto.zugo.run y admite dominio propio en cuanto lo tengas. Si el proyecto acaba pareciéndose más a una aplicación con usuarios y datos que a una web, ese camino está contado en la guía de cómo crear una app sin programar.

¿Y cuando lleguen los primeros pagos?

Cobrar desde la web se resuelve conectando Stripe al proyecto, tanto para pagos sueltos como para suscripciones. La parte técnica es la fácil.

La parte que conviene revisar antes es de negocio: comprueba que Stripe opere en tu país y que te sirva como pasarela, porque es el conector de pagos disponible. Si tu mercado depende de un método local que Stripe no cubre, mejor saberlo antes de construir la página de precios. El detalle está en la guía sobre conectar Stripe.

¿Cuándo hace falta un equipo de desarrollo?

Aquí está el límite y decirlo claro ahorra dinero. Un constructor con IA no sustituye a un equipo de desarrollo en un producto complejo, y confundir la web con el producto es un error caro.

La web pública y el producto son cosas distintas. Levantar la web de la startup con IA es una decisión sensata a cualquier escala. Construir con ella el núcleo de un producto con integraciones profundas, cumplimiento normativo y miles de usuarios simultáneos no lo es.

La lógica de negocio muy específica se afina con ediciones. Reglas de precios por tramos, permisos por rol o flujos de aprobación se pueden construir, pero llegan mediante varias ediciones sucesivas y con alguien técnico revisando el resultado, no con un solo prompt.

El código es tuyo, y eso es la salida. El proyecto se exporta a GitHub como un repositorio normal, así que cuando entre el primer programador no empieza de cero ni se queda encerrado en la herramienta.

Si tu producto es un servicio con usuarios que dependen de él, tarde o temprano querrás publicar una página de estado para los incidentes. Y si hoy lo único que necesitas es explicar la idea y recoger correos, el primer prompt se escribe en zugo.dev.