Software vertical propio: qué es un cuerpo vertical y por qué no es un SaaS con logo cambiado

Una empresa de instalaciones eléctricas industriales en Zaragoza. 140 personas, cuatro delegaciones, cartera pública y privada. Su director general lleva dos años atrapado entre dos malas opciones. La primera, un SaaS de gestión de obra bastante conocido: lo probaron seis meses, la operativa real de sus jefes de obra no cabe en ese flujo y acabaron llevando la mitad del proceso en un Excel paralelo. La segunda, un desarrollo a medida completo. Le han pasado tres presupuestos y todos empiezan por encima de los 90 000 euros, con doce meses de plazo y sin garantía de que el resultado se parezca a lo que su gente necesita el primer día.

No quiere ninguna de las dos. Quiere una tercera cosa que casi nadie le está ofreciendo con nombre claro: un software vertical propio construido sobre un cuerpo sectorial ya resuelto. Es decir, un sistema que llega el primer día sabiendo qué es un parte de obra, cómo se factura por certificación, cómo se controlan retenciones de garantía, cómo se cierra un lote de material y cómo funciona el ciclo de una subcontrata. Sobre eso, él configura lo suyo. Y si algún proceso es realmente único, lo pide en desarrollo exclusivo, pero solo ese trozo, no el sistema entero.

Ese sistema existe. Se llama SVP, software vertical propio. Y el activo central que lo hace posible es el cuerpo vertical. Este artículo explica exactamente qué es un cuerpo vertical, qué contiene, qué se configura por cliente, qué se desarrolla en exclusiva y de quién es la propiedad de cada pieza.

No es un SaaS con el logo cambiado. Tampoco es un a medida disfrazado. Es una categoría distinta.

Qué es un cuerpo vertical y por qué no es una plantilla

Un cuerpo vertical es el conjunto de decisiones de arquitectura y modelo de datos ya resueltas para un sector, sobre el que después se adapta la operación real de cada empresa. Eso es todo.

No es una plantilla. Una plantilla es una pantalla vacía que copias y rellenas. Un cuerpo vertical trae las entidades del sector, las relaciones entre ellas, los estados de cada expediente, las reglas de validación, los cálculos característicos y la trazabilidad que el sector exige. Cuando aterrizas en él, no estás rellenando huecos: estás heredando cincuenta o cien decisiones técnicas que alguien ya tomó por ti después de meter la cabeza en veinte empresas del mismo sector.

Tampoco es un SaaS vertical. Un SaaS vertical es un producto cerrado: la empresa se adapta a él, el proveedor decide qué entra y qué no en el roadmap, y cuando tu operativa se sale del carril estándar te toca inventar Excel paralelos o pagar integraciones. El cuerpo vertical, en cambio, es la base sobre la que se construye tu sistema propio. Se configura ampliamente por cliente y admite desarrollo exclusivo cuando de verdad hace falta.

Traducción: el SaaS te pide que cambies tu operativa. El desarrollo a medida te pide que pagues por todo, incluido lo que ya está resuelto en el sector. El SVP con cuerpo vertical te pide que solo pagues por lo que es tuyo y aproveches lo que ya está resuelto.

La diferencia práctica es enorme. Un SaaS vertical típico de gestión de obra impone su modelo de "unidad", "capítulo", "certificación" y "parte diario", con los campos que el proveedor eligió. Si tu empresa distingue entre parte de mano de obra directa, parte de subcontrata y parte de transporte pesado, con reglas de aprobación distintas, o cambias tu operativa para caber en el modelo del SaaS o te fabricas un Excel paralelo. Con un cuerpo vertical, esas tres variantes de parte ya vienen contempladas como tipos de expediente configurables, y la regla de aprobación se configura, no se programa.

Aquí empieza el lío para muchos directores generales. Confunden "vertical" con "cerrado". Vertical no significa cerrado. Significa que la profundidad del modelo pertenece a un sector concreto. El cierre o la apertura del sistema es una decisión de arquitectura distinta.

