Cómo montar un negocio de software para fincas de bodas: el dato se mete una vez y sale por tres sitios

El negocio de una finca no son las bodas, son 26 sábados

Una finca de bodas en España trabaja de mayo a octubre. En esos seis meses hay unos 26 sábados. Ese número es el techo de facturación del negocio, y no se puede ampliar: no hay más sábados.

Todo lo demás es consecuencia de eso. Si un sábado se queda vacío, no se recupera. Si una pareja se cae en marzo, quedan tres meses para revenderlo. Si la coordinadora se equivoca con las alergias de la mesa 7, esa boda genera una reseña mala en el único canal donde las parejas buscan finca.

Y sin embargo, la mayoría de fincas medianas gestionan esos 26 sábados con un Excel de reservas, una carpeta de WhatsApp por pareja y la cabeza de la coordinadora.

Los números dicen por qué eso ya no se sostiene:

• 175.364 matrimonios en España en 2024, un 1,7% más que el año anterior (INE).
• El 81,4% son bodas civiles, y las religiosas han caído un 42% en diez años. Cuando no hay iglesia, la finca deja de ser el sitio del banquete y pasa a ser el escenario de todo el día: ceremonia, cóctel, cena y fiesta.
• Coste medio de una boda: 25.183 €, con unos 115 invitados y 225 € por invitado (Informe del Sector Nupcial 2026 de Bodas.net, sobre parejas casadas en 2025).
• El 53% de ese presupuesto se va en lugar de celebración y catering. Son unos 13.000 € por boda que pasan por la finca.
• 1.980 fincas listadas solo en el directorio de Bodas.net.

Una finca con 30 bodas al año mueve en torno a 400.000 €. Y las gestiona con un Excel.

Qué es Velaria

Velaria es el sistema de gestión de Finca El Olivar, una finca ficticia de 12 hectáreas a las afueras de Toledo con tres espacios: el Jardín de los Olivos (300 personas), el Salón Las Encinas (250 sentadas) y la Capilla de San Miguel (120).

Tiene cuatro piezas, y conviene verlas como cuatro productos:

1. La web pública. Páginas de espacios, bodas, celebraciones, gastronomía, galería, preguntas frecuentes y un calendario de disponibilidad. Con sitemap, JSON-LD del recinto y páginas legales con preferencias de cookies.
2. La app de gestión. Panel con ocupación de la temporada, eventos, calendario, clientes y leads, proveedores, pagos y ajustes. Dos roles internos: dirección y coordinadora.
3. El portal de la pareja. Cuenta atrás al segundo, sus tareas, sus pagos, sus invitados, el menú, el plano de mesas, el minuto a minuto y un hilo de mensajes con su coordinadora.
4. La hoja del día. Un documento imprimible con el minuto a minuto, los proveedores por hora de llegada, los cubiertos por tipo, las alergias mesa por mesa, el plano y los teléfonos de emergencia. Y un modo "En directo" a pantalla completa para el día del evento.

Es, con diferencia, el proyecto más terminado de esta serie: tiene migraciones de datos versionadas, tests de reglas de negocio, soporte de renderizado en servidor y una web pública con SEO trabajado. Eso no lo convierte en un producto vendible tal cual, y más adelante explico por qué, pero sí cambia lo que se puede cobrar por él.

La idea que sostiene el producto: un dato, tres salidas

Esto es lo que hay que entender del código, porque es lo que se vende.

La información de una boda se mete una sola vez, en la ficha del evento. Y sale por tres sitios distintos, cada uno escrito para un lector diferente.

Sale hacia la pareja. El portal coge el mismo evento y lo cuenta en su idioma: cuántos días faltan, cuántas de sus tareas llevan hechas, cuánto queda por pagar y cuándo vence, cuántos invitados han confirmado. Con la foto de su coordinadora, su teléfono, su WhatsApp y su última frase citada en el portal.

Sale hacia el equipo. La hoja del día coge el mismo evento y lo convierte en un documento operativo: cubiertos por tipo (adulto, infantil, vegetariano, vegano, sin gluten), alergias agrupadas mesa por mesa, proveedores ordenados por hora de llegada con su contacto, plano de mesas y teléfonos de emergencia, incluido el del electricista de guardia. Pensado para imprimirse y llevarlo encima.

