Firebase para apps móviles: experiencia de un dev en solitario

En 2023, lancé mi primera app móvil en solitario - TaleMe - apostando a fondo por el dúo Flutter + Firebase. Dos años más tarde, la conclusión es clara: Firebase me permitió sacar una V1 a la velocidad de la luz, pero con la perspectiva de 2025 también veo dónde duele.

En este artículo, comparto mi experiencia sincera como desarrollador en solitario: lo que Firebase hace muy bien para desarrollar una app móvil, dónde empecé a desanimarme, y cómo abordaría las cosas de forma diferente hoy.

Contexto : por qué elegí Firebase en 2023

Desarrollador web de formación (front y back), en 2023 quise crear TaleMe, una app móvil basada en IA para contar historias a los niños. Siendo el único desarrollador y sin experiencia previa en mobile, mi objetivo para la V1 era simple: lanzar rápido y bien. Necesitaba las funciones "núcleo" de la app, un sistema de autenticación de usuario seguro, y un paywall para la suscripción (para validar el modelo de negocio). No era cuestión de pasar meses reinventando la rueda.

¿Por qué Firebase? En 2023 fue una elección obvia para mí. Firebase cumplía todos los requisitos: base de datos en la nube en tiempo real, auth listo para usar, almacenamiento de archivos, funciones servidor… todo "serverless" (cero servidores que desplegar o mantener) e integrado de forma nativa con Flutter mediante plugins oficiales. Además, la generosa oferta gratuita permitía empezar sin costes inmediatos, ideal para un MVP. Para la monetización también opté rápidamente por un servicio externo (RevenueCat) para implementar compras in-app sin complicaciones. En resumen, con Flutter para el frontend y Firebase para el backend, todas las piezas estaban ahí para lanzarme a toda velocidad.

Spoiler: acerté al insistir en la velocidad: pude programar y publicar una primera versión en apenas 4 semanas (validación en tienda incluida) a pesar de mi cero experiencia en mobile al inicio. ¡Misión cumplida para la V1! Pero, ¿y a largo plazo? Entremos en materia: ¿qué me aportó Firebase… y a qué precio?

Ce que Firebase hace très bien pour une app mobile

⏩ Time-to-market imbattable

El primer punto fuerte de Firebase es que acelera el desarrollo. Combinando Firebase con Flutter, pude "bootstrapear" mi app en un tiempo récord. Google no exagera: "Integrar Firebase con tus apps Flutter te permite salir al mercado y ofrecer valor a tus usuarios […] en menos tiempo y con menos esfuerzo.". En la práctica, casi no tuve que programar un backend "clásico". Base de datos, autenticación, hosting de medios, todo está disponible on demand en forma de servicios a activar. En 2023, siendo solo, fue claramente la forma más rápida de pasar de la idea a la app funcionando. Sin Firebase (y Flutter) habría llevado mucho más tiempo.

🤝 Integración con Flutter y DX de primera

Firebase también destaca por su excelente integración con Flutter y su experiencia de desarrollador (DX) cuidada. Los plugins oficiales FlutterFire cubren prácticamente todos los productos Firebase, con documentación a menudo bien hecha y una comunidad reactiva. No tuve problema en añadir Firebase a mi proyecto Flutter: un comando de CLI FlutterFire, algunas configuraciones, y tenía acceso a toda la gama de servicios.

Resultado: pude concentrarme en el código de negocio de mi app, y no en el cableado de la infraestructura. El hecho de permanecer en el ecosistema Dart/Flutter del lado cliente hace el desarrollo fluido.

Cierto, para el backend (Cloud Functions) hubo que escribir en TypeScript (volveré sobre esto), pero del lado de la app Flutter, la experiencia de desarrollador es muy agradable. Se nota que Firebase está pensado para que un dev en solitario o un equipo pequeño pueda ser productivo sin pelearse con la herramienta.

🧰 Suite de productos integrados muy prácticos

