Plec de condicions d'una app mòbil: model d'una pàgina

Plec de condicions d'una aplicació mòbil: la resposta curta

Un bon plec de condicions d'aplicació mòbil, quan crees la teva pròpia app, cap en una pàgina. Respon deu preguntes: per a qui és, quin problema resol, quina és la funció principal, com guanya diners l'app, què passa sense compte, quines dades han de sobreviure, en quina plataforma, què queda fora de la primera versió, com sabràs que funciona i amb quines limitacions. El model per copiar és més avall. També pots descarregar la plantilla i la seva graella de validació (.md), sense registrar-te.

Els models de 40 pàgines que trobes en línia estan pensats per a un altre ús: un client que encarrega una app a un proveïdor i necessita un document contractual. Tu ets alhora qui decideix i qui construeix, sovint amb l'ajuda de la IA. El teu plec de condicions serveix per a dues coses: prendre les decisions abans de programar i donar a Claude, ChatGPT o Cursor un context clar perquè construeixin l'app que toca.

Publico les meves pròpies apps iOS. Solys, un despertador amb minijocs, i TradaZen, un simulador de trading, són a l'App Store. Nolera i Clic van ser rebutjades per Apple i després corregides. Aquest és el mètode que faig servir amb cadascuna, i és el que et proposo aquí.

Per què n'hi ha prou amb una pàgina per definir la teva app

Un document llarg fa la sensació d'haver avançat. A la pràctica, s'escriu una vegada, gairebé no es rellegeix, i el projecte se n'allunya des de les primeres setmanes. Una pàgina, en canvi, es rellegeix en dos minuts abans de cada sessió de feina.

La limitació d'espai també té un efecte útil: t'obliga a decidir. Si una resposta passa de dues frases, sovint és que la decisió no està presa. Val més descobrir-ho en un full que al teu codi, tres setmanes més tard.

I, finalment, una pàgina és la mida ideal per a la IA. La pots enganxar sencera en una conversa o desar-la al fitxer de context del projet. Un document curt es revisa més fàcilment i redueix les instruccions contradictòries. No garanteix que la IA les segueixi: comprova les seves propostes respecte a aquest marc.

Què ha de contenir un plec de condicions per a una aplicació mòbil?

Respon cadascuna d'aquestes preguntes en una o dues frases.

1. Qui fa servir l'app, i en quina situació? No «la gent de 18 a 35 anys». Millor una persona concreta, en un moment concret del dia.
2. Quin problema resol l'app, en una frase? Si necessites un «i a més», estàs descrivint dues apps.
3. Quina és LA funció principal de la primera versió? Només una. Les altres esperaran a veure les xifres. La pàgina MVP d'aplicació iOS explica com triar-la.
4. Com guanya diners l'app? Subscripció, compra única o gratuïta. Aquesta resposta canvia l'app des de la primera pantalla. Si dubtes, llegeix subscripció o compra única per a una app iOS.
5. Què es pot fer sense crear un compte? Decidir aviat què és accessible sense registre t'estalvia refer tot el recorregut d'entrada.
6. Quines dades han de sobreviure a un canvi de telèfon? És la pregunta que decideix si necessites un backend com Supabase o si tot pot quedar-se al dispositiu.
7. Només iOS, o iOS i Android? El meu consell quan comences: primer iOS. T'explico per què a app iOS i Android alhora.
8. Què queda explícitament FORA de la primera versió? La secció més útil del document. Talla els debats abans que existeixin, tant amb tu mateix com amb la IA.
9. Com sabràs que funciona? Un sol senyal, mesurable les setmanes després del llançament: proves gratuïtes iniciades, subscriptors, usuaris que tornen.
10. Quines són les teves limitacions reals? El temps que hi pots dedicar cada setmana, el teu equip i el teu compte Apple Developer, que costa 99 $ l'any. No tens Mac? No és un impediment, com explico a publicar una app iOS sense Mac.