El armazón técnico transversal: los componentes que se repiten en todo SVP

Antes del cuerpo vertical hay un armazón técnico que se repite en cualquier software empresarial serio, sea del sector que sea. Un cuerpo vertical se apoya sobre este armazón, no lo sustituye. Cuando alguien te vende "software a medida" y te cotiza doce meses, lo que te está cobrando es programar este armazón otra vez desde cero para tu empresa. En un SVP bien planteado, este armazón viene resuelto.

Los componentes son entre doce y catorce, y varían poco entre sectores:

• Autenticación y gestión de identidades. Login con correo o SSO, recuperación de contraseña, doble factor cuando aplica, cierre de sesión, invitaciones. Sin esto no hay sistema.
• Roles y permisos granulares. No basta con "admin" y "usuario". Un director de operaciones ve toda la delegación, un jefe de obra solo la suya, un administrativo lee pero no aprueba. El sistema de permisos tiene que soportar el mapa real de la empresa.
• Multi-tenancy y multi-organización. Si mañana adquieres una empresa o abres una filial, el sistema separa datos por tenant sin duplicar código ni servidor.
• Modelo de datos y capa ORM. Cómo se guardan las entidades, cómo se relacionan y cómo se consultan. Es el esqueleto sobre el que se apoya todo lo demás.
• Gestión de archivos y adjuntos. Subir un PDF, un DWG, una foto de obra. Almacenamiento fiable, previsualización, versión, control de peso. Suena básico y es donde más SaaS se caen.
• Flujos de aprobación configurables. Un expediente pasa por N pasos, cada paso lo aprueba un rol, se puede devolver, se puede escalar. Motor genérico, no cableado a un proceso concreto.
• Notificaciones y trazabilidad. Quién hizo qué y cuándo. Correo saliente, notificaciones en app, log de auditoría. Sin esto no puedes defenderte en una inspección ni en una discusión con un cliente.
• Búsqueda y filtrado sobre listados largos. Buscar un expediente entre 40 000. Filtrar por estado, fecha, responsable, cliente. Ordenar. Exportar. Esto se subestima hasta que el sistema tiene tres años de datos.
• Panel de indicadores y reporting. Números de la operación en tiempo real, no informes mensuales hechos a mano. KPIs configurables por rol.
• Integraciones y API. Salida a la contabilidad, entrada de datos de ERP, conector con firma electrónica, con pasarela de correo, con la Sede Electrónica cuando toque.
• Internacionalización y multi-idioma. Aunque solo operes en España, tenerlo en la base te evita pagar por rehacer todo si mañana abres en Portugal.
• Observabilidad y logs. Cuando algo falla en producción, saber por qué en cinco minutos, no en cinco días.
• Copias de seguridad y recuperación. Backup diario, retención, prueba de restauración. No opcional.
• Panel de administración del propio sistema. Alta de usuarios, activación de módulos, cambio de parámetros sin pedir un despliegue.

Ese armazón es el 60% del coste real de cualquier desarrollo empresarial serio. Cuando te llega el presupuesto de 90 000 euros de un desarrollo a medida convencional, más de la mitad se va aquí. Y aquí no hay nada específico de tu sector. Solo hay ingeniería que ya se ha hecho miles de veces.

Regla: si tu proveedor no te enseña esta lista antes de hablar de nada, te va a cobrar por rehacerla.

Qué contiene un cuerpo vertical sectorial

Encima del armazón técnico se sienta el cuerpo vertical. Aquí es donde el sistema deja de ser genérico y empieza a entender el sector.

Un cuerpo vertical sectorial contiene, como mínimo, cuatro capas:

