Frontend y backend: la guía del founder no técnico

Un mapa práctico de la diferencia entre frontend y backend para el founder que paga por la build, tiene que leer un presupuesto y necesita saber a quién llamar cuando algo se rompe, sin escribir una línea de código.

En la tercera semana de proyecto, un founder con el que trabajamos entró a una call con el equipo de desarrollo por un problema simple: el botón de “finalizar compra” desaparecía en el celular de algunos clientes. Alguien del equipo dijo “eso es frontend” y otra persona respondió “no, el carrito llega vacío desde la API, es backend”. El founder anotó las dos palabras, asintió y no tenía idea de cuál de las dos explicaba la plata que estaba perdiendo esa mañana.

Frontend y backend son las dos mitades de cualquier software. El frontend es la parte que tu cliente ve y toca: la pantalla, los botones, el formulario, el diseño en el celular. El backend es la parte que nadie ve: el servidor que guarda los datos, procesa el pago, aplica las reglas del negocio y responde cuando el frontend le pide algo. No vas a programar ninguna de las dos. Pero si no sabes separarlas, vas a briefear mal, leer presupuestos a ciegas y perder días averiguando quién debería arreglar un problema de diez minutos.

Qué son frontend y backend, en español claro

Piensa en un restaurante. El frontend es el salón: las mesas, la carta, el mozo, todo lo que el cliente experimenta. El backend es la cocina y el depósito: donde se prepara la comida, donde se guardan los ingredientes, donde las reglas (“se acabó el salmón”) realmente existen. El cliente solo ve el salón. Pero un plato que llega mal pudo haberse pedido mal en el salón o cocinado mal en la cocina, y el dueño tiene que distinguir los dos para no pelear con la persona equivocada.

En el software es igual. El frontend corre en el dispositivo de tu cliente, en el navegador o en el app. Se encarga de mostrar las cosas y capturar lo que la persona escribe o toca. El backend corre en un servidor que alquilas en la nube. Se encarga de guardar, calcular, decidir y proteger. Entre los dos pasa la información: el frontend pide (“este cliente quiere finalizar la compra”), el backend responde (“compra registrada, cobro hecho, inventario descontado”).

La división importa porque las dos mitades tienen costos, riesgos y profesionales distintos. Tratar “el software” como una sola cosa es lo que hace que un founder acepte un presupuesto que no sabe leer y describa un bug de una forma con la que nadie puede actuar.

Por qué tú, que no vas a programar, necesitas saber la diferencia

El objetivo acá no es que aprendas a programar. Es que puedas hacer cuatro cosas que un founder no técnico hace cada semana y casi siempre hace mal.

La primera es describir un problema. “El app tiene un bug” no ayuda a nadie. “El botón de finalizar desaparece en el celular” apunta al frontend. “A un cliente le cobraron dos veces” apunta al backend. La segunda es leer un presupuesto y entender por qué una pantalla que parece simple a veces cuesta más que una compleja. La tercera es saber a quién contratar y cuándo. La cuarta es entender qué cambios son baratos y cuáles van a costar caro y arriesgan romper cosas que ya funcionaban.

Ninguna de esas cuatro exige código. Todas exigen el mapa. Es el mismo motivo por el que no necesitas cocinar para administrar un restaurante, pero sí necesitas distinguir un problema de salón de un problema de cocina.

Cuando algo se rompe: ¿es problema de front o de back?

Esta es la pregunta que más vas a hacer, así que vale un método simple. Pregunta: ¿el problema es sobre cómo se ve la cosa o sobre qué hace la cosa?

Si es apariencia o comportamiento en la pantalla, probablemente es frontend. El texto cortado en un iPhone, el botón que no clickea, el menú que queda encima del contenido, la página que tarda en dibujarse. Son problemas de lo que el cliente ve.

Si es dato, plata, regla o algo que pasa “por debajo”, probablemente es backend. Al cliente le cobraron mal, el reporte muestra un número que no cuadra, el email de confirmación no llegó, dos usuarios con el mismo login. Son problemas de lo que el sistema hace cuando nadie está mirando.

Hay una zona gris, y es honesta: a veces la pantalla muestra mal porque el backend mandó el dato mal. El carrito vacío del comienzo de este texto parecía frontend (el carrito aparece vacío) pero era backend (la API mandaba el carrito sin los ítems). Está bien no acertar a la primera. La ganancia es poder decir “parece front, pero confirmá si el dato que llega ya viene mal”, en vez de solo mandar una captura con la palabra “urgente”. Cuando tu equipo necesita contexto para moverse rápido, una auditoría de código honesta suele revelar dónde está más desprolija esa frontera.

A dónde va la plata del presupuesto

Cuando recibís una estimación, casi siempre está dividida (o debería estarlo) entre trabajo de frontend y trabajo de backend. Saber leer eso cambia la conversación.

Una pantalla que parece simple puede ser cara porque el trabajo de verdad está detrás. Un campo de búsqueda “simple” que tiene que buscar entre cien mil productos, ordenarlos por relevancia y responder en menos de un segundo es casi todo backend. Lo que el cliente ve es una cajita de texto. Lo que cuesta es la máquina de atrás.

Lo contrario también pasa. Una pantalla que parece rica, con arrastrar y soltar, animación y edición en vivo, puede ser cara en el frontend aunque el backend solo tenga que guardar el resultado al final. El punto no es memorizar qué mitad cuesta más. Es saber preguntar: “¿este monto es frontend o backend, y por qué?” Un proveedor que no te responde eso con claridad te está vendiendo una caja negra, y cuánto cuesta una aplicación se vuelve un número sin historia. Un buen socio muestra la cuenta; uno malo te pide confianza.

