El 80% del Esfuerzo en Research-as-a-Service Está en el Sitio Equivocado: Tu Problema No Son los Datos, Es la Arquitectura de Entrega
El 80% del esfuerzo en RaaS va a scraping, pero el churn viene de entregas inconsistentes. Descubre la Arquitectura de 3 Capas para escalar tu servicio productizado.
El 80% del Esfuerzo en Research-as-a-Service Está en el Sitio Equivocado: Tu Problema No Son los Datos, Es la Arquitectura de Entrega
Crees que el cuello de botella en tu Research-as-a-Service es la velocidad de scraping. Que si optimizas rotación de IPs, mejoras los selectores de Playwright, y aumentas el throughput de tus scrapers, tus clientes estarán más contentos.
*Te has equivocado de diagnóstico.*
Tu stack de scraping es increíble. Tus clientes se están yendo igual.
El problema real del productized services business model en RaaS no es la recolección de datos — es la arquitectura de entrega. El 80% del esfuerzo de los equipos de RaaS se va a scraping cuando el 80% del churn viene de entregas inconsistentes, sin formato, y mal estructuradas.
Los equipos con scrapers mediocres pero automatización de entregas excelente están superando a los equipos con scrapers世界一流 (world-class) pero formateo manual. Y no es porque tengan mejores datos. Es porque entienden que *el cliente no paga por datos. Paga por decisiones. *
---
El Problema No Son los Datos. Es Que Ahogas a Tu Cliente en Ellos.
El mito dominante en RaaS es simple: más datos = clientes más felices.
❌ Enfoque equivocado: "Voy a scrapear 10.000 páginas de la competencia de mi cliente para darle una ventaja absoluta."
✅ Enfoque correcto: "Voy a entregar un PDF de una página cada lunes con los 3 cambios de pricing más relevantes, codificados por color de impacto."
El enfoque equivocado asume que el valor está en el volumen de datos. El enfoque correcto entiende que *el valor está en la reducción de fricción cognitiva. *
Cuando entregas 10.000 filas en crudo, no estás resolviendo un problema — se lo estás trasladando a tu cliente. Le dices: "Aquí tienes los datos. Ahora descubre tú qué importa."
El productized services business model muere ahí. El cliente no pagó para hacer el trabajo de analista. Pagó para recibir una decisión empaquetada.
---
El Patrón de las 3 Capas: La Única Arquitectura de Delivery Que Escala
Construí este sistema tras ver a decenas de operadores de RaaS en España estrellarse contra el mismo muro. Después de 4 años enviando productos como conversoriaecnae.es o gestoriascercademi.com, vi el patrón claro.
El framework se llama "Arquitectura de 3 Capas para Delivery RaaS" y se inspira en cómo funcionan las plataformas API exitosas.
Stripe no vende procesamiento de pagos. Vende una experiencia de desarrollador con dashboards bonitos, outputs predecibles, y abstracciones limpias. Twilio no vende envío de SMS. Vende una API que cualquier desarrollador entiende en 5 minutos.
Tu RaaS no vende datos. *Vende documentos listos para decisión. *
Capa 1: Colección (La Capa Fina)
La capa de colección debe ser deliberadamente delgada. Lo que la mayoría hace mal: construir scrapers monstruosos que limpian, transforman y formatean los datos en el mismo pipeline.
No.
La capa de colección solo hace una cosa: traer datos en bruto. Punto.
```python
Capa de Colección - Thin scraper que solo recoge datos
import asyncio
from playwright.async_api import async_playwright
async def collect_competitor_pricing(urls: list[str]) -> list[dict]:
"""Solo recoge. No limpia. No formatea. No decide."""
raw_data = []
async with async_playwright() as p:
browser = await p.chromium.launch()
for url in urls:
page = await browser.new_page()
await page.goto(url, wait_until="networkidle")
raw_data.append({
"url": url,
"timestamp": datetime.utcnow().isoformat(),
"html": await page.content(), # HTML en bruto
"screenshot": await page.screenshot(full_page=True)
})
await page.close()
await browser.close()
return raw_data
```
Nada más. HTML en bruto. Timestamp. URL. La limpieza viene después. Esto te permite cambiar el scraper sin tocar la lógica de negocio.
Capa 2: Estructuración (Donde Vive el Moat)
Aquí es donde separas a los profesionales de los aficionados.
La capa de estructuración recibe datos brutos y produce esquemas validados, deduplicados y consistentes. Usa modelos Pydantic para garantizar que cada entrega tenga exactamente la misma estructura — independientemente de la fuente.
```python
Capa de Estructuración - Pydantic models con validación
from pydantic import BaseModel, Field, validator
from datetime import datetime
from typing import Optional
class PricingChange(BaseModel):
competitor_name: str
product_name: str
old_price: Optional[float] = None
new_price: float
currency: str = "EUR"
change_type: str = Field(...) # "increase", "decrease", "new"
detected_at: datetime
source_url: str
confidence_score: float = Field(ge=0.0, le=1.0)
@validator("change_type")
def validate_change_type(cls, v):
allowed = {"increase", "decrease", "new", "removed"}
if v not in allowed:
raise ValueError(f"Tipo de cambio no válido: {v}")
return v
class WeeklyPricingReport(BaseModel):
client_id: str
week_ending: datetime
changes: list[PricingChange]
total_changes: int
critical_changes: int = Field(ge=0)
```
Este modelo fuerza consistencia. Cada PricingChange tiene exactamente los mismos campos. Cada WeeklyPricingReport produce `total_changes` y `critical_changes` calculados automáticamente.
El resultado: puedes generar 100 informes para 100 clientes diferentes y saber que todos tienen la misma estructura. Tu cliente de la semana 52 recibe exactamente el mismo formato que el de la semana 1.
Capa 3: Entrega (El Último Kilómetro)
La capa de entrega es donde la mayoría de los equipos de RaaS sangran horas. Formateo manual, ajustes de Excel, "este cliente lo quiere en PDF pero con bordes azules".
La solución: plantillas parametrizadas.
```python
Capa de Entrega - Jinja2 template para informes automatizados
from jinja2 import Environment, FileSystemLoader
import pdfkit
from datetime import datetime
env = Environment(loader=FileSystemLoader("templates/"))
def generate_client_report(report: WeeklyPricingReport, template_name: str = "default") -> str:
template = env.get_template(f"{template_name}_report.html")
impact_color = {
"increase": "#FF4444",
"decrease": "#44BB44",
"new": "#4488FF",
"removed": "#888888"
}
html_content = template.render(
client_name=report.client_id,
week=report.week_ending.strftime("%d/%m/%Y"),
changes=report.changes,
total=report.total_changes,
critical=report.critical_changes,
impact_color=impact_color,
generated_at=datetime.now().strftime("%H:%M del %d/%m/%Y")
)
Output en múltiples formatos desde la misma fuente
output_paths = {
"html": f"outputs/{report.client_id}/weekly_{report.week_ending.date()}.html",
"pdf": f"outputs/{report.client_id}/weekly_{report.week_ending.date()}.pdf"
}
with open(output_paths["html"], "w") as f:
f.write(html_content)
pdfkit.from_string(html_content, output_paths["pdf"])
return output_paths["pdf"]
```
Con esto, un scraper mediocre + una pipeline de estructuración sólida + una capa de entrega automatizada produce informes impecables cada semana sin intervención humana.
---
El Framework de 5 Pasos para Automatizar tu Delivery RaaS
Lo construí iterando sobre los proyectos que he enviado. Cada paso resuelve una fuga concreta de margen.
Paso 1: Audita tu Reparto de Esfuerzo
Mide horas de scraping vs horas de formateo y entrega.
Si el scraping supera el 50% de tu tiempo de ingeniería, tienes el problema invertido 80/20. Estás optimizando la parte que tus clientes no ven mientras descuidas la única parte que sí ven: el informe final.
Paso 2: Define la Plantilla de Entrega ANTES del Scraper
Esto parece contraintuitivo. La mayoría empieza por "¿qué datos necesito?" y luego "¿cómo los entrego?"
Hazlo al revés.
Siéntate con tu cliente y pregúntale: "¿Cómo quieres recibir esta información? ¿PDF semanal? ¿Excel con pestañas? ¿Dashboard? ¿Qué columnas? ¿Qué colores?"
Diseña el output primero. Luego trabaja hacia atrás para determinar qué datos necesitas recolectar.
Esto elimina automáticamente el 40% de los datos que recolectas y nunca usas.
Paso 3: Construye un Scorecard de Calidad de Entrega
Deja de medir "páginas scrapeadas por hora". Mide:
Tiempo desde scrape hasta informe entregado (target: < 5 minutos)
Score de consistencia de formato (¿todos los informes tienen la misma estructura?)
Revisiones solicitadas por entrega (target: 0)
El productized services business model se basa en predictibilidad. Si tus entregas son inconsistentes, no tienes un producto — tienes un servicio freelance disfrazado.
Paso 4: Automatiza el Último Kilómetro con CI/CD
Cada scrape debe disparar automáticamente:
1. Validación del esquema
2. Generación del informe (PDF/HTML/Excel)
3. Checks de calidad (¿todos los campos rellenos? ¿sin duplicados?)
4. Subida al servidor del cliente o envío por email
5. Log de entrega
Sin intervención humana. Si tienes que tocar una entrega manualmente, algo en tu pipeline está roto.
Paso 5: Modulariza el 30% de Personalización
La objeción más común: "Pero mis clientes piden formatos diferentes cada vez."
Es cierto. Pero el 70% de la estructura es siempre la misma: resumen ejecutivo, tablas de datos, hallazgos clave, recomendaciones.
Construye un sistema de plantillas donde el 70% es estándar y el 30% es un "slot personalizado" que puedes rellenar con contenido específico del cliente.
Tu plantilla base:
```
┌─────────────────────────────────────┐
│ LOGO DEL CLIENTE (slot personalizado)│
├─────────────────────────────────────┤
│ RESUMEN EJECUTIVO (plantilla fija) │
├─────────────────────────────────────┤
│ TABLA DE DATOS (plantilla fija) │
├─────────────────────────────────────┤
│ HALLAZGOS CLAVE (plantilla fija) │
├─────────────────────────────────────┤
│ SECCIÓN PERSONALIZADA (slot 30%) │
├─────────────────────────────────────┤
│ RECOMENDACIONES (plantilla fija) │
└─────────────────────────────────────┘
```
Esto elimina el rework sin sacrificar la personalización.
---
Por Qué Esto Determina si Sirves a 10 Clientes o a 1.000
El productized services business model en RaaS tiene un techo invisible.
Cuando empiezas, formateas cada entrega manualmente. Funciona para 5 clientes. Para 10 ya empieza a doler. Para 20, necesitas contratar.
El instinto natural es automatizar el scraping. Es visible, técnico, divertido. Construir rotadores de IP, optimizar selectores, escalar workers.
Pero el cuello de botella no está ahí. Está en la entrega.
Automatizar el scraping sin automatizar la entrega es como construir una autopista de 8 carriles que termina en un camino de tierra. Los datos llegan rápido y se acumulan en un embudo que nadie gestiona.
Los equipos que escalan de verdad — los que pasan de 10 a 100 a 1.000 clientes — no tienen los mejores scrapers. Tienen la mejor arquitectura de entrega.
---
Conclusión: El Moat No Son los Datos. Es Cómo los Sirves.
Tu stack de scraping es commodity. Playwright, Scrapy, proxies — cualquiera puede montarlo en un fin de semana.
Lo que no es commodity es la pipeline que convierte HTML en bruto en un PDF impecable que tu cliente abre los lunes a las 9:00 y toma una decisión en 30 segundos.
Esa pipeline — la Arquitectura de 3 Capas para Delivery RaaS — es tu verdadero moat.
Deja de optimizar la recolección. Empieza a diseñar la entrega.
*El que construye el mejor pipeline de entrega, no el que scrapea más páginas, es el que gana. *
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF