01 · Análisis estratégico de las 4 opciones de arquitectura RadiaPet

Documento de trabajo. Razonamiento profundo, números reales, y trade-offs que el consejo debe validar. Autor inicial: Gonzalo Monzón (CTO). Pendiente de feedback de Elisa, David, asesores externos y al menos 2 perfiles veterinarios reales.

Actualización: Se añade una dimensión transversal (sección 4-bis) sobre estrategia de dominio: dominios independientes (radiapet.com) vs subdominios de marca paraguas (radiavet.cadences.app, modelo "Cadences = empresa, Radia/RadiaVet = productos", al estilo Microsoft Office, Google Workspace o Adobe Creative Cloud). Esta decisión es ortogonal a las opciones A/B/C/D y debe debatirse en paralelo.

0. Punto de partida — ¿qué es "una app" en arquitectura Cloudflare?

Antes de hablar de "uno o dos frontales", hay que entender que con Cloudflare Pages + Functions + D1 + R2 la frontera tradicional "front vs back" es difusa:

• El front es estático (Astro build → HTML/JS/CSS) servido en CDN. Coste prácticamente cero.
• El back es Workers serverless ejecutándose en el edge. Se factura por petición.
• La DB (D1) y el storage (R2) son recursos que se conectan vía bindings — múltiples Workers pueden compartirlos sin penalización.

Esto cambia radicalmente el cálculo respecto a infra tradicional (VPS, contenedores, Kubernetes). Duplicar un frontend en Cloudflare cuesta 0€/mes. Duplicar un backend cuesta solo en función del tráfico real, no de "tener una instancia encendida". Por eso aquí la conversación no es de coste de infra — es de coste de mantenimiento humano y coherencia de marca y producto.

1. Opción A — Una sola app, un dominio (status quo + pestaña)

Descripción

Mantener todo dentro de radia.cadences.app (o el dominio comercial actual de Radia). El veterinario entra al mismo sitio que el médico humano y selecciona "Veterinaria" como sector. La UI ya cambia según dialogSector. Cero trabajo nuevo.

Pros

• Coste técnico real: 0 €. Cero líneas de código nuevas.
• Iteración compartida: Cada mejora en prompts, UX, billing beneficia inmediatamente a ambos verticales.
• Análisis de uso unificado: Una sola base de métricas para entender qué patrones funcionan.
• Equipo único: Soporte, devops, on-call son los mismos.

Contras

• Marca confusa: Un veterinario que ve "Radia — diagnóstico por imagen" duda si es para él. Conversión orgánica baja.
• GTM imposible de focalizar: No puedes hacer una landing de "RadiaPet para clínicas veterinarias" sin que el visitante aterrice en una experiencia genérica.
• SEO fragmentado: Compites contra ti mismo en queries como "IA radiografía perro" desde un dominio que también rankea para "IA radiografía humano".
• Pricing único forzado: O subes el precio veterinario a niveles humanos (caro para el vet) o bajas el humano (canibalizas margen).
• Conversaciones comerciales contaminadas: "Sí, también lo usan veterinarios" mata credibilidad ante un radiólogo humano. "Sí, también lo usan médicos humanos" mata credibilidad ante un vet que necesita sentir que el producto es para él.
• Riesgo regulatorio cruzado: Si entras en CE médico humano, debes proteger toda la app. Si separas el vet (que NO es producto sanitario en EU bajo MDR), te ahorras carga regulatoria en ese vertical.

Cuándo elegirla

Solo si decidimos que RadiaPet no es prioridad estratégica en 2026 y queremos optimizar al máximo el coste de oportunidad técnico para enfocarnos en mercado humano.

Veredicto provisional del CTO

Descartable salvo que el consejo decida pausar la apuesta veterinaria. La fricción de marca y GTM es real y crece con cada euro invertido en marketing.

2. Opción B — Dominio espejo, misma app (white-label de uno mismo)

Descripción

La misma storefronts/radia/ exacta, desplegada dos veces en Cloudflare Pages bajo dos dominios:

• radia.com (o el dominio actual) → experiencia "humana" por defecto
• radiapet.com (o radiavet.com) → misma app, pero la home detecta el dominio y fuerza sector="veterinary" desde la primera pantalla, oculta los sectores médico y botánico, cambia logo, paleta y copys

Implementación: una variable de entorno PUBLIC_BRAND ∈ {radia, radiapet} consumida por un componente <BrandProvider> que decide:

• Logo y favicon
• Paleta Tailwind (CSS vars)
• Sectores visibles
• Copys de la home y onboarding
• Pricing mostrado en la página de planes
• Meta tags / OG / SEO
• Email del soporte (soporte@radiapet.com vs soporte@radia.com)

El backend es exactamente el mismo Worker, las mismas tablas D1, el mismo R2. Una columna brand en radia_studies y radia_users permite filtrar/segmentar.

Pros

• Marca diferenciada al 100%: Un veterinario en radiapet.com ve un producto veterinario. Cero confusión.
• SEO independiente: Dos dominios, dos estrategias de contenido, dos perfiles de backlinks.
• Pricing diferenciado: Misma DB, planes distintos según brand.
• GTM focalizado: Landing, ads, email marketing y partnerships independientes.
• Coste técnico bajo: 1-2 semanas de trabajo para extraer el BrandProvider, parametrizar copys y desplegar el segundo Pages project.
• Coste operativo nulo: Sigue siendo un solo codebase, una sola CI/CD, un solo on-call.
• Migración futura sin dolor: Si en 18 meses RadiaPet justifica su propia stack, ya tenemos la separación lógica hecha (tabla brand, copys aislados, etc.).
• Iteración 2x más rápida: Cada mejora del core (prompts, billing, auth, UX) beneficia a ambas marcas el mismo día.

Contras

• Divergencia de producto difícil: Si RadiaPet necesita un flujo de onboarding radicalmente distinto (p. ej. integrar con software de gestión veterinaria tipo Vetesia o Qvet), meterlo en el mismo codebase añade if brand === 'radiapet' por todos lados. Manejable hasta cierto umbral.
• Riesgo de confusión interna: Devs y soporte deben recordar siempre "esto aplica a una marca o a las dos". Mitigable con tests y documentación.
• Reportes de uso requieren filtro: Las métricas globales no son útiles sin segmentar por brand.
• Un fallo en el backend afecta a las dos marcas: Blast radius compartido.

Coste real estimado

Coste mensual recurrente extra: 0 € (Cloudflare Pages es gratis hasta 500 builds/mes y los Workers se facturan por uso real).

Cuándo elegirla

Si creemos que RadiaPet merece su propia identidad comercial pero todavía no tiene tracción suficiente para justificar un equipo separado. Es la opción más reversible: si funciona, evolucionas a C; si no funciona, repliegas a A en un día apagando un Pages project.

Veredicto provisional del CTO

Recomendada para los próximos 6-9 meses. Permite probar la tesis veterinaria con riesgo mínimo y opción de escalar.

3. Opción C — Frontends separados, backend compartido

Descripción

Dos repos/carpetas de frontend independientes:

• storefronts/radia/ — humano (médico + botánico)
• storefronts/radiapet/ — veterinario puro

Comparten una librería interna (packages/radia-core/ o similar) con:

• Componente DICOM uploader
• Hooks de auth, billing, fetch
• Tipos compartidos
• Cliente de la API

El backend (functions/) sigue siendo único, sirviendo a ambos dominios con CORS configurado.

Pros

• Libertad total de UX: RadiaPet puede tener un onboarding radicalmente distinto, integraciones específicas (PACS vet, software de gestión clínica), flujos propios sin contaminar el core humano.
• Equipos pueden separarse: Un dev puede trabajar en RadiaPet sin tocar Radia y viceversa.
• Releases independientes: Bug en Radia humano no bloquea release de RadiaPet.
• Diseño realmente nativo del sector: Un vet ve una app pensada para vets, no una app humana adaptada.
• Backend sigue siendo único: Cero coste extra de infra, una sola fuente de verdad para datos y billing.

Contras