1. Modelo de datos sectorial. Las entidades propias del sector con sus relaciones. En instalaciones eléctricas: Obra, Certificación, Parte de trabajo, Parte de material, Subcontrata, Retención de garantía, Cliente promotor, Cliente contratista, Delegación, Cuadrilla. En despachos de abogados: Expediente, Asunto, Actuación procesal, Cliente, Contraparte, Vencimiento procesal, Provisión de fondos. En centros médicos privados: Paciente, Historia clínica, Episodio, Prescripción, Cita, Consentimiento informado, Profesional, Cuadro médico. Estas entidades no las improvisa el proveedor el primer día. Vienen del sector y ya están validadas.

2. Tipos de expediente y ciclos de vida. Cada sector tiene procesos con estados definidos. Un expediente de obra pasa por Adjudicada, En ejecución, Suspendida, Recibida provisionalmente, Recibida definitivamente, Liquidada. Un expediente clínico pasa por Abierto, En revisión, Cerrado, Archivado. Estos ciclos, con las transiciones válidas entre estados, las alertas al cambiar y los permisos por estado, forman parte del cuerpo vertical. No se programan otra vez.

3. Reglas de negocio del sector. Cálculo de la certificación mensual con acopio a origen, deducción de anticipos y aplicación de retención. Cálculo de la provisión de fondos deducible. Cálculo del margen por proyecto neto de subcontrata. Validación de que un consentimiento informado esté firmado antes de agendar un procedimiento. Son reglas que existen porque el sector las exige, no porque tú las inventes. Vienen resueltas.

4. Documentos, plantillas y trazabilidad regulatoria. Un cuerpo vertical de servicios jurídicos trae la plantilla de encargo profesional, la carátula del expediente y el modelo de provisión. Un cuerpo vertical de obra trae la certificación en el formato que exige el pliego, el acta de replanteo y el parte diario. Un cuerpo vertical clínico trae el consentimiento informado por tipo de intervención y el histórico versionado. Se configuran por cliente, pero la estructura base viene del sector.

El cuerpo vertical no cubre el 100% del sector. Cubre el tronco común que comparten el 80% o el 90% de las empresas de ese sector. Lo que es genuinamente diferente de tu empresa se configura o se desarrolla en exclusiva, como veremos ahora.

Perspectiva real: un cuerpo vertical serio se construye en dos o tres años de trabajo con empresas del sector. No se improvisa en un mes. Cuando alguien te dice que "en un mes tenemos vertical de tu sector", lo que te va a entregar es un CRUD de pantallas vacías, no un modelo sectorial validado.

Qué se configura por cliente y qué se desarrolla en exclusiva

Aquí es donde el SVP se diferencia radicalmente de un SaaS y de un a medida.

En un SaaS vertical, la línea entre configurable y no configurable la decide el proveedor. Tú aceptas lo que hay o migras. En un desarrollo a medida clásico, todo se puede modificar, pero todo cuesta dinero y tiempo, porque no hay tronco reutilizable.

En un SVP con cuerpo vertical la línea es explícita y se pacta al inicio del proyecto. Hay tres zonas claras.

Zona 1: Configuración por cliente

Lo que se ajusta sin escribir una línea de código. Se cambia desde un panel de administración por alguien del cliente o del proveedor, en minutos u horas.

• Terminología y etiquetas. Si tu empresa llama "actuación" a lo que el estándar llama "actividad", se cambia.
• Campos personalizados. Añadir campos propios a Cliente, a Expediente o a Documento sin tocar el core.
• Flujos de aprobación específicos. Configurar quién aprueba qué y en qué orden dentro del motor de flujos.
• Permisos por rol y por delegación. Ajustar el mapa organizativo real.
• Plantillas de documentos. Personalizar la certificación, el contrato tipo, el consentimiento, con el logo, la razón social y las cláusulas de la casa.
• KPIs y paneles. Elegir qué métricas ve cada rol, con qué corte temporal y con qué filtros.
• Integraciones estándar. Activar y configurar el conector con la contabilidad, el correo, la firma electrónica.
• Alertas y notificaciones. Qué eventos disparan qué comunicación a qué persona.

Todo esto es configuración pura. No añade riesgo de deuda técnica, no exige testeo profundo y no bloquea futuras actualizaciones del cuerpo vertical.

Zona 2: Extensión configurada

Lo que se resuelve combinando piezas existentes del cuerpo vertical con parámetros más profundos. Requiere trabajo, pero no reinventa nada.

• Un nuevo tipo de expediente derivado de uno base, con sus estados y sus reglas.
• Un nuevo flujo de aprobación complejo con condicionales por importe, delegación o tipo de cliente.
• Un nuevo cálculo derivado apoyado en fórmulas parametrizables.
• Un nuevo informe con datos del modelo estándar.

Esto no es programación desde cero. Es aprovechar el motor del sistema para configurar un caso más elaborado. Se hace en días, no en meses.

Zona 3: Desarrollo exclusivo

Lo que es genuinamente tuyo y no encaja en la configuración. Se programa, se testea, se documenta y se despliega. Pero solo esa pieza, no el sistema entero.

Ejemplos reales del tipo de desarrollo exclusivo que aparece en proyectos SVP:

• Un cálculo de comisión comercial con tres niveles de escala variable atados a antigüedad del cliente y tipo de contrato, específico de tu red comercial.
• Una integración con un ERP heredado de los años noventa que no tiene API estándar.
• Un algoritmo de asignación de cuadrillas a partes de trabajo que depende de disponibilidad, especialidad y distancia geográfica, con reglas propias.
• Una pantalla operativa muy específica que el jefe de almacén usa doscientas veces al día y necesita atajos de teclado y un flujo binario sí/no muy particular.

El desarrollo exclusivo es la parte cara. Pero al haber cubierto el 80% con cuerpo vertical y configuración, ese exclusivo es proporcionalmente pequeño. En proyectos típicos representa entre el 10% y el 25% del coste total, no el 100%.

Regla operativa: si tu proveedor no te dibuja estas tres zonas en la propuesta y no te dice cuántas horas cae cada cosa, no está vendiendo SVP. Está vendiendo humo con etiqueta bonita.

Propiedad: qué queda del cliente y qué queda del proveedor

Este bloque es el que más se evita en las conversaciones comerciales, y es el más importante. Un director general que no aclara la propiedad antes de firmar termina atrapado en un sistema del que no puede salir. Un CTO que no la aclara termina descubriéndolo cuando quiere migrar.

En un SVP bien planteado la propiedad se pacta por capas.

Del proveedor: el armazón técnico transversal y el cuerpo vertical del sector. Esto es su producto. Es la ingeniería que ha construido en años de trabajo con múltiples clientes del sector. Es coherente que se mantenga como suyo, evoluciona con cada nuevo cliente que se suma y todos se benefician de esa evolución. Un cuerpo vertical mejora cuando el proveedor recibe feedback de veinte empresas del sector y consolida las mejoras en el tronco común.

Del cliente: los datos, siempre. Su instancia con toda su información operativa. Los desarrollos exclusivos pagados específicamente para él, con contrato que lo diga en letras claras. La documentación técnica de esos desarrollos. El acceso a los datos vía exportación estándar y vía API en cualquier momento.

Compartido con criterio: las configuraciones estándar y las plantillas específicas que el cliente ha diseñado. Aquí conviene pactar que el cliente puede usarlas libremente en el futuro fuera del sistema y que el proveedor puede incorporar aprendizajes anónimos al cuerpo vertical, pero nunca el detalle exacto.

Los tres puntos que hay que ver escritos en el contrato antes de firmar:

• Portabilidad de datos. Cláusula explícita de que el cliente puede exportar todos sus datos en formato estructurado (CSV, JSON o SQL) en cualquier momento y sin coste. Sin esto, el sistema es una cárcel.
• Fuente y titularidad del desarrollo exclusivo. El código de las piezas exclusivas, quién lo puede usar, dónde se hospeda, qué pasa si terminan la relación. Idealmente el cliente recibe el código fuente de sus exclusivos en escrow o directamente.
• Continuidad si el proveedor desaparece. Plan de contingencia por escrito. Cómo se accede al sistema, cómo se migran los datos, quién puede mantener el cuerpo vertical si el proveedor cierra.

Nota crítica: hay proveedores de SVP serios que tienen esto en su contrato desde la primera versión. Hay otros que lo dejan ambiguo. Un cliente que no lo pide, no lo tiene.

Duele, pero es información: si el proveedor se pone nervioso cuando le pides estas cláusulas, tienes tu respuesta antes de firmar.

Cómo saber si tu operación encaja en un SVP con cuerpo vertical

No todas las empresas necesitan un SVP. Algunas están bien con un SaaS de sector porque su operativa cabe entera en el estándar. Otras necesitan un desarrollo a medida completo porque su modelo de negocio es tan particular que no hay cuerpo vertical que sirva. La mayoría de PYMES industriales, de servicios profesionales y de sanidad privada de 20 a 200 personas están en el punto exacto donde un SVP tiene sentido.

Los criterios objetivos que separan un caso encajado de uno no encajado son estos.

Encajas si...

• Has probado uno o dos SaaS de sector y tu gente sigue trabajando en Excel para al menos un proceso crítico. Es la señal más clara. El SaaS cubre parte y no cubre parte, y el equipo compensa con hoja de cálculo. Eso no escala.
• Tienes entre 20 y 200 personas. Por debajo, el SaaS suele ser suficiente. Por encima, empiezas a mirar producto propio o corporate. En medio, el SVP es el punto dulce.
• Facturas entre 3 y 40 millones de euros. Volumen suficiente para amortizar el coste de un SVP y evitar la trampa de aceptar un SaaS que te encorseta el crecimiento.
• Tu sector tiene un tronco común claro de expedientes, ciclos y regulación (obra, salud privada, servicios jurídicos, distribución, logística, formación reglada, gestoría, consultoría técnica). Si tu sector ya tiene tres o cuatro cuerpos verticales maduros en el mercado, es que el tronco existe.
• Tienes al menos una persona técnica interna capaz de dialogar con el proveedor. No hace falta un CTO senior. Sí una persona que entienda de datos, procesos y sistemas y que pueda pedir cosas concretas.
• Tu operativa tiene entre 3 y 10 procesos claramente diferenciales frente a la media del sector. Ni menos (irías bien con SaaS), ni más (necesitarías a medida completo).

No encajas si...

• Tu empresa tiene menos de 15 personas y factura menos de 2 millones. El coste hundido de un SVP no se amortiza. Mejor un SaaS asumiendo su rigidez y compensando con automatizaciones puntuales.
• Tu sector es tan de nicho que no hay cuerpo vertical maduro en el mercado. Aquí tocaría o construirlo desde cero (caro) o esperar.
• Tu operación cambia cada seis meses de forma sustancial. Un SVP tiene sentido cuando la operativa se estabiliza. Si estás en pivote continuo, cualquier sistema queda obsoleto antes de rodarse.
• No tienes presupuesto de al menos 40 000 a 80 000 euros para el primer año entre implantación y evolutivo. Rangos orientativos de mercado que puedes contrastar con agencias como Vertebra Gestión, Cero Ideas o ASD Solutions según sector. Por debajo, terminarás en un SaaS.
• No estás dispuesto a documentar tu operativa real. Un SVP se configura sobre lo que haces de verdad, no sobre lo que dices que haces. Si tu equipo no puede describir su flujo real en cuatro reuniones, no hay sistema que lo capture.

Si has marcado cuatro o más de la primera lista y ninguna de la segunda, un SVP con cuerpo vertical del sector es probablemente la mejor decisión estratégica que puedes tomar en sistemas los próximos tres años.

