El desarrollo de un MVP consiste en construir la app más pequeña capaz de responder a la pregunta que tu negocio tiene de verdad: si alguien lo usará, si pagará por ello, si el flujo que imaginaste es el que la gente quiere. Se diferencia del desarrollo corriente en algo estructural: el entregable no es un conjunto de funcionalidades, es una respuesta. Todo lo que no te acerca a esa respuesta es alcance que pagas dos veces, una por construirlo y otra por mantenerlo hasta que lo borres.

Un en Flutter suele llevar dos o tres meses desde el arranque hasta estar publicado, y cuesta 12-24 mil €. Ambas cifras son las de nuestra guía de costes, y adónde van esos meses, fase a fase, está en nuestro desglose de plazos: preferimos publicarlas y que nos las rebatas a abrir con un «depende».

Flutter importa más en esta etapa que en ninguna otra. Un MVP pone a prueba la demanda, no las plataformas, y no sabes de antemano de qué tienda llegarán tus primeros cien usuarios reales. Una sola base de código lo pone en las dos, que es la diferencia entre validar una idea y validar una idea en Android.

Qué incluye un MVP

  • 5-8 funcionalidades principales: aquellas de las que depende la pregunta, y ninguna más
  • iOS y Android, desde una base de código y un equipo
  • Un backend gestionado en lugar de uno escrito desde cero, salvo que el producto exija de verdad lo contrario
  • Interfaz con componentes de librería: Material y Cupertino, estilizados y no redibujados, para que el diseño no esté en el camino crítico
  • Analítica e informes de fallos desde el primer día, porque un MVP sin instrumentación no responde a nada
  • Ficha en ambas tiendas, con el trabajo de envío tratado como una fase y no como un botón

Quién construye tu MVP

Dos cosas separan a un equipo capaz de entregar un MVP de otro que construye apps.

Un producto completo, diseñado y entregado en siete semanas

OneTwoDo es un marketplace de dos lados de servicios locales para Perform Connect Studios S.L.: anuncios de limpieza, reformas, fontanería y demás, publicados y consultados por gente del mismo barrio. Lo construimos de principio a fin: diseño de producto, cliente Flutter y toda la infraestructura sobre la que funciona. Siete semanas.

Encaja aquí por cómo se acotó. Un marketplace de dos lados normalmente implica un equipo de backend antes que ninguna otra cosa —cuentas, sesiones, una base de datos de anuncios, almacenamiento de fotos, un servidor detrás de todo ello—, y ahí es donde se van los tres primeros meses de un equipo pequeño. OneTwoDo salió sin escribir esa capa: Firebase Authentication para las cuentas, Firestore para anuncios y perfiles, Cloud Storage para las fotos, Analytics y Crashlytics en lugar de los cuadros de mando que habría habido que construir. Nada que aprovisionar, parchear ni poner de guardia.

Esa decisión es la que permitió a un solo equipo llevar diseño, cliente y backend a la vez, y siguió dando réditos: precios multidivisa, descripciones localizadas por anuncio y un feed filtrado por idioma y ubicación fueron trabajo de cliente sobre una capa de datos que ya existía, en lugar de un ticket de backend seguido de uno de cliente. El relato completo está en el caso de OneTwoDo.

Publicamos las cifras en lugar de decir «depende»

Cualquier agencia responde a «cuánto tarda» y «cuánto cuesta» con un rango tan ancho que no sirve de nada. Las nuestras están en esta página, en la de desarrollo de apps con Flutter y desglosadas fase a fase en Cuánto se tarda en desarrollar una app Flutter y Cuánto cuesta desarrollar una app en Flutter en 2026. Si tu proyecto no encaja en ellas, te lo diremos al acotarlo, que es el único momento en que esa información te vale de algo.

