Què passa després de fer una app amb vibe coding: el matí que deixa de ser una demo i el go/no-go que ve després

Ningú no decideix portar a producció una app feta amb vibe coding. Ho decideix producció per tu, un matí que no has triat: paga el primer desconegut, es dona d'alta una segona empresa o el departament de compres d'un client t'envia un qüestionari de seguretat. A partir d'aquell matí l'app ja no és una demo, digui el que digui el codi.

Escric això des del seient que rep la trucada unes setmanes més tard. A Conectia ens fem càrrec d'apps construïdes amb Claude Code, Cursor, Lovable, v0, Bolt i Replit i les posem a funcionar amb clients de debò; abans vaig passar anys fent DevOps i resposta a incidents en entorns corporatius, i la meva part en aquests encàrrecs són les dues primeres setmanes: llegir el que hi ha i deixar per escrit què fer-ne. Això no és cap tutorial per portar una app de Cursor a producció. Ja he escrit on es trenca un MVP fet amb IA i com audito una app de Lovable sobre Supabase. Aquest post va de la decisió: què passa quan la demo deixa de ser una demo, i com s'arriba a un veredicte que puguis comprovar en comptes de creure.

La pregunta mai no és «si el codi és bo». La pregunta és «quins mòduls aguanten un usuari que paga, i amb quina evidència».

L'app deixa de ser una demo un d'aquests tres matins

El fundador gairebé mai no s'adona del moment. L'app, sí. Hi ha tres fets que converteixen un prototip en una obligació, i cadascun canvia què vol dir el mateix codi.

El primer usuari que paga. Mentre no es mou cap diner, un bug és un bug. Després, aquell mateix bug és una devolució, una disputa amb la targeta o un client que marxa i ho explica a tres més. El pagament afegeix, a més, l'única part de l'app que mou el sistema d'un altre: el webhook. El proveïdor reintenta, l'esdeveniment arriba dues vegades o no arriba, i el teu codi s'executa en l'ordre que hagi decidit la xarxa. Una demo no passa mai per aquest camí, perquè vas prémer «pagar» una vegada i vas veure que funcionava.

El segon client. Les dades del primer client vivien en unes taules que eren, a la pràctica, seves. Les del segon cauen a les mateixes taules, i qui pot llegir què deixa de ser una qüestió teòrica. En una app de Lovable la resposta són unes polítiques de Postgres que qui la va construir pot haver escrit o no; en una app de Cursor o de Claude Code és l'autorització que l'agent va deixar a l'API, i sovint és un botó amagat. El maig de 2025 un investigador va escanejar 1.645 apps de l'aparador públic de Lovable i en va trobar 170 que es podien llegir o escriure amb la clau pública i res més (CVE-2025-48757). Aquelles apps funcionaven. Funcionaven per a tothom.

El primer qüestionari de seguretat. Un client gran vol comprar i t'envia un full de càlcul: on són les dades, qui hi té accés, com es roten les claus, quina còpia de seguretat teniu i fins a quin punt es recupera, si guardeu registres. Les preguntes no són difícils. El que passa és que no tenen resposta en una app que ningú no ha llegit com a sistema, i «l'hem feta amb IA» no és una resposta que un departament de compres accepti.

Cadascun d'aquests tres matins demana el mateix: algú que llegeixi l'app sencera i signi un veredicte. I no qui la va construir, que ja sap que no aguantarà i no sap dir per què.

Els vuit símptomes són l'app assenyalant el mòdul que ha fallat primer

Quan un fundador ens escriu, porta un símptoma, no una causa. Després de prou casos, els símptomes s'ordenen sols en vuit, i cadascun apunta a un mòdul. Publiquem la llista perquè estalvia una setmana a tothom.

