Esta semana me dediqué a publicar de verdad una build en vivo por los tres caminos en lugar de solo describirlos, así que aquí está el registro — qué ejecuté, qué se rompió, qué me saltaría si lo volviera a hacer.
Día 1, mañana — el subdominio de un clic
Empecé con la opción más rápida: le di a publicar y obtuve tunombre.buildmidas.com sin DNS, sin crear cuenta, sin costo. Tardó unos cuatro segundos. Este es el movimiento cuando solo quieres saber si a alguien le importa la idea — comparte el enlace, observa qué pasa, itera. Casi esperaba toparme con un muro en cuanto la app necesitara cosas de backend reales —cuentas, una base de datos, una capa de multijugador con WebSocket—, pero no, eso también está alojado y gestionado. Nada que configurar por mi parte. Buen primer día.
Día 1, tarde — intentando romper el despliegue por SFTP
Esta es la parte que más me ponía nervioso. Una vez que un producto supera el subdominio y necesita su propio dominio, despliegas por SFTP directamente desde la página de build. Lo apunté a un servidor que ya tenía un webroot con archivos viejos, medio esperando que los aplastara. En cambio, el agente de despliegue inspeccionó el servidor, eligió una estrategia y —este es el detalle que importó— capturó el webroot preexistente antes de tocar nada. Cada versión desplegada después de eso también se conserva, y revertir es un clic. Así que cuando deliberadamente publiqué una build rota veinte minutos después solo para probarlo, revertir tomó más o menos lo mismo que tardé en notar que la build estaba rota. Escribí más sobre por qué eso importa en Iterar sin miedo — la versión corta es que el historial de versiones convierte los despliegues de un momento de contener la respiración en un no-evento.
Lo que me saltaría la próxima vez: pasé veinte minutos tratando de engañarlo con una estructura rara de subdirectorios anidados antes de recordar que todo el punto es que es tu servidor, tu dominio, tus archivos — la herramienta es solo un transportador cuidadoso, no un guardián. Esfuerzo desperdiciado probando algo que nunca fue el riesgo real.
Día 2 — el camino de la tienda, que no terminé
En realidad no terminé esto, y esa es, honestamente, la nota más útil. El envío a tiendas —Android a Google Play, extensiones a Chrome Web Store y Firefox Add-ons— se hace a través de tus propias cuentas de desarrollador, con listados y declaraciones de privacidad preparados por agentes. Eso es real, pero también es su propio proceso de varios días con colas de revisión fuera del control de cualquiera, así que me detuve después del paso de preparación del listado. Si buscas distribución en tiendas, presupuesta eso por separado; escribí el recorrido completo en De prompt a tienda de apps.
Qué decidía qué camino tomar, en el momento
Para el segundo día, la elección prácticamente se hacía sola:
| Qué estaba haciendo | Camino al que recurría |
|---|---|
| Comprobar si la idea tenía vida | Subdominio, el mismo día |
| Necesitaba un dominio de marca real | Primero subdominio, luego SFTP a mi propio servidor |
| Utilidad que la gente debería encontrar en una tienda | Página de aterrizaje en subdominio + envío a tienda para la app |
| Proyecto de cliente en su infraestructura | SFTP a su servidor, con control de versiones |
Fin de semana
Para el viernes tenía un sitio de marketing en mi propio dominio, el producto mismo en vivo en un subdominio y un listado de tienda medio preparado —los tres caminos funcionando a la vez para el mismo proyecto, construido e iterado desde el mismo chat todo el tiempo. Ese es, al parecer, el estado final normal para cualquier proyecto serio, no una excepción. Ojalá lo hubiera esperado desde el día uno en lugar de tratar los tres caminos como decisiones separadas.