• Coste inicial significativo: Hay que extraer la librería compartida, montar monorepo (turbo/nx/pnpm workspaces), configurar CI/CD para dos builds, mantener dos sets de tests.
• Drift de UX: Sin disciplina, ambas apps divergen en patrones (botones, modals, formularios) y la "marca Cadences" se diluye.
• Doble bug surface en frontend: Cada feature del core debe probarse en ambas apps.
• Onboarding de devs más largo: Hay que entender la librería compartida + 2 apps.
• Backend monolítico crece: Cada vez que añadimos una feature vet, contamina el código compartido con if isVeterinary.

Coste real estimado

Coste mensual recurrente extra: 0-30 € (más builds en Cloudflare Pages, posible plan team de Cloudflare si superamos límites gratuitos).

Cuándo elegirla

Cuando RadiaPet haya validado tracción (>50 clientes pagantes o >€3-5K MRR) y la UX humana le esté quedando demasiado estrecha o demasiado ancha. Es el siguiente paso natural desde B si la apuesta veterinaria funciona.

Veredicto provisional del CTO

Apuesta a 9-18 meses. Buena en cuanto haya tracción confirmada.

4. Opción D — Producto totalmente separado (front + back + DB)

Descripción

RadiaPet se convierte en un producto/empresa hermana con:

• Repo propio (projectos/radiapet/ o repo separado en GitHub)
• Frontend propio
• Backend propio (sus propias D1, R2, Workers)
• Auth propia (o federada vía OAuth)
• Billing separado (sus propias suscripciones Stripe)
• Equipo dedicado (al menos 1 PM + 1 dev + 1 comercial)

Pros

• Independencia total: RadiaPet puede pivotar, ser vendida, recibir inversión propia, hacer integraciones agresivas con players veterinarios sin afectar a Radia.
• Regulación aislada: Si Radia entra en CE Class IIa para humano, RadiaPet no carga con la complejidad regulatoria.
• Equity story más limpia: Más fácil contar a un inversor "RadiaPet, líder español de IA veterinaria de imagen" que "el vertical vet de Radia".
• Equipos especializados: Un comercial veterinario solo vende RadiaPet. Un equipo de producto piensa solo en clínicas veterinarias.
• Posibilidad de venta/spin-off: Compradores estratégicos veterinarios (IDEXX, Mars Petcare, fondos) compran productos puros, no "verticales de un humano".

Contras

• Coste inicial alto: 3-6 meses de bootstrapping. Requiere PM y comercial dedicados.
• Doble mantenimiento perpetuo: Cada mejora del core debe portarse manualmente. El esfuerzo se multiplica con el tiempo.
• Doble infraestructura: Aunque Cloudflare es barato, hay duplicación de auth, billing, observability, on-call, soporte, legal, GDPR, etc.
• Pérdida de network effects internos: No puedes ofrecer descuento cruzado a una clínica multi-veterinaria que también tenga consultas humanas.
• Coste oportunidad: Cada hora invertida en bootstrap de RadiaPet es una hora no invertida en cerrar clientes Radia humanos.
• Riesgo de morir doble: Dos productos sub-críticos compiten por el mismo bolsillo de Cadences Lab.

Coste real estimado

Cuándo elegirla

• Si RadiaPet supera €15-20K MRR sostenido (ya paga su propia operación)
• Si aparece un comprador estratégico que valora la separación
• Si Radia humano necesita aislar regulación CE y RadiaPet le frena
• Si conseguimos un co-fundador veterinario con cap table propio para RadiaPet

Veredicto provisional del CTO

Prematuro hoy. Es la dirección final correcta si RadiaPet despega, pero saltar a esto desde cero sin tracción es el error más caro posible. ROI negativo durante 12-24 meses sin garantías.

4-bis. Dimensión transversal — Estrategia de dominio (¡decisión clave!)

Esta dimensión es ortogonal a las opciones A/B/C/D. Cualquiera de ellas puede ejecutarse con dominio propio, con subdominio paraguas, o con ambos a la vez. Pero la decisión tiene un impacto enorme en marca, SEO, GTM y narrativa de empresa.