Otra ventaja de Firebase: es un ecosistema todo-en-uno. Al añadir Firebase, desbloqueé todo un surtido de servicios secundarios muy útiles para una app móvil, sin esfuerzo de integración adicional:

• Crashlytics (informe de fallos) - Incluido por defecto. Pude recibir reportes de errores en producción desde el inicio, crucial para corregir bugs rápidamente. No hubo necesidad de conectar Sentry u otro, todo ya estaba en la consola de Firebase.
• Analytics (Google Analytics for Firebase) - Para entender el comportamiento de los usuarios. En unos pocos clics tenía dashboards sobre retención, pantallas vistas, etc. Súper útil para orientar las iteraciones de producto.
• Cloud Messaging (FCM) - Enviar push notifications gratis, multiplataforma. De nuevo, unas pocas líneas de configuración en la app, una función Cloud en el servidor, y pude notificar a mis usuarios (por ejemplo para novedades).
• Remote Config / A/B Testing - La posibilidad de activar feature flags de forma remota o probar variantes de una funcionalidad. Aunque lo usé a pequeña escala, saber que está disponible "out of the box" da confianza para evolucionar la app sin repushs constantes.
• Performance Monitoring, App Distribution, etc. - Firebase ofrece un montón de herramientas extra (perf, beta-test, etc.) integradas de forma nativa. No las usé todas al principio de TaleMe, pero es un verdadero confort saber que se pueden activar cuando haga falta, sin buscar decenas de servicios externos.

En suma, Firebase actuó como una "navaja suiza" del desarrollo móvil para mí. Para un dev en solitario que debe gestionar todo, tener todas estas herramientas a mano e integradas entre sí (ej.: crashes y analytics en el mismo sitio, notificaciones ligadas al auth de Firebase, etc.) me hizo ganar un tiempo enorme. Time-to-market +1, sin duda.

Là où ça commence à coincer...

Evidentemente, el panorama no es totalmente idílico. A medida que TaleMe pasó de simple POC a producto en producción con usuarios reales, descubrí ciertos límites y escollos de mi elección "todo Firebase". Aquí los principales puntos de fricción que encontré:

📦 Un POC que devient prod (aka la deuda técnica del « todo Firebase »)

Al principio estructuré mi app de forma bastante simple, modo prototipo. Toda la lógica giraba en torno a Firestore (mi base NoSQL) y algunas Cloud Functions. Honestamente, en su momento no pensé mucho en la arquitectura: Firebase fomenta un poco el "plug and play". Pero con el tiempo ese enfoque me alcanzó.

Lo que funcionaba de maravilla en modo MVP se complicó conforme añadía funcionalidades. La lógica de negocio (generación de historias por IA, gestión de contenidos, etc.) quedó esparcida entre el código Flutter del cliente y Cloud Functions del servidor. Es el síndrome del "todo en Firebase": se arranca rápido, pero puedes acabar con una mezcla de reglas de seguridad de Firestore, triggers serverless y código cliente poco modular.

Para dar un ejemplo concreto: inicialmente, la subida de archivos (las imágenes/videos generados por la IA) se hacía directamente desde el cliente a Firebase Storage. Sencillo… pero insuficiente cuando quise verificar al usuario, procesar los medios en el servidor (transcripción, miniatura…) y llamar de forma segura a la API de OpenAI. Tuve que implementar la subida vía una Cloud Function HTTP que recibe el archivo y ejecuta esos tratamientos antes de almacenar todo. Técnicamente funciona muy bien (incluso escribí un tutorial al respecto), pero ilustra cómo un pequeño POC frontend acaba requiriendo un backend considerable. Me vi acumulando Cloud Functions para suplir las limitaciones del "todo cliente" (y alternando entre el código Dart de la app y el TypeScript de las funciones).

🔄 Cloud Functions : deux écosystèmes à maintenir