Sale hacia la web pública. Y aquí está el detalle más fino de todo el proyecto. Hay una función que recorre la agenda interna y devuelve, para cada día, un único valor: libre, pocas o ocupada. Ignora las visitas y las cancelaciones, y no expone ni un nombre de cliente ni un dato del evento. La web muestra disponibilidad real sin filtrar nada confidencial.

El resultado: el calendario público de la finca está siempre actualizado sin que nadie lo actualice. Eso resuelve un problema que toda finca tiene, que es la pareja que escribe preguntando por una fecha que ya está vendida.

Lo mismo pasa con las preguntas frecuentes: se generan a partir de los espacios y del precio mínimo real de la carta de menús. Si dirección cambia la capacidad del salón en ajustes, la respuesta pública cambia sola. La web no puede contradecir a la app porque beben de la misma fuente.

Otras tres decisiones que vale la pena copiar

El plan de pagos 20/40/40 se calcula solo. Señal a la firma, 40% a sesenta días de la boda, 40% a siete días. Y lo interesante es cómo regenera el plan cuando cambia el presupuesto: conserva cualquier hito que ya tenga algún cobro registrado y reparte el resto entre los que faltan. Un hito admite varios recibos parciales, con método y referencia, y el estado de "pendiente, pagado o vencido" se deduce de lo cobrado y de la fecha, no se declara a mano.

Las tareas salen de una plantilla por tipo de evento, contada en días antes. La de boda tiene 18 pasos, desde "firma de contrato" a 300 días hasta "coordinación del día" a 0, cada uno con prioridad y con dueño: equipo o pareja. Eso es lo que permite que el portal pueda enseñarle a la pareja solo lo suyo, que es lo que hace que la pareja entre. Las comuniones, aniversarios y eventos corporativos tienen sus propias plantillas.

El plano de mesas sienta a la gente por grupos. Hay una función que coloca a los confirmados sin mesa agrupados por su grupo (familia de la novia, amigos del pádel, compañeros de trabajo) buscando la mesa donde el grupo quepa más ajustado, y si no cabe entero lo reparte entre las que más sitio tienen. Nunca usa la presidencial. No es inteligencia artificial, son cuarenta líneas, y resuelve la tarde más tediosa de toda la organización de una boda.

El modelo: desarrollo a medida replicable

Como Obria y Remansa, esto no es un SaaS. Hay una finca escrita en el código, con su nombre, su CIF, su dirección y sus coordenadas. Los datos viven en el navegador. No hay registro ni suscripciones.

Y, otra vez, ese es el modelo, no el defecto. Una finca no quiere ser un inquilino de una plataforma. Quiere su web, con su dominio y sus fotos, y un sistema que funcione como trabaja ella.

Estructura de precios:

• Implantación: 4.000 € a 12.000 €, según cuántas piezas entren. La web pública sola ya es una venta. La web más la app es el paquete normal. Con portal de la pareja y hoja del día es el completo.
• Mantenimiento: 200 € a 400 €/mes: hosting, soporte, copias, cambios de temporada (fotos nuevas, precios nuevos, menús nuevos).

El argumento de precio se construye solo con los datos de arriba. Una finca de 30 bodas mueve unos 400.000 € al año. Un proyecto de 6.000 € más 250 €/mes son 9.000 € el primer año: el 2,2% de su facturación, y menos del valor de una sola boda. Si el sistema evita que se caiga un sábado, ya se ha pagado dos veces.

Un escenario conservador a 12 meses

Antes de los números, la advertencia de siempre: esto sigue siendo una demo sin backend. Las cifras asumen que haces primero el trabajo de la sección "lo que hay que añadir antes de vender esto". El ciclo de venta aquí es más largo que en otros sectores, porque la decisión la toma el propietario y suele tomarla entre temporadas.

Proyecto medio: 6.000 €. Mantenimiento medio: 250 €/mes.

