En un sitio de venta al consumidor final, el precio es la parte más simple del problema. Un producto, un precio, el mismo para todos los que abren la página —un desconocido en otro país ve el mismo número que vos. Un desarrollador que recién empieza en proyectos B2B suele llevarse ese supuesto directo a su primer proyecto mayorista, y se rompe casi de inmediato.
Vi pasar esto con alguien que estaba al principio de su carrera, a quien le encargaron construir "el portal de clientes" para una operación mayorista. Armó un catálogo de productos prolijo, un carrito, un checkout —básicamente una tienda normal, bien hecha. Después se la mostró al cliente, que la miró unos treinta segundos y preguntó: "¿dónde se ve que a este cliente le corresponde un 12 por ciento de descuento, y a este otro una tarifa distinta por el volumen del año pasado?" No había una respuesta clara, porque toda la estructura asumía que existía un solo precio por artículo. En una operación B2B real, ese supuesto simplemente es falso.
Un mismo artículo, varios precios verdaderos a la vez
En el mayorista, el mismo código de producto puede tener un precio distinto para cada cliente, y todos esos precios son correctos al mismo tiempo. Un cliente negoció un descuento fijo hace años que todavía se respeta. Otro accede a una tarifa más baja al superar un umbral de volumen cada trimestre. Un tercero está a mitad de una renegociación de tarifa que entra en vigencia el mes que viene, pero todavía no. Nada de esto es una excepción para resolver después: es la forma normal que tiene el precio en el mundo B2B, y un portal que no lo contempla desde el principio no es una versión más chica de lo real. Es la cosa equivocada.
Por esto mismo, "simplemente construyamos una tienda online" subestima lo que realmente requiere un portal. Una tienda online asume que el catálogo y el carrito son la mayor parte del trabajo. En B2B, el catálogo y el carrito son casi la parte fácil. La lógica de precios que está debajo de todo eso —quién ve qué precio, cómo cambia con el tiempo, y cómo respetar una tarifa que alguien acordó hace seis meses incluso después de que la lista general de precios se movió— es donde está la ingeniería real.
Las complejidades más silenciosas llegan junto con el problema de los precios
Una vez que el tema de los precios está bien resuelto, aparecen otras tres cosas justo detrás, y las tres son fáciles de subestimar desde afuera.
La primera es mantenerse sincronizado. Un portal que muestra stock y precios solo sirve si esos números coinciden con lo que realmente es cierto en los sistemas que ya hacen funcionar el negocio —inventario, facturación, lo que sea que su equipo ya use. Un portal que se desincroniza de la realidad es peor que no tener portal, porque engaña activamente a los clientes en lugar de simplemente no ayudarlos.
La segunda son los permisos dentro de un mismo cliente. Un cliente empresa normalmente no es una sola persona —es una compañía con varios empleados que necesitan distintos niveles de acceso. La persona que hace los pedidos de rutina no necesariamente debería ver todo el historial de pagos de la empresa. El contacto de finanzas que necesita las facturas puede no ser la persona que debería poder cambiar las direcciones de envío. El acceso por rol dentro de cada cuenta de cliente no es un extra opcional; es parte de lo que realmente significa, en la práctica, que "una empresa, no una persona, está usando esto".
La tercera es el volumen que crece. Un portal construido para manejar cómodamente el tráfico y el tamaño de catálogo de hoy va a empezar a sufrir en el momento en que cualquiera de los dos crezca más allá de lo que se diseñó —y si el negocio está haciendo bien las cosas, ambos van a crecer. Construir solo para los números de hoy es apostar a que el negocio no va a crecer, lo cual es una apuesta rara de hacer a propósito.
Diseñalo desde el principio, no lo parches después
Nada de esto necesita resolverse todo junto, y nada necesita ser perfecto el primer día. Lo que sí necesita es estar pensado desde el principio —el modelo de datos que asume precios por cliente desde la primera línea de código, no agregado después; la estructura de permisos que asume una empresa con roles, no un solo usuario. Agregar esto después de que el portal ya está en producción es mucho más caro que construirlo desde el inicio, porque para ese momento hay datos reales de clientes y procesos reales que dependen del supuesto más simple que ahora hay que deshacer.
Por esto mismo trabajo con una fase corta de discovery, a precio fijo, antes de comprometerme con un desarrollo completo —alrededor de una semana, con un alcance claro, un prototipo funcional y una estimación real al final. Es suficiente tiempo para mapear exactamente cómo funcionan los precios de un cliente, con qué sistemas el portal necesita mantenerse sincronizado, y quién necesita ver qué dentro de cada cuenta, antes de que esos supuestos queden grabados en código que después es caro de deshacer. También desarrollo con asistencia de IA cuando realmente acelera las cosas, lo cual achica aún más ese plazo, pero cada línea se revisa y se prueba exactamente igual que siempre.
No es un precio. Es un sistema de precios.
La diferencia entre "una tienda online" y "un portal B2B" no son las funciones: es este supuesto de base, que sostiene todo lo demás. Una vez que aceptás que cada cliente puede ver un número distinto para el mismo artículo, y diseñás a partir de eso desde el principio, el resto de la complejidad —sincronización, permisos, escala— tiene dónde vivir de forma sensata. Si se salta ese paso, termina reconstruyendo los cimientos cuando los clientes ya están confiando en ellos.