Hablemos de las Cloud Functions de Firebase. Es una funcionalidad genial (ejecutar código backend sin gestionar servidores, ¡un sueño!), pero al avanzar descubrí un inconveniente para un dev Flutter: todas las funciones deben escribirse en JavaScript/TypeScript (o Python en beta) — no en Dart. En la práctica, imposible compartir código entre mi app Flutter y mi backend Firebase; tuve que mantener dos bases de código en dos lenguajes distintos. Cuando trabajas solo, ese context-switch constante tiene un coste en velocidad y fiabilidad.

En mi caso dominaba JS y TS, pero tener que reescribir ciertas estructuras de datos o reglas de validación en TS en el servidor, cuando ya las tenía en Dart en el cliente, fue frustrante. Sin mencionar las distintas herramientas de testing, y el debug menos cómodo (los logs de Cloud Functions vs debug directo en el emulador Flutter no es lo mismo).

En resumen: añadir Cloud Functions por todas partes fue necesario, pero con el tiempo sentí cómo crecía una deuda técnica y una complejidad mayor para hacer evolucionar el backend.

Un POC puede convertirse en una «pequeña fábrica» si no se tiene cuidado.

🗄️ Modelo NoSQL y vendor lock-in

Firebase = Firestore (NoSQL) y al principio no medí totalmente sus impactos. Me atrajo la flexibilidad del NoSQL: sin esquema fijo, guardas documentos JSON y vas viendo.

Genial mientras prototipas.

Pero cuando la app maduró, noté las limitaciones de una base NoSQL para datos más estructurados. Por ejemplo, tuve que hacer consultas cada vez más complejas (cruzar colecciones, filtrar por varios campos, etc.) y Firestore no es muy fan de eso. Terminas duplicando datos para compensar la ausencia de verdaderos joins, multiplicando pequeñas consultas en el cliente y gestionando la coherencia tú mismo.

Como resume la documentación de Supabase : « El diseño sin esquema de Firestore facilita prototipar. A medida que las relaciones de datos se vuelven más complejas, debes manejar los joins en el cliente o desnormalizar tus datos. ». ¡Tan cierto! Con retrospectiva, ciertos datos de TaleMe probablemente habrían estado mejor en una base SQL clásica...

Hablando de Supabase, es imposible no mencionar el vendor lock-in de Firebase. Al empezar no se piensa mucho en ello ("ya veremos si escala").

Pero en 2025, con una base de usuarios en crecimiento, me doy cuenta de lo dependiente que soy de Google Firebase. Migrar a otro lado (por ejemplo a un servidor propio o a otro BaaS) sería un proyecto colosal. No es solo paranoia: exportar datos de Firestore a una base SQL no es sencillo (aunque existen herramientas de migración hacia Supabase o AWS).

La dependencia al ecosistema Firebase es real: APIs propietarias (Firestore, FCM, etc.), reglas de seguridad específicas... Cuanto más tiempo pasa, más difícil es "salir", así que te quedas, a veces aceptando ciertos compromisos técnicos.

Lo pienso en serio hoy en día (de ahí este artículo).

💸 Costes ocultos : la cuenta en perf y presupuesto

Por último, y no menos importante: Firebase no es gratis para siempre, y su facturación puede volverse un rompecabezas mental. Al inicio, todo entraba en el free tier.

Pero el éxito (aunque modesto) trae uso creciente, y ahí empiezas a vigilar tus lecturas/escrituras en Firestore, invocaciones de Cloud Functions, almacenamiento, ancho de banda, etc.

La facturación por uso de Firebase no siempre es predecible, y pueden surgir sorpresas si no optimizas.

Por ejemplo, una consulta mal diseñada que multiplica lecturas de documentos puede hacer explotar el contador. O una Cloud Function llamada con demasiada frecuencia puede exceder los cuotas gratuitos. Los testimonios abundan : « El precio de Firebase puede volverse caro a medida que tu aplicación escala, llevando a algunos desarrolladores a buscar alternativas más rentables… ».

