Com construir un MVP en un cap de setmana: un pla realista

Per construir un MVP en un cap de setmana, redueix la teva idea a una sola funció per a un tipus d'usuari, escriu-la divendres a la nit, dedica el dissabte a construir el bucle central amb un constructor d'apps amb IA, i dedica el diumenge a l'imprescindible (desar dades, una pàgina de presentació, publicar) abans de mostrar-ho a persones reals. Salta tot el que no ajuda a respondre la sola pregunta per a la qual existeix el MVP. Un cap de setmana és suficient per a una versió aproximada que funcioni. No és suficient per a un producte acabat, i això està bé.

Què és (i què no és) un MVP de cap de setmana

Un MVP (producte mínim viable) és la cosa més petita que pots construir per aprendre si una idea funciona. Què és un MVP explica la idea completa. Per a un cap de setmana, això vol dir:

• Un sol tipus d'usuari. No «autònoms, agències i els seus clients».
• Una feina, de principi a fi. L'usuari pot començar, acabar i obtenir el resultat.
• Real, no una maqueta. Desa dades, funciona al mòbil i viu en una adreça real.
• Permès tenir imperfeccions. Disseny simple, pocs paràmetres, una mica de feina manual entre bambolines.

No és una versió més petita del producte complet. És la part del producte que prova la teva suposició més gran.

Abans del cap de setmana: tria la pregunta

Cada MVP respon una pregunta. Escriu-la, perquè és la que decideix què construir:

Idealment, ja has parlat amb algunes persones que tenen el problema. Si no, com validar una idea d'app explica com fer-ho, i un parell de converses abans de divendres faran que tot el cap de setmana sigui més útil.

El pla

Divendres a la nit: decideix (2 a 3 hores)

• Escriu una frase: «[Producte] ajuda [usuari específic] a [fer una feina] sense [el dolor actual].»
• Enumera els passos del bucle central, per exemple: registrar-se, enganxar una descripció de feina, obtenir una carta de presentació adaptada, editar, copiar.
• Enumera les dades: què es desa i de qui són.
• Escriu la llista de «no aquest cap de setmana»: configuració, equips, panell d'administració, notificacions per correu, una segona funció, mode fosc. Escriure-ho ajuda a dir que no el dissabte.
• Redacta el primer prompt per al constructor (mira més avall).

Dissabte: construeix el bucle central

• Al matí: fes que funcioni la primera versió del bucle central amb dades d'exemple. Itera en passos petits: un canvi per missatge, i després revisa la vista prèvia.
• A la tarda: afegeix la base de dades perquè les dades sobrevisquin a una recàrrega, i usa l'app tu mateix amb entrades realistes. Arregla el que bloquegi el bucle i ignora el que sigui cosmètic.
• Al vespre: afegeix inici de sessió si els usuaris necessiten les seves pròpies dades. Prova-ho amb dos comptes en dos navegadors per confirmar que cap dels dos veu les dades de l'altre.

Diumenge: fes-la utilitzable per desconeguts

