Tutol es la oportunidad de los cinco de Arges Lab de volver a sentarse en la misma mesa — esta vez para construir una plataforma global de tutorías on demand.
Erick trajo el proyecto y nos invitó a sumarnos. Hoy es idea + invitación. Lo que sigue es lo que ya tenemos definido y las decisiones que tomamos juntos.
El alumno aprieta "necesito ayuda ahora" y matcheamos con un tutor disponible en vivo. Modelo Uber para educación.
También soportamos el modelo Calendly: reservar con un tutor específico para un día y hora futuros. Ambos modos día uno.
Sistema de calificaciones y perfiles públicos desde el MVP. La comunidad como tal llega en v2.
Los términos legales todavía se están redactando — todo es ajustable. Esta es la estructura tentativa con la que Erick nos invitó.
Erick tiene el 51% y nos invita a los cuatro a compartir ese bloque entre todos. La distribución interna del 51% queda por definir entre nosotros.
Inversor capitalista + persona que hizo la conexión. Esa parte está fija desde el origen del deal.
Son decisiones tomadas en la primera ronda de discusión técnica. Ajustables, pero ya son la base sobre la que avanzamos.
Onboarding diferenciado para tutor y estudiante. Servicios pre-request, post-request y after-session bien definidos.
Real-time, código propio (sobre Yjs). El diferencial técnico vive aquí — no en el video.
Arrancamos con links a Zoom / Meet. Eventualmente movemos a video in-house (LiveKit u otro SFU). Adapter pattern desde día 1.
Cobramos al alumno, retenemos, liberamos al tutor post-sesión. Soporta cancelaciones, no-shows, disputas. Ledger interno propio.
Puede variar por escuela enterprise. Default global ajustable sin deploy.
Arranque en USA + México como mercados de prueba. Multi-currency, multi-timezone, i18n día 1.
El esquema soporta integración de escuelas (cada una con configs propias) desde el día uno. Retrofittear esto después es brutal.
v1 = reviews + perfiles públicos de tutores. Foros / grupos / DMs vienen después con tracción demostrada.
# Modular monolith, NO microservicios. Bounded contexts como módulos de NestJS.
# Multi-tenant con RLS en Postgres desde el modelo de datos.
┌─────────────────────────────────────────────────────────────┐ │ Clients: Web (Next.js) │ Mobile (RN, fase 2) │ Admin │ └─────────────────────────────────────────────────────────────┘ │ HTTPS/REST+GraphQL │ WebSocket ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────────┐ │ API Gateway (BFF) │ │ Realtime Layer │ │ Auth, rate-limit, ABAC │ │ - Presence (tutors online) │ └──────────────────────────┘ │ - Matching dispatch │ │ │ - Collab (Yjs / Hocuspocus) │ ▼ │ - Notifications fanout │ └──────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ Modular Monolith (one deploy, clean module boundaries) │ │ ┌──────────┬─────────┬──────────┬──────────┬────────────┐ │ │ │ Identity │ Catalog │ Matching │ Sessions │ Payments │ │ │ │ Tenancy │ Tutors │ Booking │ Whiteboard│ Stripe │ │ │ │ Auth/RBAC│ Subjects│ Dispatch │ Notes │ Escrow │ │ │ ├──────────┼─────────┼──────────┼──────────┼────────────┤ │ │ │ Reviews │ Disputes│ Admin │ Notif. │ Media │ │ │ │ Ratings │ Refunds │ Console │ Email/SMS│ Adapter │ │ │ └──────────┴─────────┴──────────┴──────────┴────────────┘ │ └─────────────────────────────────────────────────────────────┘ │ │ ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────────┐ │ Postgres (system of │ │ Worker Pool (BullMQ) │ │ record, RLS por tenant) │ │ Post-session, payouts, KYC, │ │ Redis (cache, presence, │ │ emails, recording transcode │ │ queues, pub/sub) │ │ │ │ S3/R2 (assets, archivos)│ │ │ └──────────────────────────┘ └──────────────────────────────┘
{ "frontend_web": "Next.js 15" // App Router + TanStack Query + Tailwind + shadcn/ui "backend_api": "NestJS 11" // monolito modular, módulos = bounded contexts "realtime_collab": "Hocuspocus" // Yjs server, proceso separado, mismo repo "realtime_app": "Socket.IO" // @nestjs/websockets + Redis adapter "orm": "Prisma" // migraciones limpias, multi-schema "database": "Postgres 16" // RLS para multi-tenant "cache_queues": "Redis 7" // presencia, BullMQ, pub/sub "jobs": "BullMQ" // @nestjs/bullmq "storage": "MinIO → GCS" // S3 API → un solo cliente entre dev y prod "auth": "Better Auth" // control total, sin vendor lock "email": "Resend" // + React Email para templates "payments": "Stripe Connect Express" "observability": "OpenTelemetry → Grafana Cloud" "i18n": "next-intl + nestjs-i18n" }
tutol/ ├── apps/ │ ├── web/ # Next.js — alumnos + tutores │ ├── admin/ # Next.js separado — admin.tutol.com │ ├── api/ # NestJS — el monolito modular │ ├── collab/ # Hocuspocus server (Node standalone) │ └── worker/ # BullMQ workers (reusa modules de api/) ├── packages/ │ ├── db/ # Prisma schema + cliente compartido │ ├── shared/ # Tipos, DTOs, zod schemas │ ├── ui/ # Componentes shadcn compartidos │ └── sdk/ # Cliente tipado del API (gen de OpenAPI) ├── infra/ │ ├── docker/ # Dockerfiles │ ├── compose/ # docker-compose.yml para MVP │ ├── k8s/ # Helm charts (futuro) │ └── terraform/ # GCP infra (futuro) └── turbo.json # Turborepo para builds incrementales
Redis sorted sets para colas de matching, WebSocket fanout a tutores candidatos, accept-first-wins con timeout y fallback en cascada.
CRDT serio (Yjs) sobre WebSocket, persistido a Postgres con snapshots a S3. TipTap para notas, tldraw o fork de Excalidraw para whiteboard.
Interfaz MediaRoom con providers
ZoomProvider → DailyProvider → LiveKitProvider.
El día que movemos a in-house, ningún consumer cambia.
Tabla ledger_entries append-only.
Stripe = fuente de verdad de dinero movido. Nuestro ledger = fuente de verdad de qué le debemos a quién.
tenant_id en cada tabla, RLS aplicada vía
SET LOCAL app.tenant_id por request.
Cuando una escuela enterprise pida aislamiento físico → schema dedicado, cero refactor.
apps/api, apps/collab, apps/worker
son procesos físicos distintos pero comparten módulos de Nest. Cero duplicación,
pre-particionado para el futuro.
MVP corre en la PC de Edmundo. Cloudflare Tunnel expone subdominios. Cloudflare Access gatea con allowlist (free hasta 50 usuarios).
Migración cuando el MVP esté validado. El código no cambia — solo el orquestador.
12-factor desde día 1, no opcional. Config por env vars, stateless containers, logs a stdout, migrations idempotentes. La migración Compose → K8s debe ser únicamente un cambio de orquestador, no de código.
Filosofía: lo mínimo para que el flujo end-to-end funcione con 20 usuarios reales en un túnel privado. Cada feature que recortamos hoy nos compra una semana de runway.
Yjs + Hocuspocus está battle-tested, pero la persistencia con muchas sesiones simultáneas requiere snapshots inteligentes. Mitigación: load tests tempranos.
Pagar a tutores en MX desde una entidad USA tiene fricciones. Compliance, FX, retenciones. Necesitamos asesoría legal/contable temprano.
Sin tutores online no hay producto on-demand. Mitigación: enfoque inicial en scheduled hasta tener masa crítica de tutores.
Si Edmundo apaga la PC o se va el internet, MVP cae. Está bien para 20 usuarios privados, pero es un single point of failure.
% de estudiantes que completan primera sesión dentro de 7 días del signup. % de tutores que aceptan primera request en < 24h.
Tiempo medio de matching on-demand. % de requests on-demand que terminan en sesión vs caen al modo scheduled.
Rating promedio + % de sesiones con dispute. % de sesiones con whiteboard usado > 5 min (señal de engagement profundo).
GMV semanal, take rate efectivo (después de cancelaciones/refunds), CAC vs LTV de tutores y estudiantes.
No están asignados — son los "sombreros" que alguien tiene que ponerse para que el proyecto funcione. Una persona puede tener varios.
La propuesta: que los 5 de Arges trabajemos en decisiones estratégicas y dirección de producto, mientras Claude Code ejecuta implementación en paralelo con múltiples agentes coordinados.
Cada subagente trabaja en su propio worktree (rama temporal). N implementaciones simultáneas sin pisarse.
Explore = búsqueda rápida read-only. Plan = arquitecto. General = ejecutor full-stack.
/new-module, /new-endpoint, /add-stripe-flow, /scaffold-yjs-doc — capturamos repetición.
Pre-commit: lint + typecheck + tests. Post-edit: verificar boundaries de módulos.
Skill built-in que analiza el diff. Capturamos los hallazgos como comentarios en GitHub.
Para cambios grandes: bundle de revisores en paralelo. Lo invocan los humanos antes de mergear cosas críticas.
Babysit PRs, check dependency updates, alertar sobre tests rotos cada mañana.
Linear/GitHub/Slack como contexto vivo del agente. Lee tickets, comenta, transiciona estados.
Ejemplo: Carlos decide que vamos a construir el flujo de "cancelación con reembolso parcial". Esto es lo que pasa cuando lo lanzamos.
Carlos escribió 1 línea. Claude Code orquestó 5 agentes en paralelo
(plan + 3 implementadores en worktrees aislados + reviewer). Cada uno hizo su parte, hubo merge
automático cuando los diffs eran disjuntos, y la última palabra fue de Carlos aprobando el PR.
El equipo de Arges no está en el camino crítico de cada línea de código — está en las decisiones
importantes (qué construir, por qué, cómo se siente para el usuario, dónde está el negocio).
El repo tiene un CLAUDE.md con convenciones, comandos, boundaries. Es la "memoria del equipo" para todos los agentes.
Agentes que rompen tests no merguean. Pre-commit hook lo asegura. Sin esto, los agentes alucinan refactors.
Cualquier tarea no trivial pasa por un Plan agent y un humano aprueba antes de que el ejecutor escriba código.
Pagos, auth, schema de DB, RLS policies: review humano obligatorio. Lo demás, review humano probable.
Cada agente vive en su worktree. Si su PR no merguea, se descarta sin afectar a nadie más.
ADRs (Architecture Decision Records) en /docs/adr/. Cuando un agente decide algo no trivial, lo registra.
¿Cómo distribuimos internamente el 51%? ¿Vesting? ¿Dedicación esperada de cada uno?
¿Empezamos B2C (estudiantes directos) o B2B2C (cerrar 1-2 escuelas piloto primero)?
¿USA y MX en paralelo o secuencial? Implicaciones de pagos, idioma, soporte legal.
¿Quién es CTO? ¿Quién tiene la última palabra en arquitectura cuando no llegamos a consenso?
¿Comisión inicial? ¿15%? ¿20%? ¿Tarifa fija mínima por sesión? Benchmarks con Wyzant, Preply, etc.
¿Cómo manejamos KYC y compliance MX? ¿Asesor legal? ¿Contador? ¿Cuándo y quién lo busca?
// el siguiente commit es nuestro
Volvemos a estar en la mesa.
Esta vez hagámoslo bien.
Documento vivo. Comentarios, correcciones y desacuerdos son bienvenidos en la primera junta de Arges.