Otras cosas que hemos entregado a este tamaño: Arcana, un compañero de tarot con IA cuyo cliente Flutter —un chat en streaming que sostiene miles de mensajes a 60 fps— llevó tres semanas; y hemos publicado además el plan de seis semanas para convertir un bot de Telegram con audiencia ya formada en una app publicada en las tiendas; ese es un compuesto de trabajo que hemos hecho y no un único cliente, y es rápido precisamente porque la pregunta de producto ya estaba respondida en otro sitio.

Qué exige de verdad un MVP

Seis cosas deciden si un MVP sale en tres meses o se convierte en un proyecto que triplica lo que se planificó.

Una lista de recortes que de verdad respetas

El extremo de dos meses es real, pero condicional: un alcance que cabe en una página, una persona que pueda aprobar una decisión sin convocar a un comité, y ningún riesgo técnico novedoso —nada de pipeline de vídeo, aprendizaje automático en el dispositivo o pasarelas de pago en una jurisdicción nueva—. Tres meses es el resultado más frecuente, y el mes extra casi nunca es «el código era más difícil». Es un flujo de pago que apareció en la semana cuatro, una ronda de diseño no presupuestada o dos semanas esperando acceso a una API.

Por eso la lista de recortes es el entregable del acotado, no una nota al pie. Escribimos lo que queda fuera con la misma claridad que lo que queda dentro, y pondremos objeciones a los añadidos a mitad de construcción: no por incordiar, sino porque cada pequeño añadido es una semana, y cuatro pequeños añadidos son la diferencia entre lanzar este trimestre y el siguiente.

El alcance que no ves

«Una app sencilla para registrar entrenamientos» son cinco pantallas en tu cabeza. En la práctica son onboarding, autenticación con email, Google y Apple —cada una con sus casos límite—, la funcionalidad en sí, ajustes, perfil, borrado de cuenta (obligatorio en ambas tiendas) y un flujo de pago si está monetizada. Nada de eso sobra, y nada de eso es lo que tenías en mente cuando describiste la app.

Nombrarlo pronto es buena parte de lo que significa acotar bien. Es también donde ocurre la conversación honesta sobre el rango: el alcance invisible es más o menos constante, así que consume una porción mucho mayor de una construcción de dos meses que de una de seis.

Un backend que no escribiste desde cero

Para la mayoría de los MVP un backend gestionado no es una concesión, es la decisión de ingeniería correcta, y OneTwoDo es la prueba. Firebase, Supabase o un servicio ligero sobre una base de datos gestionada cubren cuentas, datos, ficheros y analítica sin un equipo que los opere, y escalan mucho más allá del punto en que un MVP ya ha respondido a su pregunta.

Cuándo desaconsejamos esto: cuando el núcleo del producto es algo que un backend gestionado no sabe hacer —lógica de negocio pesada, en tiempo real a escala, un régimen normativo que dicta dónde residen físicamente los datos—. Te diremos en qué lado estás antes del presupuesto, porque mueve la cifra.

Instrumentación, o el MVP no responde a nada

Un MVP existe para producir evidencia. Publicarlo sin analítica, sin informes de fallos y sin un conjunto definido de eventos es gastarse el presupuesto entero y recibir a cambio una opinión en lugar de datos. Acordamos al acotar los pocos eventos que corresponden a tu pregunta real —activación, la acción central, el abandono que te preocupa— y los cableamos antes del lanzamiento, no después de que la primera cohorte haya venido y se haya ido.

Lo que nos negamos a recortar

Un MVP gana velocidad recortando funcionalidades, no recortando ingeniería. Lo que se queda, sea cual sea el alcance: fronteras entre módulos que permitan a la v2 crecer sin una reescritura, desde la primera semana para que compilar sea un solo comando, pruebas en los caminos donde equivocarse cuesta dinero, y estados de error con nombre en vez de un spinner que nunca termina.

Esta es la diferencia entre un MVP y un prototipo, y conviene ser preciso. Un prototipo es desechable por diseño. Un MVP es la primera versión de un producto que piensas conservar, así que el código tiene que ser código conservable. Y la razón por la que «ya lo limpiaremos después del lanzamiento» casi nunca ocurre es que un producto validado genera de inmediato trabajo más urgente que la limpieza.