En mi caso no he (todavía) reventado el presupuesto, pero la carga mental de estar siempre pensando en "optimización de costes" está ahí. He dedicado tiempo a pulir reglas de caché, agrupar writes en batch, monitorizar dashboards de uso para evitar sorpresas a fin de mes. Tiempo no dedicado a desarrollar features.

En cuanto a rendimiento, también lidié con las limitaciones de Firestore (sin búsquedas full-text, índices que hay que configurar o ciertas queries fallan o van lentas). Y los famosos cold starts de las Cloud Functions introdujeron latencias en ciertas pantallas.

Nada insuperable, pero una acumulación de pequeños "rozamientos" que hacen que en 2025 sea mucho más consciente de los costes reales de Firebase, tanto financieros como cognitivos.

Ce qui change en 2025

Han pasado dos años desde el lanzamiento inicial, y obviamente mi perspectiva ha cambiado.En 2025:

• Aumento de habilidades: Ya no soy el mismo dev de 2023. A base de trastear con Flutter/Firebase y evolucionar TaleMe, he aprendido mucho sobre mobile, arquitectura de apps, etc. He ganado expertise y confianza en temas que me parecían complejos en 2023.
• La IA como copiloto: El panorama del desarrollo también ha cambiado. Vivimos en plena revolución de AI Copilot & compañía, que facilita la vida a los devs en solitario. ¿Necesitas generar un fragmento de backend en Express, escribir un script de migración, encontrar una consulta SQL? Agentes IA pueden hacernos gran parte del trabajo. Lo que en 2023 parecía excesivo de codificar desde cero, en 2025 lo es menos porque estamos mejor equipados.
• Nuevas prioridades: testabilidad, portabilidad, robustez: Con la perspectiva, doy más importancia a aspectos arquitectónicos. Por ejemplo, la testabilidad: en 2023 probaba poco mis Cloud Functions (no es fácil mockear Firestore), ahora sueño con un backend donde pueda escribir tests unitarios e integrados fácilmente. Igual para la portabilidad y la robustez: vi los límites del lock-in y de las soluciones demasiado propietarias, así que aspiro a elecciones técnicas más abiertas (base SQL estándar, posibilidad de desplegar en otro cloud, etc.). En resumen, busco construir bases más perennes y mantenibles, aunque suponga sacrificar un poco la rapidez inicial. Es el eterno compromiso del dev: lo que ahorra tiempo al principio puede costar más después.

En resumen, mi mirada cambió: Firebase sigue siendo una herramienta fantástica, pero ahora la veo como una pieza entre otras, a usar con conciencia dentro de una arquitectura pensada, en vez de como un paquete "mágico" que lo hace todo sin consecuencias.

A partir de ahí, ¿cuáles son mis recomendaciones en 2025 para un dev en solitario que debe elegir su stack?

Mes recommandations actuelles (solo dev en 2025)

Si tuviera que aconsejar a un desarrollador independiente que empieza hoy una app móvil, así abordaría la stack backend:

Option 1 : Combo Firebase + backend dédié (meilleur des deux mondes)

Probablemente es la arquitectura que adoptaría para cualquier proyecto nuevo algo ambicioso. La idea: usar Firebase para lo que hace mejor, y delegar el resto a un backend "propio" (o un microservicio dedicado). En la práctica, se puede mantener Firebase Auth (tan fácil de integrar y robusto), Cloud Messaging (para push) y por qué no Crashlytics/Analytics.

Pero para la lógica de negocio avanzada, los procesos sensibles (llamadas a APIs externas como OpenAI, cálculos complejos, etc.) y la gestión fina de datos, desplegaría un pequeño backend API REST/GraphQL separado.

Puede ser un servidor Node/Express, NestJS, Python FastAPI, da igual: lo importante es tener la libertad de codificar la lógica limpiamente sin las restricciones de las Cloud Functions.

