Desarrollo de Software B2B a medida en Barcelona

Cuando hablamos de software empresarial nos referimos a las herramientas que sostienen el día a día de una empresa por dentro: un CRM que ordena el pipeline comercial, un ERP que gobierna inventario y finanzas, un panel que centraliza pedidos, o una plataforma que conecta a la empresa con su red de distribuidores. No es la web pública ni la tienda online de cara al cliente final; es la maquinaria que hay detrás, la que usa el equipo para trabajar y la que usan terceros de confianza —clientes B2B, proveedores— con acceso controlado.

B2B frente a B2C: no es la misma lógica de producto

Un software B2C se diseña para que millones de usuarios anónimos completen una acción simple en segundos: comprar, reservar, publicar. Un software B2B se diseña para que un número reducido de usuarios identificados —empleados, clientes con cuenta, proveedores— repitan procesos complejos con datos sensibles, permisos por rol y trazabilidad de cada movimiento. Ahí cambia todo: el modelo de datos, la seguridad, la lógica de negocio y hasta el ritmo de las decisiones de producto, que en B2B las marca el proceso real de la empresa, no una tendencia de mercado.

Por eso el software de consumo —una app de notas, una hoja de cálculo compartida, un SaaS genérico pensado para cualquiera— no aguanta mucho tiempo como columna vertebral de una operación con volumen. Sirve para arrancar, pero en cuanto el proceso tiene excepciones, integraciones con otras herramientas o exigencias de control de acceso, se convierte en un cuello de botella. Ahí es donde entra el software a medida: no sustituye al CRM o al ERP como categorías, sino que construye la versión de esa categoría que encaja con cómo trabaja realmente tu empresa, sin forzar el proceso para que quepa en una plantilla ajena.

Un SaaS es rápido de contratar y barato de empezar: das de alta una cuenta y en una tarde tienes algo funcionando. El desarrollo de software a medida arranca más despacio porque primero se diseña el proceso y luego se construye, pero lo que se entrega es una herramienta pensada para tu operativa, no una plantilla genérica que hay que forzar. Esta tabla resume el trade-off tal como lo vemos proyecto tras proyecto:

Dicho esto, el software estándar no es la opción "mala": para procesos genéricos —correo, calendario, facturación simple, un CRM sin particularidades— es casi siempre la respuesta correcta, porque no tiene sentido pagar un desarrollo a medida por algo que ya resuelve bien un SaaS de 20€ al mes. Donde cambia la ecuación es cuando el proceso central de la empresa es lo bastante propio como para que forzarlo en una plantilla ajena cueste más, en tiempo y en fricción, que construir la herramienta que de verdad necesitas. Ese es el criterio que aplicamos antes de proponer nada: primero miramos si un software escalable estándar te sirve, y solo si no, hablamos de código propio.

Estos tres sistemas casi nunca van por separado: una solución SaaS propia suele nacer como plataforma B2B y, con el tiempo, se le añaden portales específicos para clientes y proveedores sobre la misma arquitectura, sin duplicar backend ni base de datos.

Multi-tenant: ¿aislamiento por filas o por esquema?

Cuando un mismo software da servicio a varias empresas o varios clientes con datos que no se pueden mezclar, hay dos formas serias de aislarlos. Row-level security en Postgres —una política que filtra automáticamente cada consulta por el tenant del usuario conectado— funciona bien cuando el volumen de clientes es alto y todos comparten el mismo esquema; es más barato de operar y más fácil de migrar. Schema-per-tenant, con una copia de las tablas por cliente, tiene sentido cuando hay pocos clientes grandes con requisitos de aislamiento estrictos o normativa que exige separación física de datos. No hay una respuesta universal: depende de cuántos tenants vas a tener y de qué tan crítico es el aislamiento entre ellos, y esa decisión se toma en la fase de diseño, no a mitad de desarrollo.

RBAC y accesos delegados

