Firebase es un conjunto de servicios de Google que te da hechas las piezas invisibles de una app: el registro de usuarios, la base de datos, el almacenamiento de archivos, las notificaciones y los avisos de errores. En lugar de montar y mantener servidores propios para todo eso, tu equipo de desarrollo los conecta y dedica el tiempo a lo que tu negocio sí nota: las pantallas y las funciones que usan tus clientes.
Si estás valorando presupuestos de una app y en alguno aparece la palabra Firebase, lo que te están diciendo es qué van a construir y qué van a alquilar. Esto es lo que conviene que entiendas antes de firmar.
Qué es Firebase y qué parte de tu app resuelve
Toda app tiene dos mitades. La que se ve (los botones, los formularios, las listas) y la que no se ve: el servidor donde se guardan los datos, el sistema que comprueba que una contraseña es correcta, el que envía un aviso al móvil, el que te cuenta que la app se ha cerrado sola en un modelo concreto de teléfono. Esa segunda mitad es el backend, y construirla desde cero cuesta tiempo y luego hay que mantenerla.
Firebase es la respuesta de Google a ese problema. Es lo que en el sector se llama un backend como servicio: tú no instalas nada ni administras máquinas, usas servicios que ya están funcionando y pagas por el consumo que hagas. Para el que encarga la app, la traducción práctica es sencilla: con Firebase se llega antes a tener algo en manos de los usuarios, porque buena parte de la fontanería viene puesta.
Firebase no es un programa que se instala ni una alternativa a tener una app. Es la caja de herramientas con la que se construye por dentro. Y como cualquier decisión de infraestructura, tiene consecuencias a años vista que merecen una conversación de negocio, no solo técnica.
Qué servicios incluye Firebase y para qué sirve cada uno
La plataforma agrupa varias piezas que se activan por separado. Estas son las que aparecen en casi cualquier proyecto, explicadas por lo que hacen para ti:
- Authentication: el registro y el acceso de usuarios. Permite entrar con correo y contraseña, con cuenta de Google o de Apple, o con el número de teléfono y un código por SMS. Te ahorra construir la parte más delicada de cualquier app.
- Cloud Firestore: la base de datos donde viven los pedidos, las fichas, los mensajes. Guarda la información en documentos y la sincroniza en el móvil casi al instante, así que varios usuarios ven lo mismo sin recargar nada.
- Realtime Database: la base de datos anterior de Firebase, todavía en uso. Encaja en casos muy concretos, como un chat o un marcador en directo.
- Cloud Storage: el almacén de archivos. Fotos de productos, justificantes, documentos que suben tus clientes.
- Cloud Functions: pequeños trozos de código que se ejecutan en el servidor cuando pasa algo. Por ejemplo, enviar un correo de confirmación cuando entra un pedido o avisar a tu ERP.
- Cloud Messaging: las notificaciones push al móvil, gratuitas y a cualquier número de dispositivos.
- Crashlytics: te dice cuándo y por qué la app ha fallado, en qué modelo y en qué pantalla. Sin esto, dependes de que un cliente se moleste en contártelo.
- Remote Config: cambiar textos, precios o activar una promoción sin publicar una versión nueva en las tiendas. Es más útil de lo que parece: una actualización tarda días en llegar a todos los usuarios.
- App Distribution: repartir versiones de prueba entre tu equipo y tus clientes piloto antes de publicar.
- Performance Monitoring y la integración con Google Analytics: cuánto tarda en abrirse, dónde abandona la gente, qué pantallas se usan de verdad.
No necesitas todas. Un proyecto razonable empieza con tres o cuatro y añade el resto cuando hacen falta.
Cuándo le conviene Firebase a tu proyecto y cuándo no
Firebase encaja bien cuando quieres validar una idea rápido, cuando la app es principalmente móvil y cuando lo que necesitas es lo de siempre: usuarios, datos, archivos, avisos. También cuando tu volumen es irregular y prefieres pagar por uso en lugar de mantener servidores encendidos todo el mes.
Encaja mal, o directamente no encaja, en estos casos:
- Tu negocio vive de informes y consultas complicadas cruzando muchas tablas. Firestore está pensado para leer y escribir rápido, no para la contabilidad analítica.
- Necesitas integrarte a fondo con sistemas que ya tienes (un ERP antiguo, una base de datos propia, un sistema sectorial). Entonces el centro del proyecto es esa integración y Firebase se queda en un papel secundario.
- Tienes requisitos estrictos sobre dónde y cómo se guardan los datos, por el tipo de información o por el cliente al que vendes.
- El proyecto es una web corporativa o una tienda. Ahí la decisión relevante es otra: el gestor de contenidos. Nuestra comparativa de tecnologías web te sitúa mejor que esta.
Firebase frente a un backend propio: en qué se diferencian
| Aspecto | Con Firebase | Con un backend propio |
|---|---|---|
| Tiempo hasta la primera versión | Más corto: las piezas base vienen hechas | Más largo: hay que construirlas |
| Modelo de gasto | Pago por consumo, variable cada mes | Coste más fijo y previsible |
| Mantenimiento de servidores | Lo lleva Google | Lo lleva tu proveedor o tu equipo |
| Consultas e informes complejos | Limitado; suele hacer falta otra pieza | Flexible, es su terreno |
| Integración con sistemas existentes | Posible, con trabajo extra | Natural |
| Cambiar de proveedor más adelante | Trabajo de migración real | Más sencillo si la tecnología es estándar |
No hay una opción buena y otra mala. Hay una pregunta previa: ¿qué es más caro para ti ahora mismo, tardar seis semanas más en salir o asumir una dependencia que algún día costará dinero deshacer?
Qué debes vigilar antes de decir que sí
Tres asuntos que a los no técnicos se les escapan y luego duelen.
El coste no es cero y no es fijo. La documentación de Firebase describe dos planes: Spark, gratuito y con límites de uso, y Blaze, de pago por consumo. El plan gratuito aguanta bien una prueba o un piloto pequeño. En cuanto la app se usa de verdad, se pasa a pago por uso, y ahí la factura depende de cuántas veces se lee y se escribe en la base de datos. Una app mal construida puede hacer cien consultas donde bastaría una, y eso se paga todos los meses. Pide que el presupuesto incluya una estimación de consumo y pon alertas de gasto desde el primer día.
Los datos personales siguen siendo tu responsabilidad. Si guardas datos de clientes, el Reglamento General de Protección de Datos te obliga igual. Google publica condiciones de tratamiento de datos para los servicios de Firebase, y Firestore te deja elegir la ubicación de la base al crearla, con regiones europeas entre las opciones. Esa elección se hace una vez y no se cambia después, así que decídela conscientemente y refléjala en tu registro de actividades de tratamiento.
La dependencia es real, pero se puede acotar. Las reglas de seguridad, la estructura de datos y las funciones de servidor son propias de Firebase. Si un día quieres salir, hay que rehacer esa parte. Se reduce mucho si el proyecto mantiene la lógica de negocio separada de la plataforma. Es una decisión de arquitectura que debes pedir expresamente.
Cómo empezar sin quedarte atrapado
- Escribe qué tiene que hacer la app antes de hablar de tecnología. Firebase o no, lo que hunde proyectos es no saber qué se construye.
- Pregunta qué servicios de Firebase se van a usar y por qué. Si la respuesta es «todos», falta criterio.
- Exige que la cuenta de Google y el proyecto estén a tu nombre, con tu facturación y tu acceso de administrador. Es tuyo, igual que el dominio.
- Pide el código fuente y la documentación de la estructura de datos como entregable, en tu propio repositorio.
- Pon un presupuesto de consumo con alertas en el primer mes de uso real y revísalo.
- Aclara qué pasa con la lógica de negocio: cuánta vive en Cloud Functions y cuánta en código portable.
Con esos seis puntos cerrados, usar Firebase es una decisión sensata y reversible. Sin ellos, cualquier tecnología te deja atado.
Lo que te conviene recordar
Firebase te sirve para salir antes con una app que funciona, sin montar ni mantener servidores, a cambio de una factura variable y de una dependencia que conviene acotar por contrato y por arquitectura. Para un piloto, un producto nuevo o una app de uso interno es una base muy razonable. Para un sistema que debe convivir con tus programas de gestión de siempre, probablemente sea solo una pieza de un diseño más amplio.
Si tienes una idea de app y no sabes si Firebase es el camino o te sobra con una web app, cuéntanos qué quieres construir y te decimos con qué piezas lo montaríamos y qué consumo esperar.
Artículos relacionados
Preguntas frecuentes sobre
Cómo mejorar mi negocio con la metodología Anticompetencia
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.