Investigación de mercado — quién hace esto hoy

No estás inventando una categoría: estás replicando un modelo probado y madurando hace 10 años, pero integrando piezas que hoy están dispersas. Estos son los actores reales:

Mapa de competidores

Detalle por competidor

SkaDate / SimChat Console competencia técnica directa

Chatwriters · Cloudworkers · Texting Factory · Remotely4u competencia laboral

AdultFriendFinder referencia B2C

Meete / toChat (y similares en España/LatAm) referencia regional

Fuentes consultadas

Arquitectura técnica

Una sola API Laravel sirve a N frontends. Cada frontend resuelve su marca por dominio. Toda la lógica (cola, mensajes, pagos, retiros) vive en el backend.

Stack propuesto

Diagrama de arquitectura (alto nivel)

Detección de marca por dominio

// app/Http/Middleware/ResolveBrand.php
public function handle($request, $next) {
    $host = $request->getHost();
    $brand = Brand::query()
        ->where('domain', $host)
        ->orWhere('domain', 'LIKE', '%.'.$host)
        ->firstOrFail();

    app()->instance('current.brand', $brand);
    Config::set('brand.id', $brand->id);

    return $next($request);
}

Los 12 módulos del sistema

El corazón del sistema: dos colas que se emparejan

El sistema mantiene dos colas FIFO que se alivian entre sí: una de mensajes pendientes y otra de operadores disponibles. Un dispatcher toma uno de cada lado en cada turno y los empareja. Es la lógica de un despacho de taxis: cuando hay pasajero y hay taxi, sale el viaje. Cuando un operador responde, vuelve al final de la cola de operadores y espera el próximo match (que llega al instante si hay mensajes esperando).

Modelo de dos colas + dispatcher

Por qué dos colas y no una

Ciclo de vida del operador (la cola B)

1. El operador se conecta al panel → entra al final de queue:ops:es.
2. Espera (la espera es bloqueante en Redis con BLPOP: cuesta cero, no consume CPU).
3. El dispatcher lo empareja con un mensaje → el match aparece en su pantalla.
4. Responde y envía. En ese instante, el operador vuelve al final de queue:ops:es.
5. Si hay mensajes pendientes en Cola A, el siguiente match es inmediato. Si no, espera.

Reglas duras del sistema

Reglas duras de la cola

Estados de un mensaje

Pseudocódigo del dispatcher

Un proceso por idioma (Laravel command supervisado) se queda esperando que las dos colas tengan al menos un elemento cada una. Cuando ocurre, hace el match y vuelve a esperar.

// php artisan dispatcher:run --lang=es
// Un proceso por idioma · ligero · bloqueante en Redis
while (true) {
    // BLPOP bloquea hasta que haya un mensaje. Cuesta 0 CPU.
    [$_, $msgId] = Redis::blpop(["queue:msgs:{$lang}"], 0);

    // Ahora necesitamos un operador libre. Tomamos del principio (FIFO).
    [$_, $opId]  = Redis::blpop(["queue:ops:{$lang}"], 0);

    // Match → asignar
    $msg = ClientMessage::find($msgId);
    $msg->update([
        'status'          => 'assigned',
        'assigned_op_id'  => $opId,
        'assigned_at'     => now(),
    ]);

    // Empuja el mensaje al panel del operador vía WebSocket
    broadcast(new MessageAssigned($msg, $opId))->toOthers();

    // Watchdog: si en 2 min no responde, devolvemos el mensaje a Cola A
    // y removemos al operador de Cola B
    dispatch(new MatchTimeoutCheck($msg->id, $opId))->delay(now()->addMinutes(2));
}

Cuando el operador envía la respuesta:

// POST /api/operator/messages/{id}/reply
public function reply(Request $r, $msgId) {
    $op  = auth()->user();
    $msg = ClientMessage::findOrFail($msgId);

    // Validar reglas (longitud, pregunta, anti-fuga)
    $this->validateReply($r->body, $msg->body);

    // Guardar respuesta + acreditar comisión
    OperatorReply::create([...]);
    Wallet::credit($op->id, $op->tier->per_message_pay);

    // **Clave**: devolver al operador a la cola B al final
    Redis::rpush("queue:ops:{$op->lang}", $op->id);

    // Push al cliente
    broadcast(new ClientReplied($msg, $r->body));

    return ['ok' => true];
}

Conexión y desconexión del operador:

// Operador abre el panel
public function goOnline() {
    Redis::rpush("queue:ops:{$op->lang}", $op->id);
}

// Operador cierra panel · timeout · idle
public function goOffline() {
    Redis::lrem("queue:ops:{$op->lang}", 0, $op->id);
}

Modelo económico

Cada mensaje es una transacción con tres partes: el cliente paga, el operador cobra, la plataforma se queda con el spread (menos la comisión que pasa a la marca si la marca no es tuya).

Precios al cliente — packs de créditos