El planteamiento

Hoy tenemos cadences.app como dominio raíz y los productos viven debajo (radia.cadences.app, etc., además de los dominios comerciales propios). Pregunta de fondo:

¿Qué somos como empresa?

• ¿Cadences Lab es la empresa-paraguas con un catálogo de productos (Radia, RadiaVet, FichaYa, NutriNen, …), al estilo Microsoft Office (Word, Excel, PowerPoint), Google Workspace (Gmail, Docs, Drive), Adobe Creative Cloud (Photoshop, Illustrator) o Atlassian (Jira, Confluence, Trello)?
• ¿O cada producto es una marca-empresa independiente que vive sola, al estilo Stripe, Notion o Figma?

No es una decisión de DNS. Es una decisión de identidad corporativa que arrastra años de inercia.

Las 3 estrategias de dominio reales

Estrategia D1 — Dominios independientes por producto (radia.com, radiapet.com, fichaya.com)

Cada producto es su propio universo. Cadences Lab solo aparece en el footer y en facturas.

Pros

• Marca de producto fuerte y enfocada — el cliente no se distrae con el resto del catálogo.
• SEO independiente, sin que un dominio "tire" del otro en buena o mala dirección.
• Posibilidad real de venta/spin-off de un producto sin tocar al resto.
• Encaja con la narrativa "indie / startup / disruptor" si esa es la posición.

Contras

• Cada dominio cuesta dinero (€10-50/año), gestión DNS, certificados, monitorización.
• Brand equity fragmentada: el cliente que adora Radia no descubre orgánicamente RadiaVet.
• Cross-sell artificial: tienes que "vender" cada producto desde cero, sin apoyarte en la confianza ya ganada.
• Sin marca corporativa fuerte → más difícil contratar talento ("¿para qué empresa trabajo?"), más difícil ronda de inversión ("¿qué empresa estoy financiando, una o cinco?"), más difícil prensa ("¿de quién es esta noticia?").
• Riesgo de percepción de fragilidad: cinco dominios pequeños en lugar de una empresa sólida.

Ejemplos del mundo: Stripe, Notion, Figma, Linear (cada uno su dominio, una sola "cosa" por marca). Coincide con empresas mono-producto o con producto estrella claro.

Estrategia D2 — Subdominios bajo marca paraguas (radia.cadences.app, radiavet.cadences.app, fichaya.cadences.app)

Cadences es la empresa y la marca corporativa. Los productos son inquilinos del paraguas.

Pros

• Brand equity acumulativa: cada cliente nuevo de cualquier producto refuerza "Cadences" como marca de tecnología fiable. A los 18 meses tienes una marca corporativa real, no cinco micro-marcas anémicas.
• Cross-sell orgánico gratis: el footer y header de RadiaVet pueden enseñar "También de Cadences: Radia, FichaYa, NutriNen". El cliente que prueba uno descubre el resto.
• SEO transferible (parcialmente): el dominio cadences.app acumula autoridad y backlinks; cada subdominio nuevo se beneficia parcialmente (Google trata subdominios como semi-independientes — ni completamente unidos ni completamente separados).
• Coste técnico ridículo: un solo dominio, un solo certificado wildcard, una sola gestión DNS. Cloudflare lo da gratis.
• Narrativa coherente para inversores y prensa: "Cadences Lab construye software vertical de IA, ya tiene 5 productos en producción". Mucho más sólido que "tenemos 5 startups separadas".
• Más fácil contratar: "Trabaja en Cadences" es una oferta más atractiva que "trabaja en Radia o RadiaPet o FichaYa según el día".
• Recuerda al modelo Microsoft / Google / Adobe / Atlassian: empresa fuerte + productos diferenciados, todos bajo paraguas.

Contras

