Guies

Com pressupostar el desenvolupament d'un MVP sense sorpreses

Per Marc Molas·20 de maig del 2024·10 min de lectura

«Quant costa un MVP?» és la primera pregunta que fa tot fundador. I és la pregunta equivocada.

La pregunta correcta és: «Quina és la cosa més petita que puc construir per validar la meva hipòtesi?» Perquè un MVP no és la versió 1 del teu producte. És un experiment. I com qualsevol experiment, hauria de costar el mínim necessari per obtenir una resposta clara.

He passat per prou sessions de scoping amb fundadors per saber com acaba cada camí. Si comences preguntant pel preu, acabaràs construint més del que necessites. Si comences preguntant per la hipòtesi, acabaràs gastant només el que cal.

Pas 1: defineix què és el teu MVP (i què no ho és)

Abans de parlar de diners, necessites una llista de funcionalitats. I després necessites retallar-la a la meitat.

Sona agressiu, però funciona. Prova aquest exercici:

Apunta totes les funcionalitats que imagines per al teu producte. Totes. Sense filtre.
Classifica-les en tres categories: imprescindibles (el producte no funciona sense això), importants (milloren molt l'experiència) i nice-to-have (estaria bé, però pot esperar).
Elimina tot el que no sigui imprescindible. Sí, tot. Els «importants» van a la v1.1; els «nice-to-have», a la v2.
Per a cada imprescindible, pregunta't: puc validar la hipòtesi sense aquesta funcionalitat? Si la resposta és que sí, elimina-la també.

El resultat t'hauria de fer sentir una mica incòmode. Si la llista de funcionalitats del teu MVP et sembla completa i polida, probablement no has retallat prou.

Un MVP d'autenticació no necessita login amb Google, Apple, Facebook I email. Només email. Un MVP de marketplace no necessita sistema de ressenyes, missatgeria interna I pagaments amb escrow. Només un flux bàsic de compravenda. Un MVP de SaaS no necessita dashboard d'analítiques, rols d'usuari I integracions amb Zapier. Només la funcionalitat central que resol el problema.

Pas 2: entén els components del cost

Un MVP típic té aquests blocs de cost:

Disseny UX/UI: wireframes, fluxos d'usuari, disseny visual. Rang: 2.000-8.000 euros segons la complexitat.
Frontend: la interfície que veu l'usuari. Web (React, Next.js, Vue) o mòbil (React Native, Flutter). És on se'n va la major part del temps visible.
Backend: lògica de negoci, APIs, base de dades. El que l'usuari no veu però que fa que tot funcioni.
Infraestructura: hosting, domini, SSL, CDN, bases de dades al núvol. Cost mensual recurrent.
Serveis de tercers: autenticació (Auth0, Clerk), pagaments (Stripe), email (SendGrid), emmagatzematge (S3). Cadascun amb el seu model de preus.
Testing i QA: assegurar-se que tot funciona. Sona obvi, però molts pressupostos s'ho salten.
Desplegament i DevOps: CI/CD, entorns de staging, monitoratge. La diferència entre «a la meva màquina funciona» i «funciona en producció».

El que uneix tots aquests blocs és el temps d'enginyeria. I el temps d'enginyeria és, de llarg, el cost més gran de qualsevol MVP.

Rangs de referència per al 2024

Són referències de mercat, no els preus de cap proveïdor concret. Varien segons la regió, la complexitat i l'equip:

Web app simple (landing amb funcionalitat, dashboard bàsic, CRUD): 15.000-30.000 euros. Exemples: eina interna, directori, app de reserves senzilla.
Web app complexa (múltiples rols d'usuari, integracions, lògica de negoci no trivial): 30.000-80.000 euros. Exemples: plataforma SaaS vertical, eina de gestió amb workflows.
App mòbil (iOS i Android, backend propi): 40.000-100.000 euros. El rang és ampli perquè el mòbil sempre costa més del que sembla — dues plataformes, app stores, notificacions push, suport offline.
Marketplace o SaaS multi-tenant (mercat de dues bandes, pagaments, onboarding complex): 50.000-120.000 euros. Aquí la complexitat és a la lògica de negoci, no a la tecnologia.

Si algú et pressuposta un SaaS complet per 8.000 euros, desconfia. Si algú et pressuposta una landing amb un formulari per 50.000 euros, també.

Els costos ocults que la majoria de fundadors passen per alt

El pressupost de desenvolupament és només el començament. Aquests són els costos que apareixen després del llançament i que haurien de formar part de la teva planificació:

Manteniment continu: calcula un 15-20% anual del cost de desenvolupament. Actualitzacions de dependències, pedaços de seguretat, bugs que afloren amb l'ús real. El programari no es construeix i s'oblida.
Costos d'APIs de tercers: Stripe cobra un 1,4-2,9% + 0,25 euros per transacció. SendGrid té un tram gratuït, però els costos pugen de pressa. Auth0 és gratuït fins a 7.000 usuaris. Són costos insignificants al principi, però creixen amb la teva base d'usuaris.
Hosting i infraestructura: una app petita pot funcionar amb 50-100 euros al mes. Una app amb trànsit real, base de dades relacional i workers en segon pla pot arribar fàcilment als 500-1.000 euros mensuals.
Domini, SSL, email transaccional: costos petits per separat (10-50 euros al mes en total) que van sumant.
Processador de pagaments: si cobres als teus usuaris, el processador es queda una part. Inclou-la al teu model financer.

Regla pràctica: si el teu MVP costa 30.000 euros de desenvolupar, pressuposta'n com a mínim 40.000 per al primer any complet (desenvolupament + 6 mesos d'operació i manteniment).

Preu tancat vs time & materials

Hi ha dos models estàndard de facturació en desenvolupament de programari. Cadascun té els seus avantatges:

Preu tancat (fixed price):

Saps exactament què pagaràs abans de començar.
El risc de passar-se del pressupost recau sobre el proveïdor.
Funciona bé quan l'abast està molt ben definit i no canviarà.
El problema: incentiva el proveïdor a escatimar per protegir el marge. I qualsevol canvi d'abast implica renegociar.

Time & materials (per hores/sprints):

Pagues pel temps realment dedicat.
Màxima flexibilitat per canviar prioritats sobre la marxa.
Funciona bé quan vas descobrint el producte mentre el construeixes (que és el que passa amb la majoria d'MVP).
El problema: sense un sostre clar, els costos es poden disparar. Necessites visibilitat setmanal de la despesa i disciplina per retallar.

La meva recomanació per a MVP: time & materials amb sprints curts (2 setmanes) i un pressupost màxim pactat. Tens la flexibilitat per pivotar, però amb un sostre que no superaràs.

Com reduir el cost del teu MVP

No tots els euros es gasten igual. Per la meva experiència, aquestes decisions et poden estalviar un 30-40% sense sacrificar qualitat:

Fes servir frameworks i plantilles existents. No construeixis un design system des de zero. Fes servir Tailwind, shadcn/ui o un kit de components provat. La majoria d'interfícies d'MVP són formularis, taules i dashboards — no necessiten disseny a mida.
Autenticació estàndard. Construir l'auth pel teu compte és car i arriscat. Auth0, Clerk o Supabase Auth et donen un login segur en hores, no en setmanes.
Infraestructura gestionada. Vercel, Railway, Render o Fly.io. No muntis el teu propi clúster de Kubernetes per a un MVP. Gastaràs més en DevOps que en producte.
Comença només amb web. Si el teu producte pot funcionar com a web app, no construeixis app mòbil per a l'MVP. Sempre hi pots afegir mòbil més endavant, si valides la idea. Una PWA cobreix la majoria de casos d'ús.
Prioritza la funcionalitat per davant del poliment. Els primers usuaris perdonen un disseny imperfecte si el producte els resol el problema. No perdonen un producte bonic que no funciona.

Senyals d'alerta en les propostes de desenvolupament

Quan rebis pressupostos, desconfia de:

Preus irrealment baixos. Si tres proveïdors et pressuposten entre 30.000 i 45.000 i un et diu 8.000, aquest proveïdor o no ha entès l'abast o escatimarà en coses que pagaràs més endavant.
Ni una paraula sobre el testing. Si el pressupost no inclou QA, qui verificarà que el programari funciona? Tu, el fundador, a les onze de la nit.
Cap pla de desplegament. «T'entreguem el codi» no és un pla. On es desplega? Qui configura l'entorn? Hi ha CI/CD?
«Ja ho anirem veient sobre la marxa.» La flexibilitat és bona. La manca de planificació disfressada de flexibilitat és el camí directe al desastre.
Cap estimació desglossada. Un pressupost que diu «MVP: 40.000 euros» sense desglossar per mòduls o funcionalitats no et permet decidir amb criteri què retallar si has de reduir l'abast.

Pressuposta amb realisme, no amb optimisme

L'error més car del desenvolupament de programari és l'optimisme sense fonament. «Segur que trigarà menys del que s'ha estimat» — no, no trigarà menys. «Segur que els primers mesos no necessitarem manteniment» — sí que en necessitaràs. «Segur que els costos d'infraestructura seran mínims» — potser, però probablement no.

A Conectia, quan un fundador ens porta un projecte, la primera cosa que fem és una sessió de scoping tècnic amb un CTO. No per vendre't més hores, sinó per definir exactament què es construeix, què no, i quant hauria de costar de manera realista. Aquest scoping evita la majoria de sorpreses que apareixen a mig projecte.

Construir un MVP no hauria de ser una aposta. Hauria de ser una inversió calculada, amb un pla clar de què es construeix, quant costa i quan estarà a punt.

Estàs planificant el teu MVP i vols un scoping tècnic realista? Parla amb un CTO — t'ajudem a definir l'abast, les prioritats i el pressupost abans d'escriure una sola línia de codi.