1. El login es trenca o els usuaris perden la sessió. L'autenticació es va quedar amb els valors per defecte del constructor: URL de redirecció, caducitat de sessió, confirmació per correu. A Supabase, sense un SMTP propi, el remitent incorporat s'atura a dos correus per hora, i aquesta és l'avaria del dia de llançament que ningú no veu venir.
2. La base de dades va més lenta cada setmana. Consultes sense índexs, pantalles que carreguen taules senceres, una política que avalua auth.uid() fila a fila. Amb cinquanta usuaris no es nota.
3. El pagament entra i l'accés no es desbloqueja. Webhooks sense verificació de signatura, sense reintents ni idempotència, de manera que un esdeveniment perdut o repetit deixa el compte en l'estat equivocat.
4. Funciona a preview i falla a producció. Variables d'entorn i ajustos de build que només existeixen a la plataforma del constructor, sense cap staging entremig. Les apps de v0 i de Replit ho mostren més que cap altra, perquè la plataforma era l'entorn.
5. No passaria una revisió de seguretat. Claus dins del bundle del navegador, polítiques d'accés que ningú no ha provat, cap registre d'accessos.
6. No pots donar d'alta un segon client. Aïllament per convenció: el front filtra per organization_id; la base de dades, no.
7. Ningú no gosa desplegar. Sense tests als camins que mouen diners o dades personals, sense CI, i cada arranjament de l'agent trenca una altra cosa. L'agent de Replit va esborrar una base de dades de producció el juliol de 2025 durant una prova en viu, després que li ordenessin no tocar res. La lliçó no va de Replit: un sol entorn més un agent amb permís d'escriptura és un entorn de menys.
8. La factura del núvol creix més de pressa que els usuaris. Crides al model sense sostre, funcions que s'executen a cada vista de pàgina, recursos que ningú no va apagar.

Cada símptoma, un cop té nom, és un o dos dies de feina sènior. El que és car ve abans: decidir quin dels vuit tens, a quin mòdul, i si aquell mòdul mereix conservar-se.

Les dues respostes equivocades són reescriure-ho tot i «llançar i veure què passa»

Algú, sovint el teu primer fitxatge sènior, proposarà reescriure-la «com cal». He vist aquest consell cremar un trimestre de caixa en productes amb les pantalles i el model de dades en bon estat. Primer el perímetre, després substituir el que porta risc peça a peça, i continuar traient funcionalitats mentrestant: aquest ordre guanya gairebé sempre, i el vaig defensar al primer post d'aquesta sèrie.

L'altra resposta equivocada és tirar endavant. És la que més fundadors trien, perquè avui l'app funciona i perquè els que els diuen que parin són els mateixos que venen l'aturada. Concedeixo la versió més forta d'aquesta objecció: nou de cada deu apps d'aquell escaneig de Lovable no estaven exposades per aquell error, i una app sense usuaris que paguin i sense dades sensibles hauria de continuar construint-se amb l'eina que l'ha portat fins aquí. Un veredicte abans que hi hagi res a protegir són diners gastats en un actiu que potser no sobreviurà al següent gir.

Però quan ja ha arribat un dels tres matins, «llançar i veure» vol dir deixar que l'auditoria la facin els clients. La faran. I lliuraran les troballes en forma de devolucions i de qüestionaris.

Hi ha una tercera resposta, i té nom a totes les disciplines que llancen coses. Abans d'un llançament, cada lloc de la sala canta go o no-go amb la seva pròpia telemetria. El director de vol no llança per intuïció, sinó sobre una llista de «go», cadascun avalat per un número que algú pot ensenyar. Jo vaig passar anys a la versió corporativa d'aquella sala, on una release només rebia el go amb un rollback provat i una còpia que algú havia restaurat de debò. Això és el que vull de les dues setmanes que van de «ha deixat de ser una demo» a «comencem la feina».

Un sprint de discovery acaba en un go/no-go per mòdul, amb la mesura al costat

El Diagnòstic i Blueprint és aquest sprint de discovery: dues setmanes, accés només de lectura al repositori, a la base de dades i a la consola del núvol, una sessió de treball amb qui millor coneix el producte i, al final, un veredicte per escrit. La pàgina explica què conté el document. El que vull deixar clar aquí és el llistó que ha de superar el veredicte, perquè un veredicte que no es pot comprovar és una opinió amb capçalera.

La unitat és el mòdul, no l'app. Login, dades, pagaments, integracions, la capa d'IA: cadascun rep una de tres paraules. Rescatar vol dir que el mòdul aguanta un usuari que paga amb una llista acotada d'arranjaments. Refer vol dir que els arranjaments costen més que una versió neta que encaixi en l'arquitectura objectiu. Llençar vol dir que ningú no el fa servir i porta risc. Cap mòdul no es queda en «depèn».

