Donar d'alta un client escrivint només la seva URL

Quan algú vol provar un producte de programari, cada camp extra al formulari de registre és una oportunitat perquè marxi. Si per donar-se d'alta li demanes nom del negoci, logotip, colors i dades de cada propietat, la majoria tancarà la pestanya abans d'acabar. Aquesta setmana he tancat un flux de registre que demana tres coses: correu, contrasenya i l'adreça web del negoci. El sistema entra a aquella pàgina, en treu la identitat visual, crea el compte i, pocs minuts després, la pàgina pública del client ja és en línia sense que ningú més hi hagi tocat res.

La decisió de producte és simple: si la informació ja existeix en algun lloc, no la demanis. La web d'un negoci ja porta el nom, el logo i els colors. Només cal anar-los a buscar.

Tres passos fins a tenir la web en línia

L'experiència d'un usuari nou té tres passos:

1. Escriu l'adreça d'un dels seus anuncis (la propietat que lloga, el servei que ofereix).
2. El producte li fa una recollida gratuïta: contacta els seus clients, els demana una valoració i les recull.
3. Amb les valoracions recollides, la pàgina pública es genera i es publica sola.

Cap d'aquests passos requereix un humà a l'altre costat. La web neix sola. Això és el que internament en dic auto-debut: la primera publicació de la web es dispara quan la primera recollida de valoracions acaba, sense que l'usuari hagi de prémer cap botó.

POST /public/signup: alta atòmica amb rollback

Tot comença amb un sol endpoint públic:

POST /public/signup
Body: { email, password, websiteUrl }

L'endpoint fa dues coses en seqüència: crea el tenant (el compte del negoci dins el sistema, amb la seva identitat visual extreta de la URL) i crea l'usuari a Cognito, el servei d'autenticació d'AWS que gestiona correus i contrasenyes. Si la segona operació falla —per exemple perquè el correu ja existeix a Cognito—, el sistema esborra el tenant que acaba de crear. Sense aquest rollback quedaries amb comptes orfes: tenants sense cap usuari que hi pugui entrar.

L'extracció de marca passa dins la creació del tenant. El sistema fa un GET a la websiteUrl que l'usuari ha proporcionat, analitza l'HTML i en treu:

• El nom del negoci (normalment de l'element <title> o de les metadades Open Graph).
• El favicon o logo.
• Els colors principals del CSS.

No és perfecte. Hi ha webs que porten tot el contingut carregat amb JavaScript i el GET simple no veu res. Hi ha logos que són SVG incrustats que costen de parsejar. Però en la majoria de casos n'hi ha prou per tenir un punt de partida raonable que el client pot corregir després.

Generació de disseny amb Bedrock

Un cop el tenant té la identitat visual bàsica, el sistema la passa a Amazon Bedrock (el servei d'AWS que dóna accés a models de llenguatge) per prendre decisions de disseny: quina tipografia complementa aquells colors, quina disposició d'elements funciona millor, quin to de text encaixa amb la marca.

Tot passa dins d'un sol endpoint intern que executa la cadena sencera:

1. Llegeix el branding del tenant.
2. Envia un prompt a Bedrock amb la identitat visual i rep les decisions de disseny.
3. Renderitza la pàgina en tres llengües.
4. Crea una aplicació d'Amplify (el servei de desplegament web d'AWS) i la desplega.

El resultat és una URL pública funcional. El client no ha pujat cap foto, no ha triat cap plantilla, no ha escrit cap text.

La web que es regenera sola

La pàgina pública no és estàtica. Cada vegada que acaba una recollida de valoracions, la web es torna a generar per incorporar les noves dades.

El mecanisme és un comptador pendingJobs al registre del tenant. Cada tasca en curs l'incrementa. Quan una tasca acaba, el decrementa. Quan arriba a zero, el sistema crida publishTenantSite, que torna a executar tota la cadena de generació i desplegament.

Això vol dir que la primera recollida —la gratuïta que forma part de l'onboarding— és la que dispara la primera publicació de la web. L'auto-debut no és un pas separat: és una conseqüència natural de que pendingJobs arribi a zero per primera vegada.

Freemium amb límits durs

El pla gratuït és deliberadament curt: una propietat, un canal de recollida i una recollida amb un sostre d'unes trenta valoracions. Aquests límits s'apliquen al servidor, no a la interfície. No és un avís que diu "has arribat al límit": és un rebuig net de l'operació.

La raó és pràctica. Si el límit és només visual, qualsevol crida directa a l'API se'l salta. Si és al servidor, no hi ha escletxa. El codi comprova el pla del tenant abans d'executar qualsevol operació que consumeixi quota.

El pla gratuït té prou corda perquè l'usuari vegi el producte funcionar de veritat —rep valoracions, la web es publica— però no prou perquè s'hi quedi indefinidament sense pagar.

El test de punta a punta

He provat el funnel sencer amb un test E2E que reprodueix tot el camí:

1. Alta amb correu, contrasenya i URL.
2. Creació d'una propietat.
3. Recollida de 29 valoracions.
4. Verificació que la web s'ha publicat automàticament.

El test confirma que no hi ha cap pas manual entremig. Des del POST /public/signup fins a la web desplegada a Amplify, tot passa sense intervenció. Si algun dia algú trenca la cadena —un canvi a Bedrock, un límit nou a Amplify, un error al rollback—, el test ho detectarà abans que cap usuari real s'hi trobi.