Cuatro clics para salir en vivo. Treinta segundos, de principio a fin. Una app respaldada por servidor en vivo por cuenta en el plan gratuito. Medio segundo de latencia extra en la primerísima solicitud que atiende un subdominio nuevo, y ninguna después. Tres de esos números son curiosidades — de las que asientes y olvidas al siguiente capítulo. El "uno", sin embargo, es el número que realmente cambia cómo deberías trabajar, así que ahí es donde quiero dedicar la mayor parte de este capítulo.
Por qué el límite es uno, no cero ni ilimitado
La mayoría de las herramientas sin código que permiten publicar un frontend gratis, o no tocan las apps respaldadas por servidor en absoluto, o las limitan tan agresivamente que "gratis" es solo un tecnicismo. Aquí, un build con cuentas, una base de datos o estado multijugador se publica a través del mismo botón Publicar que una página estática, y el lado del servidor se aloja y gestiona como parte de esa única acción — sin aprovisionamiento de base de datos por separado, sin variables de entorno que conectar, sin descubrir tres días después que el inicio de sesión funciona en vista previa y falla con un 500 en producción porque el backend nunca llegó a desplegarse. Eso es real, y por eso la gente se sorprende cuando choca con el límite: hasta ese punto todo parecía ilimitado.
No lo es. Tienes exactamente una app respaldada por servidor en vivo a la vez en el plan gratuito. Los builds estáticos no cuentan para ese límite — publica tantas páginas de marketing y portafolios como quieras, sin límite ahí. Pero el segundo build que necesite su propia base de datos o proceso persistente tiene que esperar su turno, completamente construido y disponible en vista previa, solo que no en vivo en su URL. Si estás prototipando tres ideas de SaaS en la misma semana, solo una consigue ocupar cómputo real; las otras dos son productos terminados sin dirección. Creo que la línea está trazada en un lugar razonable — un paquete estático apenas cuesta nada servirlo en el edge, un proceso de servidor activo sí cuesta — pero significa que la decisión de qué idea merece el espacio tiene que tomarse antes de pulsar Publicar, no después de haberte encariñado con tener dos en vivo a la vez.
Los cuatro clics, para que conste
- En la tarjeta del build, elige Publicar.
- Elige un slug — el tu-nombre en
yourname.buildmidas.com. Los slugs ya usados sugieren alternativas. - Confirma.
- Copia la URL desde la tarjeta, o encuéntrala más tarde en tu página Publicados.
Sin DNS, sin cuentas externas, sin esperar propagación. Y sobre ese medio segundo: no es una cola ni una demora de "vuelve a comprobarlo en 24 horas", es simplemente el calentamiento normal de la caché de CDN. El primer visitante de un subdominio nuevo puede notar un instante de latencia extra mientras el nodo de edge más cercano descarga el paquete de recursos; el segundo visitante, y todos los siguientes, lo reciben desde la caché. En la práctica no lo notarás — publicarás, tocarás el enlace y ya se sentirá instantáneo. Solo lo menciono porque alguien que se dedica a capturar tiempos de carga eventualmente preguntará por qué la solicitud uno y la solicitud diez no son idénticas, y ahora ya lo sabes.
El slug es la única decisión que vale la pena pensar con calma
Todo lo demás en este flujo es mecánico; el slug es la parte que una persona tiene que decir en voz alta o escribir de memoria, así que vale la pena pensarlo un momento. "demo-v2-final-final" está bien para pruebas internas y es algo terrible para enviarle a un cliente por mensaje. Di la URL en voz alta antes de confirmar — riverside-cafe.buildmidas.com se lee con claridad, riverside-cafe-mvp2.buildmidas.com no. Las palabras cortas y genéricas se agotan rápido en una plataforma que lleva tiempo activa, por eso un slug ya usado te da sugerencias en lugar de un simple error. Acepta una o recházala, pero decide a propósito — he visto a gente tomar lo que la caja les ofrecía en mitad de una demo porque necesitaban un enlace de inmediato, y luego cargar con un nombre incómodo durante meses porque nunca hubo un momento natural para arreglarlo.
Republicar no toca lo que está en vivo hasta que tú lo decidas
Aquí hay un hecho que vale la pena interiorizar desde el principio: editar un build publicado no mueve el sitio en vivo. Puedes romper cosas, probar un cambio de diseño arriesgado, iterar durante una semana — la URL que un cliente ya guardó en favoritos seguirá sirviendo lo último que publicaste, hasta que decidas publicar de nuevo deliberadamente.
Esa es toda tu estrategia de reversión, y es buena precisamente porque es aburrida. La versión 6 lanza un bug — un formulario que deja de enviarse silenciosamente — y no recurres a un comando de reversión ni a un ticket de soporte. Abres el historial de versiones, encuentras la versión 5, la vuelves a publicar. Mismo botón, artefacto más antiguo, la URL en vivo cambia de inmediato. Luego arreglas la versión 6 sin ninguna presión, porque producción no está rota mientras trabajas. El costo de esto es un clic extra por lanzamiento, ya que tienes que recordar publicar realmente en lugar de asumir que una edición salió automáticamente. Comparado con herramientas donde cada guardado queda en vivo — genial en una demo, complicado tres semanas después de uso real — el clic extra es un intercambio que vale la pena hacer siempre.
Despublicar significa que la URL deja de resolver, no "deja de estar listado"
Muchas plataformas usan "despublicar" para decir ocultar de una página de galería mientras la URL sigue sirviéndose silenciosamente. Aquí significa que la dirección se apaga por completo — sin página en caché, sin marcador de posición, nada resuelve. El build en sí sobrevive con cada versión intacta; republícalo más tarde y el mismo slug vuelve exactamente donde lo dejaste. He usado esto por el motivo mundano (terminó una colaboración con un cliente, nadie quiere su logo antiguo flotando en un enlace público) y por el menos mundano (un build filtró algo que no debía, y necesitaba estar fuera de línea en el tiempo que toma pulsar un botón, no el tiempo que toma abrir un ticket con un proveedor de hosting). Ambas situaciones quieren la misma garantía, y ambas la obtienen.
Otra cosa que vale la pena no confundir: publicar hace que una URL esté en vivo para cualquiera con el enlace; que sea descubrible — listada públicamente, a veces mostrada en el Showcase — es un interruptor completamente aparte. Muchos sitios publicados legítimos deberían permanecer accesibles solo por enlace para siempre, y un build que opta por el listado público sigue siendo simplemente un sitio publicado normal por debajo, con el mismo historial y el mismo botón de despublicar.
