Quattro clic per andare online. Trenta secondi, dall'inizio alla fine. Un'app con server attiva per account nel piano gratuito. Mezzo secondo di latenza extra sulla primissima richiesta gestita da un sottodominio nuovo di zecca, e nessuna dopo. Tre di questi numeri sono curiosità — del tipo che annuisci e dimentichi entro il capitolo successivo. L'"uno", però, è il numero che cambia davvero il modo in cui dovresti lavorare, quindi è lì che voglio dedicare la maggior parte di questo capitolo.
Perché il limite è uno, non zero e non illimitato
La maggior parte degli strumenti no-code che permettono di pubblicare gratuitamente un frontend o non gestiscono affatto le app con server, oppure le limitano così aggressivamente che "gratuito" è solo una formalità. Qui, una build con account, un database o uno stato multiplayer si pubblica tramite lo stesso identico pulsante Pubblica di una pagina statica, e il lato server viene ospitato e gestito come parte di quell'unica azione — nessun provisioning separato del database, nessuna variabile d'ambiente da configurare, nessuna scoperta tre giorni dopo che il login funziona in anteprima ma restituisce errori 500 in produzione perché il backend non è mai stato effettivamente distribuito. Questo è reale, ed è per questo che le persone sono sorprese quando raggiungono il limite: fino a quel punto tutto sembrava illimitato.
Non lo è. Ottieni esattamente un'app con server attiva alla volta nel piano gratuito. Le build statiche non contano ai fini del limite — pubblica quante pagine di marketing e siti portfolio vuoi, nessun limite lì. Ma la seconda build che necessita di un proprio database o processo persistente deve aspettare il proprio turno, rimanendo completamente costruita e visibile in anteprima, ma non attiva al suo URL. Se stai prototipando tre idee SaaS nella stessa settimana, solo una può occupare risorse di calcolo reali; le altre due sono prodotti finiti senza un indirizzo. Penso che il limite sia posto in un punto ragionevole — un pacchetto statico costa alla piattaforma quasi nulla da servire ai margini della rete, un processo server attivo no — ma significa che la decisione su quale idea meriti lo slot deve avvenire prima di premere Pubblica, non dopo esserti già affezionato ad averne due attive contemporaneamente.
I quattro clic, per la cronaca
- Sulla scheda della build, scegli Pubblica.
- Scegli uno slug — il tuo-nome in
yourname.buildmidas.com. Gli slug già presi suggeriscono alternative. - Conferma.
- Copia l'URL dalla scheda, o trovalo più tardi nella pagina Pubblicati.
Nessun DNS, nessun account esterno, nessuna attesa per la propagazione. E riguardo al mezzo secondo: non è una coda o un ritardo del tipo "controlla di nuovo tra 24 ore", è solo un normale riscaldamento della cache CDN. Il primo visitatore di un nuovo sottodominio potrebbe percepire un istante di latenza extra mentre il nodo edge più vicino recupera il pacchetto di risorse; il secondo visitatore, e tutti quelli successivi, lo ottengono dalla cache. In pratica non lo noterai — pubblicherai, toccherai il link e sembrerà già istantaneo. Lo menziono solo perché prima o poi qualcuno che fa screenshot dei tempi di caricamento per lavoro chiederà perché la prima richiesta e la decima non sono identiche, e ora lo sai.
Lo slug è l'unica decisione per cui vale la pena rallentare
Tutto il resto in questo flusso è meccanico; lo slug è la parte che una persona deve pronunciare ad alta voce o digitare a memoria, quindi merita un attimo di riflessione. "demo-v2-final-final" va bene per test interni ed è una cosa pessima da inviare a un cliente. Pronuncia l'URL a te stesso prima di confermare — riverside-cafe.buildmidas.com si legge bene, riverside-cafe-mvp2.buildmidas.com no. Le parole brevi e generiche si esauriscono in fretta su una piattaforma esistente da tempo, ed è per questo che uno slug già preso ti dà suggerimenti invece di un semplice errore. Accettane uno o rifiutalo, ma decidi consapevolmente — ho visto persone prendere qualsiasi cosa suggerisse il campo a metà demo perché avevano bisogno di un link immediatamente, per poi convivere con un nome scomodo per mesi perché non c'è mai stato un momento naturale per sistemarlo.
La ripubblicazione non tocca ciò che è live finché non lo decidi tu
Ecco un fatto che vale la pena interiorizzare subito: modificare una build pubblicata non sposta il sito live. Puoi rompere cose, provare un cambio di layout azzardato, iterare per una settimana — l'URL che un cliente ha già salvato nei preferiti continua a servire l'ultima versione pubblicata, finché non decidi deliberatamente di pubblicare di nuovo.
Questa è tutta la tua strategia di rollback, ed è valida proprio perché è noiosa. La versione 6 introduce un bug — un form che smette silenziosamente di inviare — e non devi ricorrere a un comando di ripristino o a un ticket di supporto. Apri la cronologia delle versioni, trovi la versione 5, la ripubblichi. Stesso pulsante, artefatto più vecchio, l'URL live torna indietro immediatamente. Poi correggi la versione 6 senza alcuna pressione, perché la produzione non è compromessa mentre lavori. Il costo di tutto questo è un clic in più per rilascio, dato che devi ricordarti di pubblicare effettivamente invece di dare per scontato che una modifica sia andata online automaticamente. Confrontalo con strumenti in cui ogni salvataggio è live — ottimo in una demo, complicato tre settimane dopo nell'uso reale — e il clic extra è uno scambio che vale sempre la pena fare.
Annullare la pubblicazione significa che l'URL smette di risolvere, non "smette di essere elencato"
Molte piattaforme usano "annulla pubblicazione" per intendere nascondere il sito da una pagina galleria mentre l'URL continua silenziosamente a servirlo. Qui significa che l'indirizzo si spegne, punto e basta — nessuna pagina in cache, nessun segnaposto, nulla si risolve. La build stessa sopravvive con ogni versione intatta; ripubblicala più tardi e lo stesso slug torna esattamente dove l'avevi lasciato. L'ho usato per il motivo banale (una collaborazione con un cliente è finita, nessuno vuole che il suo vecchio logo resti su un link pubblico) e per quello meno banale (una build ha divulgato qualcosa che non doveva, e doveva essere offline nel tempo di un clic, non nel tempo necessario per aprire un ticket con un provider di hosting). Entrambe le situazioni vogliono la stessa garanzia, ed entrambe la ottengono.
Un'altra cosa da non confondere: pubblicare rende un URL attivo per chiunque abbia il link; se sia individuabile — elencato pubblicamente, a volte mostrato nella Vetrina — è un'impostazione completamente separata. Molti siti pubblicati legittimi dovrebbero restare accessibili solo tramite link per sempre, e una build inclusa nell'elenco pubblico resta comunque semplicemente un normale sito pubblicato sotto sotto, con la stessa cronologia e lo stesso pulsante per annullare la pubblicazione.