Errores frecuentes al contratar un SVP

Los directores generales que llegan a un SVP con la cabeza equivocada suelen tropezar en los mismos sitios. Estos son los cinco errores más habituales, con síntoma y solución.

Error 1: Confundir cuerpo vertical con plantilla. Síntoma: el proveedor te enseña pantallas bonitas y te dice "esto se adapta a lo que tú quieras". No te enseña el modelo de datos ni los ciclos de expediente. No hay documentación técnica del cuerpo vertical. Solución: pide ver el diagrama entidad-relación del sector antes de firmar. Si no lo hay, no hay cuerpo vertical. Hay CRUD.

Error 2: No pactar por escrito las tres zonas (configuración, extensión, exclusivo). Síntoma: el presupuesto llega sin desglose. Solo hay una cifra global y "servicios de implantación". A los tres meses del proyecto todo lo que pides es "desarrollo adicional" y el coste se dispara. Solución: exige en la propuesta un desglose por horas de cada bloque, con lista de piezas que caen en cada zona. Si algún proceso tuyo no está mapeado a una zona, no lo firmes.

Error 3: No aclarar la propiedad del código exclusivo. Síntoma: pagas 20 000 euros por un desarrollo específico y en el contrato solo aparece "licencia de uso". Cuando quieres irte, ese código se queda con el proveedor y tú te quedas sin la lógica de tu proceso más diferencial. Solución: cláusula de titularidad del desarrollo exclusivo o, como mínimo, escrow de código. Ambos son estándar de mercado en contratos serios.

Error 4: Meter demasiado en desarrollo exclusivo desde el día uno. Síntoma: el cliente insiste en que "en nuestro caso todo es diferente" y pide programar a medida procesos que están perfectamente cubiertos por la configuración del cuerpo vertical. El proyecto se convierte en un a medida disfrazado, caro y lento. Solución: obligarse a arrancar solo con configuración del cuerpo vertical los primeros noventa días. Ver dónde duele de verdad. Programar exclusivo solo sobre las piezas que sigan doliendo después de rodar.

Error 5: Delegar la implantación en el proveedor y desaparecer. Síntoma: el director general firma, cede el proyecto a "un responsable" que no tiene autoridad para decidir, y no vuelve a mirarlo hasta que el sistema entra en producción. Ahí descubre que se han tomado veinte decisiones que no le gustan. Solución: designar sponsor ejecutivo con dedicación real (mínimo cuatro horas semanales los tres primeros meses) y calendario de comités quincenales con actas.

Estos cinco errores explican la mayoría de proyectos SVP que se torcieron. Ninguno es del proveedor. Todos son del cliente. Cansancio garantizado si no se corrigen a tiempo.

Preguntas frecuentes

¿Qué es exactamente un software vertical propio y en qué se diferencia de un SaaS vertical?

Un software vertical propio (SVP) es un sistema empresarial construido sobre un cuerpo vertical de sector (arquitectura y modelo de datos ya resueltos) que se configura ampliamente por cliente y admite desarrollo exclusivo para las piezas que son genuinamente diferentes. Un SaaS vertical, en cambio, es un producto cerrado que el proveedor evoluciona en su roadmap y al que la empresa se adapta. En SVP el sistema se adapta a la empresa; en SaaS es al revés.

¿Existe algo entre un SaaS de sector y desarrollar software desde cero?

Sí. Es exactamente el SVP con cuerpo vertical. Aprovechas el 60 al 80% del sistema (armazón técnico común más cuerpo vertical del sector) y solo pagas desarrollo exclusivo por el 20 al 40% que es genuinamente diferencial de tu operativa. La consecuencia es coste y plazo mucho menores que un a medida completo, con flexibilidad muy superior a un SaaS.

¿Cómo se construye un sistema empresarial partiendo de una arquitectura sectorial reutilizable?