14 fincas sobre las 1.980 del directorio de Bodas.net es un 0,7%. Entras en el segundo año con 42.000 € de recurrente ya firmado.

Y hay un detalle de calendario que importa: se vende de noviembre a marzo. En plena temporada ninguna finca va a cambiar de sistema, pero en invierno tienen tiempo, tienen el balance del año reciente y tienen el recuerdo fresco de todo lo que salió mal.

La competencia: existe, pero no juega en esta liga

Aquí hay que ser honesto, porque el argumento fácil ("nadie tiene portal del cliente") es falso.

Parker Solutions vende un ERP para salones y fincas de eventos que ya incluye intranet para el cliente final, con presupuesto, degustación de menú, lista de invitados, alérgenos, timing, firma de documentos y mensajería. Es un producto serio y hace más cosas que Velaria: escandallos, producción de cocina, trazabilidad de lotes, integración con A3 y SAGE.

OfiEventos (Ofimática) cubre reservas, planning, presupuestos, salones, invitados, inventarios, cobros, facturación y contabilidad. No tiene portal de autoservicio para el cliente. Y hay más: 360 Event Software, Univents, Skanda, además de herramientas pensadas para wedding planners, no para fincas.

El hueco real no es funcional, es de mercado y de forma de vender:

1. Son ERPs de grupo de catering, no herramientas de finca. Están construidos alrededor de la cocina y la administración: escandallos, stock, producción, contabilidad. Una finca de 30 bodas al año no tiene ese problema. Tiene el problema de los 26 sábados y de las parejas que llaman.
2. Ninguno publica precio. Todos son "cotización personalizada" y venta con comercial. Eso ya dice a quién van dirigidos, y dice también que el ciclo de compra es largo y caro. La finca mediana no entra en ese embudo, y por eso sigue con el Excel.
3. Ninguno trae la web pública. Y para una finca, la web no es un accesorio: es el canal. Las parejas llegan por Bodas.net, por Instagram y por la web, y la web es la única pieza que la finca controla. Entregar la web conectada al sistema, con el calendario de disponibilidad en vivo y el formulario que entra directo como lead, es una venta que esos ERPs no hacen.

Dicho de otra forma: no compites por funcionalidad, compites por tamaño de cliente y por formato de entrega. Tu producto es "le monto a esta finca su web y su sistema, por un precio cerrado, en seis semanas". El suyo es "implante nuestro ERP".

Lo que hay que añadir antes de vender esto

1. Backend y autenticación de verdad. Hoy los datos están en localStorage y el rol se cambia desde un selector. Eso significa que cualquiera que abra la aplicación puede ponerse en modo dirección. Para un sistema que contiene los teléfonos y las alergias de 200 invitados, es lo primero que hay que resolver.
2. Enlace propio y privado por pareja. El portal apunta hoy a un evento por defecto. Cada pareja necesita su enlace con token, que caduque después de la boda.
3. Confirmaciones de los invitados. Esta es la función que falta y que más valor añade. Hoy la lista de invitados y sus confirmaciones se rellenan a mano, y hay importación por CSV, que ayuda. Lo que el producto pide a gritos es un enlace público que la pareja envíe con sus invitaciones, donde cada invitado confirme, diga si trae acompañante y declare sus alergias. Eso elimina el trabajo más pesado de la pareja, llena la base de datos de la finca sin esfuerzo y alimenta solo la tabla de alergias de la hoja del día. Es la pieza que convierte el portal de "bonito" en "imprescindible".
4. Avisos salientes. Todo el valor del portal depende de que la pareja lo abra. Hace falta email o WhatsApp cuando hay un mensaje nuevo, un pago que vence o una tarea que se acerca.
5. Multi-finca. Nombre, CIF, dirección y coordenadas están en el código como valores por defecto. Sacarlos a configuración es un día de trabajo y es lo que convierte el proyecto en plantilla.
6. Copias de seguridad. Un navegador que se borra se lleva la temporada entera por delante. Esto es consecuencia del punto 1, pero conviene decirlo aparte porque es el argumento con el que un propietario entiende por qué hay backend.