Replicamos la curva de precios validada por el mercado (Chatwriters / Meete / toChat). El cliente nunca compra mensajes sueltos: siempre packs, con descuento creciente.

Precio congelado al comprar pack

Pago al operador — tiers por volumen semanal

Replicamos el patrón "más mensajes = mejor tarifa" que usa Chatwriters y otros (gamifica la productividad y reduce rotación).

Mínimo obligatorio para mantenerse activo: 200 msg/semana. Si baja 2 semanas seguidas → pausa automática del operador (libera slot para reclutar).

Calculadora interactiva

Otras fuentes de ingreso (multi-revenue)

Roles y pantallas

Cuatro roles. Cada uno ve un producto distinto. La calidad de la operación depende de la calidad de la UI del operador (es donde se gana o se pierde productividad).

Esqueleto visual del chat del operador

Captación + onboarding de operadores

Esta es la parte que mencionaste que faltaba en la conversación. Es estratégica: sin operadores no hay producto. Y los marketplaces actuales (Cloudworkers, Chatwriters) ya están compitiendo por la misma mano de obra.

Pipeline de captación

Detalle de cada etapa

Métricas que vigilas como Super Admin

Modelo de datos y API

Schema MySQL simplificado + endpoints REST principales. Todo es multi-tenant por brand_id.

Diagrama ER (simplificado)

Endpoints API críticos

Eventos WebSocket (Reverb)

Roadmap de ejecución

MVP en 8 semanas con 1 marca y 1 idioma. Después escalamos. No intentes lanzar 3 marcas a la vez: vas a quemar foco.

Fase 0 · Pre-trabajo (1 semana antes del MVP)

MVP · 8 semanas (sprints de 1 semana)

Fase 2 · Crecimiento (meses 3–6)

• Captación de operadores con landing dedicada + ads.
• Segunda marca (mismo backend, dominio nuevo, paleta nueva).
• Suscripción premium.
• Contenido bloqueado (PPV media) — operadores pueden mandar fotos pagables.
• App móvil (Expo / React Native) — mismo backend. Plan detallado en la tab "Apps móviles": arranca cuando 1 marca alcance el gate de tracción.
• Reportes avanzados + exportación CSV.
• A/B testing de packs y de copy del onboarding.

Fase 3 · Escalado (meses 6–12)

• Multi-idioma real (EN, PT, FR).
• Pagos con cripto (USDT/USDC vía Coinbase Commerce o NowPayments).
• Anti-fraude avanzado (ML para detectar patrones de chargebacks).
• Marketplace de operadores como producto separado (vendes "operadores certificados" a sites de terceros).
• Integración con LLM (Llama 3.3 / Mistral) para asistir al operador con sugerencias (no autoresponder).
• White-label SaaS — vendes el sistema a terceros con comisión recurrente.

Equipo mínimo recomendado para MVP

Después de MVP, agregas: 1 dev mobile, 1 community/marketing, más team leaders por idioma.

Apps móviles — planificación post-tracción

Las apps móviles no son MVP. Son la apuesta de Fase 2/3 cuando ya tengas 1 marca con tracción demostrada: clientes recargando, operadores produciendo, churn controlado. Lanzar móvil antes es quemar foco y dinero en algo que aún no tiene product-market fit. Pero el backend ya está preparado para soportarlas desde el día 1.

Las tres apps

Diagrama: tres apps, un backend

Stack móvil

Cómo se comparte código entre las N apps de marca

// apps/marca1/App.tsx
import { MorbososApp } from '@morbosos/mobile-core';
import theme from './theme.json';

export default () => (
  <MorbososApp
    brandId="marca1"
    apiBaseUrl="https://api.morbosos.com"
    theme={theme}
    appName="Marca 1"
  />
);

Plan de ejecución móvil

Coste estimado del programa móvil

Riesgos específicos del programa móvil

• Apple rechaza apps "adult-leaning": mitigación = registrar como "social/dating", screenshots suaves, descripción no explícita.
• Google Play tolera más pero exige verificación de edad y aviso explícito.
• Apple 30% IAP: evitable pagando vía web link (deep link de retorno). Riesgo: si Apple cambia política puede sacarte de la tienda.
• App rejection en revisión: presupuestar 2–3 iteraciones de revisión por marca nueva.
• Mantener N apps es trabajo: cada release del core hay que rebuild y republicar las N. EAS Build + script lo automatiza pero requiere disciplina.

Riesgos y mitigaciones

No te decimos qué hacer con los abogados — eso ya está cubierto por ti. Aquí están los riesgos operativos y técnicos que afectan al producto, ordenados por probabilidad × impacto.

Matriz

Decisiones técnicas a tomar ya

Tus comentarios consolidados

Todo lo que escribiste en cada sección queda guardado en este navegador (localStorage). Aquí puedes verlo todo junto, exportarlo y pasárselo al equipo como mejoras o aclaraciones.

Todos los comentarios (0)