El envío a las tiendas es una fase

Presupuesta una o dos semanas. La revisión en sí suele durar de 24 a 48 horas, pero el trabajo que la rodea no: fichas de tienda, capturas para cada uno de los tamaños de dispositivo exigidos, una política de privacidad y las declaraciones de datos que ambas tiendas exigen ya, y una vía de borrado de cuenta que Apple comprobará. Los equipos que descubren esto en la última semana llegan tarde por motivos que no tienen nada que ver con su app.

Por qué Flutter para un MVP

El argumento honesto a favor de Flutter aquí:

RequisitoCómo lo aborda Flutter
Ambas tiendas con un solo presupuestoUna base de código, en torno a un 30-40 % menos que dos desarrollos nativos: la mayor palanca de coste una vez fijado el alcance
Iterar mientras los usuarios miranHot reload en menos de un segundo: un cambio llega al dispositivo antes de que arranque una recompilación nativa
Diseño fuera del camino críticoLos widgets de Material y Cupertino sostienen la interfaz hasta que te hayas ganado un sistema de diseño propio
Un solo equipo que contratarIngenieros Flutter, no un equipo de iOS más uno de Android más la coordinación entre ambos
v2 sin reescrituraLa base de código del MVP es la del producto: la misma app crece hasta el nivel de negocio en vez de ser sustituida

Dónde sigue ganando lo nativo: si la pregunta que validas es una capacidad específica de la plataforma —una experiencia profunda en Apple Watch, un producto construido alrededor de widgets, algo construido sobre una API que solo existe en una plataforma—, entonces el ahorro multiplataforma no viene al caso y lo nativo puede ser la respuesta honesta. Te lo diremos cuando sea así. La página general del servicio es desarrollo de apps con Flutter.

Cómo trabajamos

Proyecto de MVP con alcance cerrado. Nos hacemos cargo de la entrega de principio a fin: descubrimiento, diseño, arquitectura, construcción y envío a tiendas. Mejor cuando quieres delegar un alcance definido y tener un equipo responsable de la fecha de lanzamiento. Nuestro proceso de desarrollo describe cómo se ve semana a semana.

De prototipo a producción. Si ya tienes algo funcionando —una construcción con Cursor, Bolt o Lovable, o un fin de semana largo con un agente de IA—, puede que la pregunta de producto esté ya parcialmente respondida, y el trabajo es otro: una auditoría primero, y después el hueco entre «funciona en la demo» y «es seguro delante de usuarios reales». Esa vía es la auditoría de código IA, y el manual está en Llevar un prototipo hecho con IA a producción.

Ampliación de equipo. Nuestros ingenieros se incorporan a tu equipo, en tu repositorio y tus sprints, bajo tu gestión. Mejor cuando ya tienes liderazgo técnico y necesitas capacidad en Flutter: mira ampliación de equipo y nuestra guía para contratar desarrolladores Flutter, que es honesta sobre cuándo no contratarnos.

Sea cual sea la vía, enviamos un presupuesto detallado en un plazo de dos días laborables desde que entendemos los requisitos.

Preguntas frecuentes

Lo que más nos preguntan los fundadores que están acotando un primer lanzamiento en Flutter.