El control de roles (RBAC) define qué puede ver y hacer cada tipo de usuario —administrador, comercial, cliente externo, proveedor— sin escribir permisos a mano en cada pantalla. Para el acceso de terceros usamos OAuth en lugar de pedir contraseñas: el usuario se autentica contra Google o Microsoft y nosotros solo recibimos un token con permisos limitados. Para las sesiones de la aplicación usamos JWT de vida corta —minutos, no días— combinado con un refresh token que renueva el acceso sin que el usuario tenga que volver a iniciar sesión. Si un token se filtra, caduca solo; no hace falta revocar sesiones activas manualmente.

Postgres, migraciones y trabajo pesado

La base de datos relacional sigue siendo, para el 90% de los sistemas de gestión B2B, la opción correcta: garantiza integridad entre pedidos, facturas y clientes de una forma que un modelo documental no ofrece de serie. Los índices compuestos —sobre las columnas que realmente se filtran juntas, no sobre cada columna por separado— son la diferencia entre una consulta de 2ms y una de 4 segundos cuando la tabla pasa de mil a un millón de filas. Cada cambio de esquema va versionado en una migración que se puede aplicar y revertir; nada de tocar la base de datos en producción a mano. Y lo que no necesita respuesta al instante —generar un PDF, enviar un lote de emails, sincronizar con un ERP externo— va a una cola y lo procesa un worker en segundo plano, para que la aplicación nunca se quede esperando.

Observabilidad, copias de seguridad y RGPD

Registramos quién hizo qué y cuándo —logs de auditoría, no solo logs de errores— porque en software B2B tarde o temprano alguien pregunta "¿quién cambió este precio?" y la respuesta tiene que estar en la base de datos, no en la memoria de nadie. Las copias de seguridad son automáticas y se prueban, no solo se generan. Y los datos se alojan en infraestructura dentro de la Unión Europea, con el software preparado desde el diseño para cumplir RGPD: minimización de datos, cifrado de lo sensible y capacidad real de exportar o borrar la información de un cliente cuando lo pide.

Todo esto tiene un objetivo práctico: que el software aguante el crecimiento sin una reescritura completa a los dos años. Diseñar para escalar no significa sobredimensionar desde el día uno —eso es el error contrario—, significa dejar las costuras en los sitios correctos para que añadir carga, usuarios o módulos nuevos sea trabajo de configuración, no de arquitectura desde cero. Es el mismo criterio que aplicamos en cualquier desarrollo de aplicaciones web que vaya a vivir en producción varios años, y es la base que hace posible un desarrollo de software cloud sin sustos cuando el negocio crece más rápido de lo previsto.

En la práctica, un desarrollo MVP cubre el proceso principal de punta a punta —el camino que usa el 80% de los usuarios el 80% del tiempo— y deja fuera, a propósito, los casos raros y las funciones "por si acaso". Esas se añaden después, cuando ya sabemos si de verdad hacen falta. Construir todo de golpe sin haber tocado el sistema con usuarios reales es la forma más segura de gastar presupuesto en pantallas que nadie termina usando como se pensó en el papel.

La sobre-ingeniería es el error contrario y es igual de caro: montar una arquitectura pensada para un millón de usuarios cuando el proyecto todavía tiene que demostrar que los primeros cien la quieren usar. Nuestro criterio es construir el MVP sobre la misma base sólida —capas separadas, base de datos bien modelada, autenticación correcta desde el primer día— para que escalar después sea añadir capacidad, no reescribir el sistema. Ahí está el equilibrio: simple por fuera, sin atajos por dentro.

Este enfoque por fases es exactamente el mismo que aplicamos cuando el encargo es una solución SaaS propia: primero el núcleo que resuelve el problema real de los primeros clientes, después los módulos, las integraciones y la capa de administración que llegan con el crecimiento. El desarrollo SaaS que funciona no es el que sale perfecto la primera vez; es el que se construye para poder cambiar de opinión sin dolor.

Estos seis escenarios son ilustrativos, pero responden a proyectos que hemos vivido de cerca. Puedes ver casos reales de clientes por sector, y si tu operativa necesita también una app para el móvil, trabajamos apps móviles complementarias conectadas al mismo backend.

Si además necesitas la parte pública de tu empresa —web corporativa, landing o e-commerce—, hacemos también desarrollo web en Barcelona conectado al mismo software interno.