Ese backend podría usar una base de datos SQL clásica u otro almacenamiento adaptado.

Firebase y este backend se comunicarían vía HTTPS u otro. Sí, pide un poco más de trabajo que un Firebase completo... pero evita forzar Firebase en cosas para las que no es óptimo.

Mantienes el time-to-market en las piezas genéricas gracias a Firebase, y a la vez la máxima control sobre el núcleo. En solitario en 2025 es factible gracias a las herramientas modernas (se puede prototipar una API en pocos días ahora, con la ayuda de la IA).

Option 2 : Supabase (ou autre BaaS SQL) pour un backend plus ouvert

Otra opción relevante en 2025: optar por un BaaS alternativo a Firebase, basado en SQL. El principal candidato es Supabase, que recrea la experiencia Firebase (auth, storage, funciones serverless, realtime…) pero sobre PostgreSQL open-source. Supabase ofrece, en esencia, "los mismos servicios - auth, storage, realtime, functions - pero con la previsibilidad del SQL y la libertad del self-hosting".

Dicho de otro modo, disfrutas de un esquema relacional clásico (consultas potentes, joins, transacciones ACID, etc.), puedes hospedar la solución por tu cuenta si quieres (sin lock-in propietario), y mantienes funcionalidades comparables (realtime, API auto-generada, etc.).

Para un dev en solitario que empieza, Supabase puede ser un excelente compromiso: recuperas la simplicidad de un BaaS sin algunas limitaciones de Firebase. Claro, hay que sentirse más cómodo con SQL que con NoSQL, y el ecosistema Supabase es un poco menos maduro (más joven, más pequeño que Firebase). Pero honestamente, la curva de aprendizaje de SQL/Postgres merece la pena desde que tus datos tienen algo de estructura.

Existen otros BaaS similares (Appwrite, PocketBase, Parse... incluso soluciones cloud como AWS Amplify), pero Supabase es el que más destaca hoy como reemplazo de Firebase entre muchos devs. En 2025 lo probaría seriamente si volviera a empezar TaleMe — al menos para evitar el lock-in y beneficiarme de una base relacional desde el principio.

Option 3 : Rester sur Firebase, mais découpler proprement

Y si, a pesar de todo, quieres aprovechar al máximo Firebase (al fin y al cabo, su integración con Flutter sigue siendo excelente, y para una app pequeña se puede convivir con sus limitaciones), te aconsejaría hacerlo anticipando el futuro. Eso significa: desacoplar al máximo tu lógica de negocio de Firebase mismo.

Concretamente, incluso quedándote en Firestore y Cloud Functions, puedes adoptar buenas prácticas arquitecturales: usar repositorios en la app Flutter para aislar las llamadas a Firebase (en vez de dispersar .doc().get() por la UI), estructurar tus Cloud Functions de forma modular (evitar una única función enorme de 1000 líneas que lo hace todo), escribir tests unitarios con el Emulator Suite de Firebase para validar reglas de seguridad y funciones, etc.

El objetivo es hacer posible (o menos doloroso) un cambio futuro. Por ejemplo, si tu capa de acceso a datos está bien aislada, migrar de Firestore a Postgres requerirá modificar solo esa capa, no toda la app.

Igual, si tu lógica de negocio está en funciones bien encapsuladas, podrías decidir reimplementarlas en otro backend sin reescribirlo todo. En resumen, "quedarse en Firebase no implica quedarse encerrado". Es la trampa clásica de lanzarse a lo loco y pegar Firebase por todas partes en el código. En 2025, con experiencia, intentaría pensar en mi arquitectura desde el inicio incluso usando Firebase: un poco de diseño hoy para mucha libertad mañana.