El argumento de venta

No vendas software de gestión. Vende el sábado que no se pierde y la boda que no sale mal.

El pitch, en la visita:

"¿Cuántas parejas te escriben al mes preguntando por una fecha que ya tienes vendida? ¿Y cuántas veces has tenido que buscar en WhatsApp a qué hora llegaba el fotógrafo? Te monto tu web con el calendario de disponibilidad en vivo, para que esas parejas vean la fecha ocupada antes de escribirte, y para que las que sí tienen fecha libre entren como solicitud directamente en tu sistema. Y el día de la boda tu coordinadora imprime una hoja con el minuto a minuto, los proveedores por hora y las alergias mesa por mesa. Sin buscar nada."

Para rematar, la cifra: la finca se lleva más de la mitad del presupuesto de la boda. Es el proveedor más caro del día. Y es el único que todavía organiza ese día en una hoja de cálculo.

Por dónde empezar a vender

El primer cliente se busca en noviembre. Y lo que necesitas de él no es dinero, son las fotos de su finca funcionando con tu sistema y la frase de su coordinadora.

Los canales:

• Asociaciones de fincas y espacios para eventos, y los grupos privados de propietarios. Es un sector pequeño donde todo el mundo se conoce y se copian las cosas que funcionan.
• Wedding planners. Trabajan con muchas fincas y sufren en primera persona la que lo lleva mal. Son el mejor prescriptor del sector y nadie los trabaja como canal de software.
• Ferias de bodas y eventos profesionales, en temporada baja, que es justo cuando se toman estas decisiones.
• Las propias fincas de tu provincia, una a una. Son 1.980 en toda España. En una provincia normal hay entre 20 y 60. Se pueden visitar todas.

Lo que no funciona: vender "digitalización". La finca no quiere digitalizarse, quiere llenar sábados y que no se le queme ninguno.

Nichos donde el mismo sistema se vende igual

El patrón (web con disponibilidad real + ficha única + portal del cliente + documento operativo del día) encaja en cualquier negocio de aforo, fecha y día único:

• Salones de celebraciones urbanos, comuniones y bautizos, con más volumen y menos ticket.
• Hoteles con bodas, que tienen PMS para habitaciones pero gestionan los eventos al margen.
• Catering de eventos, donde el minuto a minuto y los cubiertos por tipo son exactamente el mismo problema.
• Bodegas y espacios singulares que alquilan para eventos de empresa.
• Casas rurales grandes que se alquilan completas para celebraciones.
• Organizadores de congresos y jornadas corporativas, cambiando el portal de la pareja por el del cliente corporativo.

El más interesante económicamente es el de grupos con varios espacios, porque ahí la disponibilidad cruzada y el panel de ocupación multiplican su valor, y porque pagan por sede.

Qué llevarte de aquí

Velaria es la demo más completa de esta serie, pero sigue siendo una demo: sin backend, con los datos en un navegador y con una sola finca escrita en el código. Dicho sin adornos, para que nadie lo venda como lo que no es.

Lo que sí es transferible y sí se cobra es la arquitectura: meter el dato una vez y hacer que salga por tres sitios, cada uno escrito para su lector. La pareja, el equipo del día y el público. La misma boda contada de tres maneras, sin duplicar trabajo y sin exponer lo que no toca.

Y una lección de posicionamiento que vale para toda la serie: cuando hay competencia buena, no se gana por funciones. Se gana eligiendo el cliente que a esa competencia no le sale rentable atender, y entregándole algo cerrado, a precio visible, que incluya la pieza que ellos no tocan. Aquí esa pieza es la web.

Fuentes de los datos de mercado

• INE, Estadística de Matrimonios / Movimiento Natural de la Población 2024
• Bodas.net, Informe del Sector Nupcial 2026: cuánto cuesta una boda en España
• The Objective: las bodas religiosas caen un 42% en España en los últimos diez años
• Directorio de fincas para bodas de Bodas.net
• Parker Solutions, ERP Enterprise para grandes salones y fincas de eventos
• OfiEventos, ficha de producto y precios en ComparaSoftware