Volver a proyectos

Co-Founder & CTO · 2021 - acquired

Cantoo

Construí desde cero una plataforma telecom cloud (voz, SMS, DID). Rentable en menos de dos años con 400 k€/año, y adquirida por 42com.

cantoo.co

El problema

Los proveedores de servicios de comunicación querían vender voz, SMS y números con su propia marca, sin construir ni operar una infraestructura telecom.

Cantoo se lo ofrecía como servicios alojados en marca blanca, impulsados por API. La plataforma tenía que soportar tráfico de voz y mensajería a escala industrial con fiabilidad de grado operador, cumplir la regulación telecom de varios países, y todo ello sin capital riesgo.

Lo que construí

  • Diseñé y construí toda la pila técnica desde cero, empezando por una infraestructura de voz distribuida y cloud-native sobre Kubernetes, con auto-escalado y auto-recuperación.
  • Construí un motor de enrutamiento en tiempo real que elige rutas según coste, calidad y latencia, y que desprioriza a un operador en cuanto empieza a devolver errores.
  • Construí un pipeline de facturación en tiempo real sobre ClickHouse y Pulsar para seguir al instante el uso de voz, SMS y DID.
  • Construí los servicios en marca blanca impulsados por API (voz, SMS, DID) que los operadores integraban en sus propios productos, y llevé el registro de Cantoo como operador telecom en Reino Unido, Francia y Alemania.
  • Formé y dirigí un equipo de ingeniería remoto con guardias 24/7 y, tras la adquisición, lideré la integración técnica en 42com.
Cantoo architecture: service providers send traffic and API calls to the platform; a SIP edge (Kamailio) and an SMS gateway feed a real-time routing engine that picks carriers by cost, quality and latency; FreeSWITCH media servers handle calls; usage events flow through Pulsar into ClickHouse for real-time billing; everything runs on Kubernetes on GCP and AWS.Kubernetes on GCP and AWSService providerswhite-label customersSIP edgeKamailioSMS gatewaymessagingRouting enginecost · quality · latencyMedia serversFreeSWITCHAPI & portalprovisioningPulsarusage eventsClickHousereal-time billingCarriersUK · FR · DE operator
Arquitectura simplificada de la plataforma Cantoo

Decisiones y concesiones

  • Enrutamiento multicriterio en lugar de la ruta más barata

    Por qué: los márgenes eran ajustados y una caída de calidad o latencia podía hacer perder a un operador para siempre

    Coste: se convirtió en el componente del que dependía todo lo demás, así que un error habría obligado a reescribirlo todo.

  • PostgreSQL para todo al principio, ClickHouse para analytics solo cuando los tiempos de consulta empezaron a doler

    Por qué: sin una segunda base de datos que operar demasiado pronto

    Coste: funcionó porque el modelo de datos ya preveía esa separación, y la migración llevó semanas, no meses.

  • Kubernetes desde el principio

    Por qué: por la fiabilidad de grado operador que vendría después

    Coste: durante los primeros seis meses costó semanas de configuración que un equipo de dos personas aún no necesitaba; unas cuantas VM habrían bastado.

Resultado

Cantoo fue rentable en menos de dos años y alcanzó 400 k€/año de ingresos sin ninguna ronda de financiación. Operaba como operador telecom registrado en Reino Unido, Francia y Alemania. A finales de 2023 fue adquirida por 42com, proveedor de servicios telecom mayoristas y, como los sistemas eran modulares y estaban documentados, la integración llevó meses, no años.

Stack

Kubernetes · Go · TypeScript · Vue/Nuxt · Kamailio · FreeSWITCH · PostgreSQL · ClickHouse · Redis · Pulsar · Terraform · GCP/AWS · GitLab CI

Conclusión

Cantoo demostró que no se necesita capital riesgo para construir algo real. Las restricciones nos obligaron a enfocarnos: entregamos más rápido, gastamos menos y alcanzamos la rentabilidad diciendo no a las funcionalidades que no generaban ingresos directamente.