• Marca de producto más débil al inicio: radiavet.cadences.app suena "menos serio" que radiavet.com para algunos clientes B2B muy tradicionales. (Mitigable con buen diseño y comms.)
• Riesgo de contagio reputacional: si un producto la lía (downtime, bug grave, escándalo), salpica al resto. Mitigable con comunicación clara y aislamiento operativo.
• Spin-off futuro más complejo: si en 3 años quieres vender RadiaVet, los clientes están emocionalmente vinculados a cadences.app. El comprador deberá hacer migración de dominio (gestionable, pero fricción).
• Menos prestigio en sectores muy conservadores: en medicina humana muy formal o sectores enterprise tradicionales (banca, gran industria), .cadences.app puede percibirse como "menos empresa". En vet, óptica, dental — irrelevante.

Ejemplos del mundo:

• Microsoft Office: word.com no existe; Word es un producto dentro de Microsoft 365 (office.com).
• Google Workspace: Gmail vive en mail.google.com, Docs en docs.google.com. Nunca fueron dominios separados serios.
• Adobe Creative Cloud: Photoshop, Illustrator, Premiere — todos bajo adobe.com/products/... o *.adobe.com.
• Atlassian: jira.atlassian.com (¡incluso después de comprar marcas!), trello.com mantenido sólo por herencia histórica.
• Salesforce: salesforce.com con productos como Sales Cloud, Service Cloud, Marketing Cloud — todos bajo el paraguas.
• AWS: aws.amazon.com con 200+ servicios bajo el paraguas, ninguno con dominio propio.

Patrón claro: cuanto más serio quieres parecer como empresa de software, más conviene la estrategia paraguas. Las empresas que más venden software vertical en el mundo (Microsoft, Adobe, Salesforce, AWS) todas usan paraguas.

Estrategia D3 — Híbrida: paraguas por defecto + dominio propio cuando madura

El producto nace bajo subdominio (radiavet.cadences.app). Cuando alcanza tracción y madurez (p. ej. >€10K MRR o validación clara), adquiere su dominio propio y mantiene un redirect 301 desde el subdominio.

Pros

• Se obtiene el beneficio de marca paraguas en la fase frágil (0 → tracción).
• Cuando el producto puede sostener su propia marca, se libera con dominio propio sin haber malgastado SEO en uno que quizá no funcione.
• Cada lanzamiento nuevo es bajo paraguas — coste casi cero de probar nuevos verticales.
• Permite migrar SEO sin perder ranking (canonical + 301 bien hecho transfiere ~95% del juice).

Contras

• Requiere disciplina interna: hay que definir el umbral de "graduación" y cumplirlo.
• Coste único de migración de dominio cuando ocurre (1-2 semanas dev + comms a clientes).
• Si nunca se gradúa, queda en el paraguas indefinidamente (lo cual no es problema, solo es… opción D2).

Ejemplos del mundo:

• Loom vivió como subdominio interno antes de ser su dominio propio.
• Slack comenzó como herramienta interna de Tiny Speck antes de su dominio.
• Inverso: Trello fue absorbido por Atlassian y mantiene su dominio histórico, mostrando que ambas direcciones funcionan.

Comparativa de las 3 estrategias de dominio

El paralelismo Microsoft Office (importante leerlo)

La pregunta del usuario fue muy precisa: "así ganaríamos como marca Cadences y lo de Radia es un producto, ¿no? como Office de Microsoft".

Sí, exactamente ese es el modelo D2/D3. Y funciona porque:

1. Microsoft no vende Word — vende Microsoft Word. El "Microsoft" delante es lo que da confianza al CIO que firma la compra.
2. Cuando Microsoft lanza un producto nuevo (Teams, Copilot, Loop), nace YA con la marca paraguas. No tiene que construir reputación desde cero; hereda la de Microsoft.
3. El cliente que compra Word ya está predispuesto a probar Excel. Cross-sell sin coste de adquisición adicional.
4. Microsoft puede matar productos sin manchar la marca corporativa. (Encarta, Zune, Kin, Groove). Si fueran dominios separados con marca propia, cada cierre habría sido un escándalo público.

Aplicado a Cadences Lab:

• Cadences = la empresa que sabe construir software vertical de IA con criterio clínico/operativo. Esa es la promesa.
• Radia, RadiaVet, FichaYa, NutriNen, Cloud RIS = productos del catálogo. Cada uno con su personalidad pero todos respaldados por la confianza acumulada de Cadences.
• Si en 12 meses lanzas un sexto producto (p. ej. CadencesDerma para dermatología), no parte de cero — parte de "del equipo de Cadences que también hace Radia y RadiaVet".

Riesgo del modelo paraguas: si la marca paraguas no se cuida, queda como "empresa genérica de software" sin alma. Mitigación: invertir en una landing principal de cadences.app realmente buena, con caso de uso, testimonios, equipo, valores. Hoy esa landing no existe en condiciones — y es probablemente el punto más débil del modelo si lo elegimos.

Decisión propuesta sobre dominio (a debatir)

Recomendación CTO: adoptar estrategia D3 (híbrida) con default fuerte hacia D2 durante 2026. En concreto:

1. Lanzar RadiaPet como radiavet.cadences.app (subdominio del paraguas) en cuanto ejecutemos la opción de arquitectura B/C.
2. Comprar defensivamente los dominios radiavet.com, radiavet.es, radiapet.com, radiapet.es (≤200 € total) para que nadie se nos adelante. No usarlos todavía, solo redirigirlos al subdominio paraguas.
3. Invertir en serio en cadences.app como landing corporativa — equipo, productos, valores, casos. Es el activo de marca a largo plazo.
4. Definir umbral de graduación: si un producto supera €10K MRR sostenido durante 3+ meses, evaluar migración a su dominio propio con redirect 301 desde el subdominio. Hasta entonces, vive en el paraguas.
5. Comunicar siempre "X de Cadences" en presentaciones, prensa y comerciales: "Radia, de Cadences", "RadiaVet, de Cadences". Construye marca paraguas de forma deliberada.

Sinergia con las opciones A/B/C/D

Implicaciones operativas concretas si elegimos D2 (paraguas)

• Wrangler / Pages: desplegar radiavet como nuevo Pages project con custom domain radiavet.cadences.app (Cloudflare lo gestiona automáticamente con cert wildcard).
• Auth: cookies de sesión con dominio .cadences.app permiten SSO transparente entre productos ("inicia sesión una vez, accede a Radia, RadiaVet, FichaYa"). Esto es un activo enorme casi gratis.
• Billing: una cuenta de cliente puede tener varias suscripciones a productos del paraguas. Stripe lo soporta con Customer único + múltiples Subscription.
• Email: soporte@cadences.app o vet@cadences.app son más sólidos que múltiples buzones por producto.
• Footer global: "Cadences Lab · Radia · RadiaVet · FichaYa · NutriNen · Cloud RIS" en todas las apps refuerza paraguas + invita cross-sell.

5. Comparativa numérica resumida (TCO 12 meses)

Suponemos un escenario base realista pero optimista: RadiaPet alcanza €2K MRR al mes 6 y €5K MRR al mes 12.

6. ROI esperado por opción (mejor caso, base, peor caso)

Asumimos:

• LTV medio cliente vet pro: €600-1.200/año (€29-99/mes × 12-18 meses)
• CAC vet (orgánico + outbound ligero): €80-180
• Pricing supuesto: planes €0 / €19 / €49 / €149 enterprise

Escenario base (12 meses): 60 clientes vet pagantes (€2.5K MRR ≈ €30K ARR)

Escenario optimista (12 meses): 150 clientes vet (€7K MRR ≈ €84K ARR)

Escenario pesimista (12 meses): 20 clientes vet (€800 MRR ≈ €10K ARR)

Conclusión numérica: La opción B gana en los tres escenarios con un margen sustancial. La opción D solo es viable en el escenario optimista y aún así apenas break-even.

7. Riesgos transversales (aplican a todas las opciones)