El proceso típico son cuatro fases. Diagnóstico de operativa real del cliente y mapeo contra el cuerpo vertical del sector (dos a cuatro semanas). Configuración del sistema con las entidades, permisos, flujos y plantillas propias de la empresa (cuatro a ocho semanas). Desarrollo exclusivo de las piezas que no encajan en configuración (variable, de cuatro semanas a tres meses). Puesta en producción por delegaciones o por procesos, con acompañamiento y evolutivo continuo.

¿Qué significa que un software empresarial sea "propio" de la empresa que lo usa?

Significa tres cosas concretas y contractuales. Uno: los datos son del cliente y se pueden exportar en cualquier momento sin coste. Dos: los desarrollos exclusivos pagados por el cliente son suyos, con código en su poder o en escrow. Tres: la instancia se configura al detalle a la operativa real del cliente, no al revés. La propiedad del cuerpo vertical de sector se queda del proveedor (porque es su producto acumulado con múltiples clientes), pero todo lo que es específico del cliente es del cliente.

¿Cuánto cuesta y cuánto tarda un proyecto SVP típico para una PYME de 50 a 150 personas?

Rangos orientativos de mercado para primer año (implantación más evolutivo) que puedes contrastar con proveedores de referencia como Davisa, Pistacho Digital o Efiprox: entre 40 000 y 120 000 euros según sector y volumen de desarrollo exclusivo, con arranque productivo entre tres y seis meses. Es aproximadamente la mitad de un a medida completo y comparable en amortización a un SaaS de sector si se suman licencias, integraciones y horas ocultas de operativa paralela en Excel.

¿Qué pasa con el sistema si el proveedor de SVP desaparece?

Depende del contrato. Un contrato serio incluye plan de continuidad: acceso permanente a los datos, escrow del código de los desarrollos exclusivos, documentación técnica actualizada del cuerpo vertical en tu instancia y proveedores alternativos capaces de mantener el sistema si el original cierra. Si el contrato no cubre esto, el riesgo de dependencia es alto. Pídelo antes de firmar, no después.

Cierre

La empresa de instalaciones eléctricas de Zaragoza terminó eligiendo SVP. Firmó a los cuatro meses de empezar a mirar opciones, con cuerpo vertical de gestión de obra industrial, configuración amplia de sus flujos de certificación y aprobación, y tres piezas de desarrollo exclusivo: el cálculo de comisión de sus jefes de obra, la integración con el ERP que arrastran desde 2011 y la pantalla operativa del almacén central. Coste inicial dentro del rango orientativo del sector, plazo de puesta en producción por delegaciones en cinco meses, datos y desarrollos exclusivos en su propiedad por contrato.

Lo que no compró: un SaaS que le obligaba a rehacer su operativa. Lo que tampoco compró: un a medida que le cobraba noventa mil euros por reprogramar login, permisos, adjuntos y flujos que ya existen en cualquier sistema empresarial serio del mercado. Compró lo que había en medio y que tiene nombre técnico: software vertical propio construido sobre cuerpo vertical.

No es magia. Es que la industria del software empresarial resolvió hace tiempo el 80% del trabajo, y la mayoría de PYMES lo siguen pagando cada vez desde cero. Reutilizar lo que ya está resuelto es una decisión estratégica, no un atajo.

Si estás en el punto en que has descartado el SaaS por rigidez y el a medida por coste, la conversación útil es entrar al detalle: qué cuerpo vertical existe para tu sector, qué zonas de tu operativa caen en configuración y cuáles en exclusivo, y qué pinta tendría el contrato de propiedad. Eso se ve en una sesión de trabajo. Puedes empezar por leer cómo funciona el SVP en apferrer.com o reservar una sesión de 30 minutos para revisar tu caso concreto.

Lecturas relacionadas

• Software vertical propio - la propuesta completa
• Del problema a la herramienta que funciona - metodología FDE aplicada a sistemas
• Reservar sesión de diagnóstico - 30 minutos, sin coste, sin scope oculto