Cada veredicte porta la seva evidència, i l'evidència és una mesura, no una impressió:

• Camins crítics executats. Alta, login, pagament i la consulta que seria una bretxa si es filtrés, recorreguts de cap a cap contra una còpia de les dades, amb el que va passar anotat. No «l'autenticació sembla correcta»: aquesta petició, aquest usuari, aquesta resposta.
• Consultes cronometrades. La pantalla lenta té una consulta, la consulta té un pla i el pla té un número. Un «rescatar» al mòdul de dades arriba amb l'índex que ho arregla i amb el temps d'abans i de després.
• Costos mesurats. Quant costa una petició a la capa del model, quant costa una vista de pàgina en invocacions de funcions i quina seria la factura amb deu vegades més usuaris. Si ningú no pot donar aquests tres números, el símptoma vuit ja és de camí.
• Per a les funcionalitats d'IA, un conjunt d'avaluació i una mètrica. Aquesta és la que la majoria de fundadors encara no s'ha trobat. Una funcionalitat d'IA sense evals és una funcionalitat que ningú no pot tocar: el següent retoc al prompt pot millorar-la o trencar-la, i ningú no ho sabrà fins que ho sàpiga un client. El veredicte sobre un mòdul d'IA és un go/no-go contra un conjunt de casos que el model ha de superar i la mètrica que ha d'assolir, i aquell conjunt es converteix en la suite de regressió de tots els canvis que vinguin després.

Les mesures es lliuren amb els fitxers, perquè la següent persona, sigui el teu fitxatge, el nostre equip o el mateix agent que va escriure la primera versió, pugui repetir-les. Aquesta és la diferència entre un sprint de discovery i una presentació.

Què faria jo la setmana següent a la primera factura

Si l'app fos meva i el primer desconegut acabés de pagar, en aquest ordre:

1. Apunta a quin matí ets. Primer pagament, segon client o qüestionari. Això fixa l'ordre de tot el que segueix.
2. Treu a l'agent el permís d'escriptura a producció. Un sol entorn amb un agent de codi a dins és la història de Replit esperant repetir-se. Dona a l'agent una branca i una base de dades de preview; producció queda per a les persones i per a la CI.
3. Rota totes les claus que hagin passat mai pel repositori i busca al bundle compilat la clau secreta o de service role. És una tarda de feina, i tanca la troballa per la qual pregunta primer qualsevol qüestionari.
4. Recorre tu mateix els tres camins crítics i anota el que has vist. Si no saps dibuixar el recorregut de la petició més arriscada, aquesta és la primera feina de l'auditoria.
5. Demana un veredicte per mòdul a algú que ja ho hagi fet abans, per escrit i amb les mesures adjuntes. Dues setmanes és la durada correcta: més temps vol dir que l'auditor s'ha posat a construir; menys, que està endevinant.
6. Decideix amb els números al davant. Rescatar, refer o llençar, mòdul a mòdul, i només llavors construir. A la majoria d'apps fetes amb IA les pantalles i bona part del model de dades es queden, l'autenticació i els pagaments es refan, i quan cal refer el nucli, és un MVP en 6 setmanes.
7. Deixa els fitxers de context al seu lloc. CLAUDE.md, AGENTS.md, els tests i les evals, perquè Cursor o Claude Code continuïn construint dins del pla i no al voltant.

La demo va demostrar la demanda; el veredicte és el que deus a qui ha pagat

Una app feta amb vibe coding fa la part cara en un cap de setmana: demostra que algú vol el producte. El que no pot fer és decidir què deu a la persona que ha pagat, i aquesta decisió és tot el que passa després. Ni una reescriptura ni arronsar les espatlles: un go/no-go per mòdul, cadascun amb una mesura que algú pugui repetir.

Aquest és el primer pas de com portem a producció una app feta amb IA: un Diagnòstic i Blueprint de dues setmanes que acaba exactament en aquest veredicte, i que pots executar amb nosaltres, amb el teu propi fitxatge o amb l'agent que va escriure la primera versió. Si vols comparar-nos amb altres empreses que fan aquesta feina, ho vaig fer jo mateix a la guia sobre a qui contractar per a un MVP fet amb IA, i som al directori d'agències de vibecoding.app, a la seva categoria de rescat full-stack, al costat de les altres.