1. Regulación veterinaria: En EU, software veterinario de IA NO es producto sanitario MDR, pero hay matices con el Reglamento de Medicamentos Veterinarios y normativa de bienestar animal por país. Hay que confirmar con asesor regulatorio.
2. Datos clínicos veterinarios: ¿Quién es propietario de la imagen? ¿El dueño de la mascota o la clínica? Hay que clarificar TOS y consentimientos.
3. Integración con software vet: Vetesia, Qvet, IDEXX Cornerstone, ezyVet — cada uno tiene su API o carece de ella. Sin integración, la fricción de uso diario es alta.
4. Validación clínica: Ningún veterinario serio compra IA sin validación. Necesitamos al menos 1 KOL veterinario radiólogo que respalde RadiaPet (idealmente un asesor del consejo).
5. Competencia: SignalPET, Vetology, PicoxIA ya operan en el mercado vet anglosajón. España es relativamente virgen pero llegan rápido.

8. Recomendación del CTO (a debatir)

Ejecutar la opción B en las próximas 2-3 semanas, con plan de migrar a C en cuanto se alcance €3-5K MRR vet sostenido durante 2 meses. No considerar D hasta superar €15K MRR vet o aparecer un evento estratégico (M&A, ronda específica de RadiaPet, etc.).

En la dimensión de dominio: ejecutar D3 con default D2 — lanzar como radiavet.cadences.app, comprar dominios defensivos .com/.es, invertir en cadences.app como marca paraguas, y graduar a dominio propio solo si supera €10K MRR sostenido.

Plan concreto si se aprueba B + D2

1. Semana 1:
   • Refactor BrandProvider y centralización de copys
   • Crear assets RadiaPet/RadiaVet (Elisa lidera con apoyo externo si necesario)
   • Migración D1: añadir columna brand a radia_users y radia_studies
   • Comprar dominios defensivos radiavet.com, radiavet.es, radiapet.com, radiapet.es
2. Semana 2:
   • Crear segundo Pages project con custom domain radiavet.cadences.app
   • Configurar SSO compartido vía cookie .cadences.app (gana cross-product gratis)
   • Pricing veterinario diferenciado en plans.js
   • Landing RadiaVet con onboarding específico bajo paraguas Cadences
3. Semana 3:
   • Refrescar landing principal cadences.app con catálogo de productos visible (Radia, RadiaVet, FichaYa, NutriNen) — clave para que el modelo paraguas funcione
   • Soft launch a base de 10-20 clínicas veterinarias del entorno
   • Métricas separadas por brand en dashboard
   • Iteración en función de feedback

Decisiones que el consejo debe tomar

1. ¿Aprobamos opción B (arquitectura) como hipótesis de trabajo? (sí / no / qué cambiar)
2. ¿Aprobamos estrategia D2/D3 (subdominios paraguas) como modelo de marca? (sí / no / preferimos D1)
3. ¿Nombre comercial? (RadiaPet, RadiaVet, Radia Animal, otro) — recordar que con D2 será [nombre].cadences.app
4. ¿Qué hacemos con cadences.app como landing corporativa? (refresh urgente / mantener / rediseño profundo)
5. ¿Quién lidera el lanzamiento comercial veterinario? (Elisa? un asesor vet? hire fractional?)
6. ¿Pricing de partida para el vertical vet? (mantener tabla Radia, bajar 30%, modelo por-acto vs SaaS, etc.)
7. ¿Compramos dominios defensivos .com/.es ahora aunque no los usemos? (recomendado sí, ~200 € total)
8. ¿KPI de éxito a 6 meses para decidir migrar a C o replegar? (MRR, número de clínicas, NPS, retención)
9. ¿Umbral de "graduación" de subdominio a dominio propio? (€10K MRR? otro métrico?)

9. Anexo — Lo que NO hemos analizado todavía

• Comparativa real con SignalPET y Vetology (precios, features, tracción declarada)
• Tamaño real del mercado veterinario español (nº clínicas con rayos X, ECO, etc.)
• Disposición a pagar de un veterinario español medio
• Ciclo de venta veterinario (¿auto-servicio? ¿touch ligero? ¿demo presencial?)
• Estacionalidad veterinaria (¿hay temporada alta?)
• Posición de los KOLs veterinarios españoles (AVEPA, GEVO, etc.)

Estos puntos deberían cubrirse en la próxima iteración con asesores veterinarios reales en la mesa.