El model de plec de condicions per copiar

Copia aquest model en una nota o en un fitxer de text a l'arrel del projecte, i després omple cada línia.

• Nom provisional de l'app: …
• Per a qui: una persona que … en el moment en què …
• Problema que resol, en una frase: …
• Funció principal de la versió 1: …
• El que veu l'usuari quan obre l'app per primera vegada: …
• Model de negoci: subscripció / compra única / gratuïta, i què és de pagament: …
• Sense compte, es pot: …
• Dades que cal conservar entre dos telèfons: cap / …
• Plataforma: primer iOS (Android més endavant si les xifres acompanyen)
• Fora de la versió 1: …, …, …
• Senyal d'èxit: …
• Stack: React Native, Expo, Supabase si calen comptes, RevenueCat per a les subscripcions
• Limitacions: … hores per setmana, compte Apple Developer obert o no, Mac o no
• Apps l'experiència de les quals m'agrada, i per què: …

Afegeix-hi de tres a cinc captures d'apps que t'agradin, amb una nota sobre què t'agrada de cadascuna. Diu més que una guia d'estil, tant per a tu com per a la IA.

Un plec de condicions no és una llista de desitjos. És una llista de decisions preses.

Exemple: la pàgina omplerta per a una app fictícia

Perquè vegis el nivell de detall esperat, aquí tens el model omplert per a una app inventada per a l'exemple, un temporitzador d'estudi.

• Per a qui: un estudiant que estudia sol al vespre i es desconnecta al cap de deu minuts.
• Problema: no aconsegueix aguantar una sessió de feina sense tocar el telèfon.
• Funció principal: iniciar una sessió cronometrada i veure la seva ratxa de dies complerts.
• Primera pantalla: un sol botó per començar una sessió.
• Model de negoci: subscripció per a les estadístiques detallades, sessió bàsica gratuïta.
• Sense compte: tot, excepte la còpia de seguretat entre dos telèfons.
• Fora de la versió 1: mode grup, rànquing entre amics, widgets, versió Android.
• Senyal d'èxit: usuaris que tornen diversos dies seguits.

Fixa't en el que hi falta a propòsit: cap llista de vint pantalles, cap color imposat, cap arquitectura. Aquestes decisions arribaran mentre construeixes, i la pàgina et serveix per comprovar que continuen al servei de la funció principal.

Com fer servir el plec de condicions per guiar la IA

Aquí és on la teva pàgina rendeix més. Una IA que programa sense context endevina, i sovint endevina una app que no és la teva.

Posa la pàgina al context permanent del projecte. Claude Code llegeix un fitxer CLAUDE.md a l'arrel, i Cursor té els seus propis fitxers de regles. Enganxa-hi el plec de condicions, amb el teu stack. Així cada petició parteix de la mateixa base.

Cita la secció «fora de la versió 1» quan la IA s'hi passi. Els assistents proposen de bon grat funcions extra: un mode fosc, una opció de compartir, una notificació. La teva llista d'exclusions et dona la resposta feta: ara no.

Demana un pla que respecti la pàgina. Abans d'una feina gran, escriu: «aquí tens el meu plec de condicions, proposa un pla per a la funció principal, no programis encara». Veuràs de seguida si el pla s'allunya del que has decidit.

Fes-li revisar la pàgina, no només el codi. Pregunta: «quines preguntes d'aquest plec de condicions són confuses o contradictòries?». És un ús infravalorat de la IA, i t'estalvia setmanes de feina en la direcció equivocada.

Si vols aprofundir-hi, he detallat els paranys i les comprovacions a crear una app iOS amb la IA.

Convertir les decisions en criteris de validació