• Al matí: una secció de presentació senzilla: la frase, per a qui és, i un botó de registre. Afegeix pagament si la teva pregunta és sobre pagar.
• A migdia: revisa-ho en un mòbil. Els estats buits (el que veu un usuari nou abans d'afegir res) importen més del que creus.
• A la tarda: una revisió curta de seguretat i de coherència: cap clau d'API al codi del navegador, cap pàgina que mostri dades d'altres usuaris. Després publica.
• Al vespre: envia-ho personalment a entre cinc i deu persones, amb una pregunta que vulguis que es respongui.

Què deixar de banda

Coses que semblen necessàries però poden esperar:

• Panells d'administració. Mira la base de dades directament per ara.
• Configuració i perfils. Fixa valors per defecte raonables.
• Equips, rols i invitacions. Primer comptes d'un sol usuari.
• Diversos plans de preus. Un preu únic, o gratuït.
• Fluxos de correu més enllà del que necessita estrictament l'inici de sessió.
• Integracions. Exportar a CSV o copiar i enganxar és suficient per a una primera prova.
• Disseny perfecte. Net i llegible n'hi ha prou. Un color coherent i un bon espaiat fan molt.
• Escala. Deu usuaris no posaran a prova res.

Un primer prompt per a un constructor d'IA

Construeix un MVP anomenat CoverCraft per a desenvolupadors júniors que sol·liciten feina. El bucle central: després d'iniciar sessió, l'usuari enganxa una descripció de feina i el seu text de CV, tria un to (formal o amigable), i obté una carta de presentació adaptada que pot editar i copiar. Genera la carta al servidor usant un proveïdor d'IA amb el secret AI_API_KEY, i mai no exposis la clau al navegador. Desa cada carta amb el títol del lloc i l'empresa en una base de dades; cada usuari només veu les seves pròpies cartes en una llista senzilla. Afegeix una secció de presentació amb una frase que expliqui el producte i un botó Comença. Limita cada usuari a 10 cartes al dia, aplicat al servidor. Disseny net i simple, que funcioni bé als mòbils. No afegeixis paràmetres, equips ni panell d'administració.

La darrera línia importa. Els constructors d'IA tendeixen a afegir funcions que no has demanat, i dir-li què no construir manté petita la primera versió. Més sobre això a com escriure prompts per a constructors d'apps amb IA.

Consells que salven el cap de setmana

• Un canvi per missatge. Les peticions grans de diverses parts són més difícils de comprovar i més difícils de desfer.
• Prova després de cada canvi, a la vista prèvia, a mida de mòbil.
• Torna enrere en lloc de discutir. Si un canvi ha anat malament, torna a l'última versió que funcionava i demana-ho de nou més clarament.
• Usa un pas de planificació abans de qualsevol cosa arriscada, com afegir inici de sessió o pagaments.
• Deixa de polir al 80 %. L'últim 20 % de polit en una funció que ningú usa es malgasta.

Errors habituals

• Començar sense una pregunta, de manera que no pots saber si el cap de setmana ha funcionat.
• Dues funcions en lloc d'una, i acabar-ne cap.
• Construir la llista de «no aquest cap de setmana» perquè sembla productiu.
• Saltar-se la base de dades, de manera que tot desapareix en recarregar i els provadors perden el seu treball.
• No ensenyar-ho mai a ningú. Un MVP de cap de setmana que es queda privat no t'ha ensenyat res.
• Preguntar als amics «t'agrada?». Observa què fan els desconeguts que tenen el problema.

Quan no construir res

De vegades és millor no passar el cap de setmana construint. Si la idea es pot provar amb un formulari, un full de càlcul i un enllaç de pagament, o fent el servei a mà per a tres clients, fes això primer. Construeix quan el valor està en el programari en si: un flux de treball, un càlcul, un resultat generat que les eines existents no poden donar. Després del cap de setmana, com llançar una app i aconseguir els primers usuaris explica què fer després, i com construir un MVP de SaaS explica com afegir comptes i subscripcions amb criteri quan la idea s'hagi guanyat el dret.

Construir-lo amb Mythex

Mythex encaixa molt bé amb el pla de cap de setmana: descrius el MVP al xat, l'agent escriu el codi, i ho proves en una vista prèvia en directe, inclosa una vista a mida de mòbil. El mode Planificació és útil divendres a la nit per donar forma a la idea abans que s'escrigui cap codi, i cada canvi reeixit es desa com a punt de control al qual pots tornar. Quan demanes que es desin dades, Mythex afegeix una base de dades Postgres al projecte. /test demana a l'agent que faci clic per la vista prèvia com ho faria un usuari i informi dels fluxos trencats (App Testing). Pots enviar als provadors un enllaç de compartició de la vista prèvia abans de publicar.

Algunes parts les portes tu: l'inici de sessió dels usuaris usa un enfocament d'autenticació que tu tries, els pagaments usen el teu propi compte de Stripe, i les funcions d'IA usen la teva pròpia clau d'API de model. El pla gratuït dona 10 crèdits el primer dia i 5 al dia després, cosa que pot limitar quant pots construir en un cap de setmana atrafegat; el Pro dona 100 crèdits al mes. El recorregut de la idea a l'app en directe de la documentació segueix un camí similar.

Preguntes