Un producto mínimo viable es la app más pequeña capaz de responder a una pregunta concreta del negocio: si la gente lo usará, si pagará, si ese es el flujo que quiere. El énfasis va en viable y no en mínimo: tiene que ser lo bastante bueno como para que la reacción de un usuario real signifique algo, y por eso un MVP no es un prototipo ni una maqueta clicable. En la práctica son de 5 a 8 funcionalidades principales, un backend de verdad, analítica conectada a la pregunta que estás haciendo y una ficha publicada en las tiendas. Todo lo demás es alcance que pagas dos veces, una por construirlo y otra por mantenerlo hasta que lo borres.
De dos a tres meses desde el arranque hasta la ficha publicada, para un MVP en Flutter sobre iOS y Android. El extremo de dos meses es real pero condicional: un alcance que cabe en una página, una persona que aprueba decisiones sin comité y ningún riesgo técnico novedoso como un pipeline de vídeo, aprendizaje automático en el dispositivo o pasarelas de pago en una jurisdicción nueva. Tres meses es más habitual, y el mes extra rara vez es la ingeniería. Es un flujo de pago que apareció en la semana cuatro, una ronda de diseño no presupuestada o dos semanas esperando acceso a la API de otro.
Nuestro nivel de MVP está publicado en esta página y en la de desarrollo de apps con Flutter, en lugar de darse en privado, y cubre de 5 a 8 funcionalidades en iOS y Android con un backend gestionado y una interfaz de componentes de librería. Lo que mueve la cifra es el alcance primero y las integraciones después: cada integración de terceros relevante supone una o dos semanas, y el alcance invisible de onboarding, autenticación, ajustes, borrado de cuenta y pagos es más o menos constante, así que se lleva una porción mayor de una construcción pequeña que de una grande. El desglose completo está en nuestra guía sobre el coste de desarrollo con Flutter.
Dentro: las funcionalidades de las que depende la pregunta, un camino limpio a través de ellas, analítica en los momentos que la responden y la fontanería que las tiendas no te dejan omitir, que incluye una vía de borrado de cuenta. Fuera: el segundo rol de usuario, el panel de administración que podrías llevar en una hoja de cálculo durante seis meses, el sistema de diseño propio, el modo sin conexión y toda funcionalidad justificada por un usuario que aún no has conocido. La prueba útil es si quitar algo cambia lo que aprendes del lanzamiento. Si no lo cambia, es v2, y escribir esa lista es el entregable del acotado, no una nota al pie.
No, si se construyó como un MVP y no como un prototipo. Un prototipo es desechable por diseño; un MVP es la primera versión de un producto que piensas conservar, así que debe llevar fronteras entre módulos que permitan crecer a las funcionalidades, integración continua desde la primera semana, pruebas en los caminos donde equivocarse cuesta dinero y estados de error de verdad. Eso cuesta días, no semanas, y es la diferencia entre que la v2 sea una ampliación y que sea empezar de nuevo. Lo que sí recortamos por velocidad son funcionalidades, singularidad del diseño e infraestructura que se puede alquilar; nunca la estructura del código.
Sí, y cada vez es más frecuente que los proyectos empiecen así. Una construcción con Cursor, Bolt o Lovable suele significar que la pregunta de producto está ya parcialmente respondida, lo cual vale de verdad, pero el hueco entre funcionar en una demo y ser seguro delante de usuarios reales es concreto y previsible, y se agrupa en claves expuestas y autorización ausente, llamadas a API sin caché que multiplican el gasto, y datos sensibles que acaban en logs o en terceros. La ruta en ese caso es auditar primero y después hacer el trabajo de publicación, en lugar de una reconstrucción que tira lo que ya has aprendido.
Normalmente sí, y este es el argumento más fuerte a favor de Flutter justo en esta etapa. Un MVP pone a prueba la demanda, no las plataformas, y rara vez sabes de antemano de qué tienda llegan tus primeros usuarios reales, así que publicar en una sola es validar tu idea con la audiencia de una plataforma y conjeturar sobre la otra. Como una única base de código Flutter produce ambas apps, el coste marginal de la segunda tienda es pequeño, que es exactamente el intercambio que quiere un primer lanzamiento. La excepción es un producto cuyo núcleo es una capacidad específica de la plataforma, donde el ahorro multiplataforma no viene al caso.

Lee el desglose fase a fase en Cuánto se tarda en desarrollar una app Flutter, o mira el caso de OneTwoDo para ver un producto completo diseñado y entregado en siete semanas.