Una funció principal ha de tenir un resultat observable. Per al temporitzador fictici d'aquest exemple, «el temporitzador funciona» és massa vague. Escriu més aviat: «Inicio una sessió, es mostra el temps restant, la puc aturar i trobo l'última sessió acabada després de tornar a obrir l'app.» Decideix a part si el temporitzador ha de continuar amb la pantalla bloquejada: aquesta decisió pot canviar la feina tècnica.

Afegeix tres línies per a cada funció: acció, resultat esperat, prova. La prova pot ser un test automatitzat per a un càlcul o una comprovació al dispositiu per a un recorregut. Apunta també el que no s'ha provat. Aquesta petita graella evita confondre una pantalla acabada amb una funció llesta per fer-se servir.

Aquí tens una graella omplerta per al nostre temporitzador fictici. Són criteris per comprovar, no proves ja superades:

Decisió del plec	Què cal provar	Resultat esperat
La sessió bàsica és accessible sense compte	Instal·lar l'app i iniciar una sessió sense registrar-se	Cap formulari de registre bloqueja l'inici
Una sessió abandonada no compta per a la ratxa	Aturar una sessió abans d'acabar i obrir l'historial	No s'hi afegeix cap sessió acabada
L'historial es queda al dispositiu	Acabar una sessió, tancar l'app i tornar-la a obrir	La sessió apareix una sola vegada amb la durada correcta
El temporitzador bàsic funciona sense xarxa	Activar el mode avió i acabar una sessió	El temporitzador i el desament local continuen funcionant
Les estadístiques detallades són de pagament	Obrir les estadístiques sense subscripció	Es mostra l'oferta; la sessió bàsica continua accessible

Els punts encara confusos es converteixen en decisions pendents. Per exemple: què passa si l'usuari bloqueja la pantalla o canvia l'hora del telèfon durant una sessió? No deixis que l'agent triï en silenci. Escriu el comportament que vols i afegeix el cas a la graella. Per organitzar aquestes proves en una instal·lació real, fes servir la guia provar la teva app d'iPhone amb TestFlight.

Decidir què treure quan la primera versió es desborda

Repassa cada funció i fes-te una pregunta: «Sense ella, l'usuari encara pot obtenir el resultat promès?» Per al nostre temporitzador, un rànquing entre amics pot esperar. Recuperar una sessió acabada és necessari si promets una ratxa de dies. Una pantalla de subscripció només és necessària si de debò comercialitzes les estadístiques des d'aquesta versió.

Apunta la decisió i el motiu al registre del model descarregable. Podràs reconsiderar-la després de les proves sense perdre el perquè de l'abast inicial. El tutorial crear una aplicació amb Claude Code mostra després com convertir aquesta definició en peticions acotades i verificables.

Per a una experiència real, TradaZen va canviar d'abast després de publicar-se. La definició serveix per treure una primera versió mesurable i després decidir la següent amb opinions reals.

El parany del catàleg de funcionalitats

L'impuls natural és fer una llista de tot el que l'app «haurà de fer»: el mapa, el xat, les notificacions, les invitacions, el mode fora de línia. Aquest catàleg és el senyal més fiable d'un projecte que no arriba enlloc, per una raó senzilla: cada funció afegida abans del llançament endarrereix el moment en què usuaris reals et diuen què importa.

Una bona primera versió fa una cosa, i la fa bé. Però vigila amb l'excés contrari: Apple demana que una app vagi més enllà d'un lloc web empaquetat, segons la norma 4.2 de les App Review Guidelines. Una sola funció principal, sí; una closca buida, no: és el motiu de la guideline 4.2.

El que un plec de condicions d'app mòbil no ha de contenir

• Una guia d'estil completa. Al principi n'hi ha prou amb unes quantes captures de referència.
• Una planificació dia a dia. Encara no tens la informació per complir-la. N'hi ha prou amb un objectiu setmanal.
• Una arquitectura tècnica detallada. Tria un stack provat i deixa que els detalls es decideixin mentre construeixes.
• Funcions «per a més endavant» barrejades amb la resta. Totes van a la secció fora de la versió 1.

