El punt de partida: arribar amb alguna cosa ja construïda
És un escenari que veiem cada cop més. Algú - un fundador, una persona de producte, un emprenedor sense perfil tècnic - ha fet servir eines d'IA per construir un MVP d'app mòbil. Ha arribat lluny de debò. L'app existeix, té funcionalitat, i hi ha un esforç al darrere.
Però llavors apareix el mur. El disseny no es veu bé a tots els dispositius. Hi ha bugs que no sap on buscar, i molt menys com corregir. I quan intenta publicar a l'App Store o Google Play, el procés sembla un món a part amb les seves pròpies regles. Això no és un fracàs, és una de les situacions més habituals que trobem, i té una sortida clara.
Què ens va arribar exactament
Fa poc ens va arribar una app mòbil desenvolupada amb Flutter que el client havia construït pel seu compte amb eines d'IA. Pantalles, navegació, lògica principal, tot hi era. Funcionava. Però en quant vam obrir el projecte, el deute acumulat era evident: espaïats inconsistents, components que es trencaven en certes mides de pantalla, tipografia que mai havia estat adaptada correctament per a mòbil. Alguns fluxos clau estaven bloquejats per bugs que no es veien a primera vista però apareixien en quant t'allunyaves de les pantalles principals.
I després hi havia el procés de publicació a les botigues: certificats, provisioning profiles, requisits de metadades, guies de revisió... un territori completament desconegut per al client. En resum: un producte que havia arribat al 70% però estava encallat en el 30% més complicat.
Com ho vam abordar
Primer, el diagnòstic. Abans de tocar res, vam mapejar exactament què hi havia, què faltava i què calia canviar. Això va implicar revisar la base de codi per entendre les decisions que s'havien pres: algunes intencionades, d'altres heretades del codi generat per IA, i identificar quines causaven problemes i quines simplement eren poc convencionals però inofensives.
Després, disseny i correcció d'errors. Amb el diagnòstic clar, vam treballar els problemes de disseny de forma sistemàtica: correccions de layout, estandarització de components, comportament responsive en diferents dispositius. En paral·lel, vam resoldre els bugs que bloquejaven els fluxos crítics, no reescrivint-ho tot, sinó amb correccions precises on estava el problema.
Finalment, la publicació a les botigues. Aquesta fase està infravalorada. Publicar una app a l'App Store i Google Play implica comptes de desenvolupador, certificats de signatura, configuracions de build, fitxes de botiga, captures de pantalla, polítiques de privacitat i un procés de revisió amb requisits molt concrets. Vam gestionar tot el pipeline, des del primer enviament fins a l'aprovació.
La IA en el desenvolupament actual: el que permet i el que no garanteix
La IA ha canviat la manera com es construeixen productes digitals, i cada cop arriben més projectes que han nascut amb la seva ajuda. És una realitat del sector que no anirà a menys.
El problema és que generar codi amb IA és fàcil. Entendre el que has generat, detectar on falla, adaptar-lo a les regles de publicació d'Apple i Google, i assegurar-te que el que tens és mantenible a llarg termini, ja no ho és tant. La IA no sap si la teva arquitectura donarà problemes d'aquí a sis mesos. No coneix els requisits específics de les botigues. I no pot garantir que el que produeix sigui correcte només perquè funcioni a primera vista.
No és un problema de l'eina. És un problema de context: sense experiència real en desenvolupament, és difícil saber quines preguntes fer i com avaluar les respostes. I això té conseqüències concretes quan el projecte ha de sortir al món.
Què t'emportes de tot això
Si tens un MVP - construït amb IA, amb freelancers, amb les eines que tenies disponibles - i alguna cosa no acaba de funcionar, o simplement no saps com fer el següent pas: hi ha una solució que no implica començar de zero.
No cal llençar-ho tot. De vegades només cal algú que sàpiga on mirar.