Ce que je ferais différemment pour TaleMe (si c'était à refaire)

Para ser muy concreto, si pudiera retroceder en el tiempo y aconsejar al yo de 2023 sobre TaleMe, esto cambiaría (y mantendría) respecto a Firebase:

Lo que mantendría sin dudar:

• Firebase Authentication - Es un enorme ahorro de tiempo y es ultra fiable. Gestionar registro, login (email, Google, Apple…), recuperación de contraseña, etc., habría sido una pérdida de tiempo y un riesgo de seguridad hacerlo por mi cuenta. Firebase Auth hace el trabajo a la perfección; lo volvería a usar en 2025.
• Crashlytics & Analytics - Indispensables para cualquier app en producción. Integrados gratis, estos servicios me permitieron detectar crashes (Crashlytics) y entender el uso (Analytics) fácilmente. Los consideraría must-have independientemente del backend.
• Flutter + Firebase (integración cliente) - El SDK FlutterFire en el cliente está bien mantenido y permite sacar provecho de Firebase con muy poco código. Si necesito realtime (p.ej. sincronizar datos entre usuarios) o almacenar datos simples, Firestore sigue siendo muy práctico vía Flutter. Igual para Firebase Cloud Messaging (push notifications) que no dudaría en reutilizar vía FlutterFire.

Lo que cambiaría o evitaría:

• Evitar basar todo en Firestore para datos estructurados: Si fuera de nuevo, introduciría probablemente una base SQL tan pronto como los datos de la app se vuelvan relacionales (p.ej.: usuarios, historias, capítulos, etc. con relaciones). Incluso manteniendo dos bases (Firestore para realtime en datos pequeños y Postgres para el resto), o pasando todo a una base tipo Supabase. El objetivo: no sufrir las limitaciones de consultas y estructura de Firestore a largo plazo.
• No meter toda la lógica en Cloud Functions: Optaría por un backend separado (aunque ligero) para codificar la lógica de negocio compleja. Por ejemplo, la generación de historias vía IA la hubiera desarrollado en una pequeña API Node o Deno separada, llamada desde la app, en lugar de meterla en una Cloud Function Firebase. Me habría dado más control (despliegue independiente, tests unitarios, etc.) y evitado mezclar NodeJS y Dart en el mismo proyecto.
• Anticipar la arquitectura desde la V1: En 2023 lo dejé un poco de lado ("YOLO, ship y ya veremos"). En 2025 me obligaría a definir unas guidelines arquitectónicas desde el principio: módulos claros, separación de responsabilidades entre frontend y backend, plan de tests, estrategia de seguridad y validaciones, etc. No hace falta invertir meses, pero sí unos días de reflexión. En resumen: el problema no fue Firebase en sí, sino usarlo sin una arquitectura detrás.

Conclusion

En retrospectiva, Firebase no fue el "problema": de hecho fue la solución ideal para lanzar TaleMe rápido y validar el concepto.

Sus beneficios (velocidad de desarrollo, servicios integrados, escalabilidad automática) permitieron a un dev en solitario alcanzar los objetivos de la V1.

Sin embargo, lo que aprendí es que no tomar decisiones arquitectónicas también es una decisión... y a menudo la equivocada. Al abandonarme demasiado al confort de Firebase, acumulé deuda técnica y restricciones que podrían haberse evitado con un poco más de perspectiva.

La buena noticia es que en 2025 tenemos más opciones que nunca para construir nuestros backends móviles: podemos mezclar servicios Firebase con soluciones a medida, optar por alternativas como Supabase para recuperar el control del SQL, aprovechar la IA para ayudarnos a programar con más eficiencia…

Lo importante es mantener en mente la perennidad de la app: Firebase es un excelente acelerador, siempre que se sepa frenar a tiempo y construir bases sólidas alrededor.

Y ustedes, cuál es su experiencia con Firebase (o sus alternativas)? ¿También han sufrido el síndrome del MVP "100% Firebase" que luego hay que refactorizar, o por el contrario todo ha ido bien? Compartan sus experiencias en los comentarios, ¡me interesa saber!