Qué es barato de cambiar y qué es caro

No todo cambio pesa igual, y la división frontend/backend es el mejor atajo para adivinar el peso antes de preguntar.

Los cambios de frontend suelen ser más baratos y menos riesgosos. Cambiar el color de un botón, reorganizar un formulario, editar un texto, ajustar el diseño en el celular. Ves el resultado al instante y, si quedó feo, lo deshacés sin drama. Por eso “déjame ver cómo queda” funciona bien en el frontend.

Los cambios de backend suelen ser más caros y más riesgosos, porque tocan datos y reglas de las que dependen otras cosas. Cambiar cómo se calcula el precio, cómo se guardan los datos de los clientes, cómo dos sistemas se hablan. Un error acá no deja el botón feo; le cobra mal al cliente o pierde información. Es el tipo de cambio que exige cuidado, testeo y a veces migrar datos viejos. Cuando alguien te promete un cambio “rápido” en el backend, vale desconfiar del “rápido” antes de aceptar el plazo. Buena parte de lo que llamamos integración de sistemas vive justo en esta mitad cara.

Full stack, dos especialistas, ¿o un equipo?

Acá entra la pregunta práctica de contratación, y la palabra que vas a escuchar: full stack. Un desarrollador full stack es alguien que trabaja en las dos mitades, frontend y backend. No es un superhumano; es un profesional que se mueve entre las dos en vez de especializarse en una.

Al principio, con una primera versión para poner frente a un cliente que paga, un buen full stack (o un socio que ya tiene los dos lados) casi siempre le gana a dos especialistas separados. Menos gente para coordinar, menos “eso no es lo mío”, una sola cabeza entendiendo el problema entero. La especialización tiene sentido después, cuando el producto crece y cada mitad se vuelve lo bastante compleja como para justificar una persona dedicada, o cuando ya tenés un volumen que revienta lo que viene prearmado.

El error común es contratar como si fueras una empresa grande antes de serlo. Dos seniors, uno de cada lado, en un producto que todavía no tiene forma, es caro y lento. Si estás decidiendo entre armar un equipo interno y trabajar con un socio, la división frontend/backend también ayuda: un socio entrega las dos mitades ya coordinadas, mientras que contratar significa acertar dos contrataciones difíciles antes de saber qué necesita el producto. Vale leer la tech stack que sostiene cada lado antes de decidir quién toca qué.

Señales de que la división se hizo para el ingeniero, no para el negocio

A veces el problema no es que no entiendas la división. Es que la división se hizo para agradar a quien programa, no para servir a tu negocio. Algunas señales de alerta:

El frontend está hermoso y el backend es un parche. Pantallas prolijas encima de datos en los que nadie confía es el equivalente a un salón premiado sirviendo comida de la cocina equivocada. Impresiona en la demo y falla en el uso real.

Lo opuesto también vale: un backend “de cohete” para un producto que todavía no tiene diez clientes. Demasiada ingeniería en la mitad invisible suele ser el equipo divirtiéndose, no el negocio avanzando.

Y la peor: nadie puede explicarte dónde termina una mitad y empieza la otra. Cuando el equipo trata la frontera como un misterio, casi siempre es porque está desprolija, y el código desprolijo en la frontera es donde los bugs se esconden por meses. Un tech partner de verdad no es una caja negra; te muestra el mapa sin que se lo pidas.

Preguntas frecuentes

¿Cuál es la diferencia entre frontend y backend, en una frase?
Frontend es la mitad que el cliente ve y toca (pantallas, botones, diseño); backend es la mitad invisible que guarda los datos, aplica las reglas y responde al frontend. Una se encarga de la apariencia y el comportamiento en la pantalla; la otra, de lo que el sistema hace por debajo.

Cuando algo se rompe, ¿cómo sé si es front o back?
Preguntá si el problema es sobre cómo se ve la cosa (probable frontend) o sobre qué hace la cosa con datos, plata y reglas (probable backend). Si la pantalla muestra algo mal, confirmá si el dato que llega ya viene mal, porque ahí el origen es backend aunque parezca frontend.

¿Necesito contratar dos personas o un full stack?
Al principio, un buen full stack o un socio que cubre los dos lados suele ganarle a dos especialistas: menos coordinación, una sola cabeza en el problema entero. Especializar cada mitad tiene sentido cuando el producto crece y cada lado se vuelve lo bastante complejo como para justificar una persona dedicada.

Y la base de datos, ¿es frontend o backend?
Backend. La base de datos es donde se guarda la información de tu negocio, y vive en la mitad invisible. El frontend nunca le habla directo a la base; le pide al backend, que consulta la base y responde.

¿Qué es “backend for frontend” (BFF)?
Es un patrón técnico en el que se construye un backend liviano hecho a medida para un frontend específico (por ejemplo, uno para el app y otro para el sitio). Es un detalle de arquitectura de tu equipo; como founder, no necesitás decidirlo, solo saber que la palabra existe.

¿Quién gana más, frontend o backend?
Esa es la pregunta de quien elige una carrera, no de quien paga por la build. Lo que te importa no es qué profesional cuesta más en el mercado, sino dónde está de verdad el trabajo de tu proyecto: a veces en la pantalla, a veces en el servidor, casi siempre en las dos.

La división entre frontend y backend no es trivia técnica. Es el mapa que decide si vas a briefear con precisión o a ciegas, leer un presupuesto o aceptarlo de fe, y llamar a la persona correcta en diez minutos o perder tres días. No necesitás cocinar. Necesitás distinguir un problema de salón de un problema de cocina, e insistir en que quien construye para vos sepa mostrarte los dos. Una referencia neutral y canónica sobre la división entre cliente y servidor está en la documentación de Mozilla.