Quan has d'actualitzar el plec de condicions?

Rellegeix-lo al començament de cada setmana de feina. Actualitza'l només quan una decisió canviï per una raó de pes: una prova al teu iPhone que demostra que una pantalla no funciona, l'opinió d'un provador, una restricció d'Apple que descobreixes pel camí. Si el modifiques cada dia, és que ja no defineix res.

Un cop publicada la primera versió, la pàgina es converteix en la base de la següent: el que quedava fora de la versió 1 puja, ordenat segons el que et diuen les xifres. La visió de conjunt del recorregut, de la idea a la publicació, és a la pàgina crear una aplicació d'iPhone.

De la pàgina a l'app publicada

Si has respost les deu preguntes, ja has fet la feina que molts projectes se salten. El següent pas és construir la funció principal, provar-la al teu iPhone, connectar les subscripcions i preparar el dossier per a Apple.

Aquest recorregut és el de l'iOS Kit, en quatre etapes per seguir al teu ritme: la primera serveix per triar l'app que pot donar diners, el seu públic i el seu preu, i el teu plec de condicions n'és el punt de partida.

No saps si la teva idea està prou madura per cabre en una pàgina? El diagnòstic gratuït et diu què bloqueja el teu projecte avui i per quina etapa començar. La pàgina d'inici mostra després com crear una app mòbil a partir d'aquesta definició, amb Claude Code.

No et prometo ni ingressos ni publicació: qui valida és Apple, i la resta la decideix el mercat. Sense el kit, aquest model n'hi ha prou per començar.

Preguntes freqüents

Com s'escriu un plec de condicions per a una aplicació mòbil?

Fes que el plec de condicions càpiga en una pàgina: deu preguntes, una o dues frases per resposta. Tracten del públic, el problema, la funció principal, el model de negoci, què passa sense compte, les dades que han de sobreviure, la plataforma, què queda fora de la primera versió, el senyal d'èxit i les limitacions. Si una resposta passa de dues frases, sovint és que la decisió no està presa.

Quin programa he de fer servir per escriure el plec de condicions d'una app?

Una simple nota o un fitxer de text a l'arrel del projecte: hi copies el model i després omples cada línia. També pots descarregar la plantilla i la seva graella de validació (.md), sense registrar-te. Per guiar una IA, desa'l després al fitxer de context del projecte.

Cal un plec de condicions de 40 pàgines per a una aplicació?

No, quan crees la teva pròpia app: n'hi ha prou amb una pàgina. Els models de 40 pàgines que es troben en línia estan pensats per a un client que encarrega una app a un proveïdor i necessita un document contractual. Tu decideixes i construeixes: la teva pàgina serveix per prendre les decisions abans de programar i per donar context a la IA.

Com dono el plec de condicions a una IA que programa?

Posa la pàgina al context permanent del projecte: Claude Code llegeix un fitxer CLAUDE.md a l'arrel, i Cursor té els seus propis fitxers de regles. Cita la secció «fora de la versió 1» quan la IA s'hi passi. Abans d'una feina gran, demana un pla que respecti la pàgina, sense programar encara.

Com comprovo que una funció respecta el plec de condicions?

Afegeix tres línies per a cada funció: l'acció, el resultat esperat i la prova. La prova pot ser un test automatitzat per a un càlcul o una comprovació al dispositiu per a un recorregut. Apunta també el que no s'ha provat, per no confondre una pantalla acabada amb una funció llesta per fer-se servir.

Què no s'ha de posar en un plec de condicions d'aplicació?

Quatre coses que cal evitar: una guia d'estil completa, una planificació dia a dia, una arquitectura tècnica detallada i funcions «per a més endavant» barrejades amb la resta. Al principi n'hi ha prou amb unes quantes captures de referència, i per a la planificació, amb un objectiu setmanal. Les funcions per a més endavant van totes a la secció fora de la versió 1.