Empezamos al revés que un SaaS
Quiero arrancar por la decisión que ordena todas las demás: B2BOX no es una empresa de software, es una operadora cross-border que escribe su propio software. Suena a matiz, pero cambia todo. Un SaaS optimiza para vender licencias y crecer en MRR; nosotros optimizamos para mover contenedores entre China y LATAM con menos errores y menos coordinación humana. El software es medio, no producto.
Podríamos empaquetar lo que tenemos —cotizador, tracking, calculadora de costo país— y venderlo afuera. Lo pensamos. Decidimos que no. El día que la prioridad del equipo dev pase de "que Miranda en Yiwu cierre una cotización 40% más rápido" a "que un cliente externo no encuentre un bug en producción", dejamos de ser buenos en lo que somos buenos. Esa decisión la tomé después de vender Pluxer en 2023, cuando vi de cerca lo que pasa cuando una empresa industrial pretende también ser empresa de software: termina haciendo las dos cosas a medias.
Si querés el detalle de cómo armamos el equipo alrededor de esta idea, lo conté en cómo está organizado el equipo de B2BOX.
Las cuatro capas del stack
Para que se entienda qué hay realmente atrás, lo separo en cuatro capas. Cada una resuelve un problema distinto y la decisión técnica la tomamos por separado.
| Capa | Decisión | Alternativa descartada | Por qué |
|---|---|---|---|
| Catálogo y sourcing | Supabase + scrapers en Python + LLMs para normalizar | Comprar dataset de 1688 / Alibaba | Los datasets que se venden están desactualizados y no matchean MOQ real de fábrica |
| Operación cliente (cotización + tracking) | Next.js + Postgres + Edge Functions | Salesforce + Zendesk | Over-engineering brutal para 19 personas, y el costo mensual no cierra contra el ahorro real |
| Sitio público b2box.pro | HTML estático servido desde Vercel CDN | Next.js con SSR | El sitio público se lee, no se opera. Cache de CDN gana en TTFB y SEO |
| Chat operativo China-LATAM | WhatsApp Business API + bridge custom hacia WeChat | Slack o Microsoft Teams | El equipo de Yiwu ya vive en WeChat. Forzar Slack es romper la herramienta de quien hace el trabajo real |
(i) Catálogo y sourcing
Acá necesitábamos una base de datos viva que se nutra de scraping de marketplaces chinos, fotos de Miranda en Yiwu y referencias de fábricas con las que ya operamos. Supabase nos da Postgres administrado, auth y storage en el mismo lugar; Python hace el scraping; los LLMs nos resuelven la parte más cara, que es normalizar descripciones (HS code probable, material, dimensiones, MOQ). De cómo pensamos esta capa hablé en el post de IA en sourcing — el roadmap.
(ii) Operación cliente
Next.js + Postgres + Edge Functions. Punto. No es elegante decirlo así, pero es lo que hay. Lo importante no es el stack, es lo que ese stack permite: un cotizador donde Hans o Rodrigo cargan un brief y el sistema arma el costo país completo —FOB + flete + aduana + última milla— sin que nadie tenga que abrir un Excel. Cada cotización guardada queda como dato para entrenar la próxima.
(iii) Sitio público
Esto es lo que estás leyendo ahora. HTML estático plano, servido por Vercel. Sin Next.js, sin React. Pesa poco, levanta en 200 ms desde Buenos Aires y desde Lima. Cuando el sitio público no necesita estado de usuario, meter SSR es pagar complejidad por nada. Es la decisión más vieja del libro y la sigo defendiendo.
(iv) Chat operativo
WhatsApp Business API hacia el lado LATAM, WeChat hacia el lado China, un bridge custom en el medio que sincroniza conversaciones por cliente. Esta capa la construimos porque no existe. Y la construimos chica, sin pretensiones de venderla.
Decisiones contra-corriente
Hay tres "no" que vale la pena explicitar porque me los preguntan seguido:
- No Salesforce. Para 19 personas, montar Salesforce es contratar consultora, integrador y un año de implementación. Lo que tenemos custom resuelve 90% por 5% del costo. El 10% restante lo absorbe el equipo, y está bien.
- No Slack. El equipo en China vive en WeChat y en WhatsApp. Si forzás Slack para que "el founder vea todo", terminás teniendo dos canales y ninguno con la conversación real. Decidimos que la herramienta sigue al equipo, no al revés.
- No AI agents end-to-end. Los LLMs nos sirven para tareas acotadas (clasificar productos, sugerir HS code, redactar borradores de respuesta al cliente). Pero un agente IA que cierra una compra de USD 50.000 sin humano en el medio es 100x más caro cuando se equivoca que un humano revisando. La matemática no cierra y no la vamos a forzar.
Qué construye el equipo dev y qué no
Hay una línea clara: el equipo dev construye software que reduce coordinación interna, no software para vender afuera. Ejemplo concreto: si Sergi pasa una semana automatizando el cálculo de aranceles por país, eso se traduce en que cada cotización tarda 8 minutos en vez de 40. Multiplicado por 300 cotizaciones mensuales, son 160 horas-persona liberadas. Esa métrica es la que perseguimos.
Lo que no hacemos: features para que un cliente externo se quede más tiempo en la app, gamificación, growth hacks, dashboards bonitos para impresionar inversores. No tenemos inversores y el cliente se queda porque le movemos contenedores bien, no porque la UI es linda.
Cómo medimos el ROI de la tecnología
Esto es donde más diferimos de un SaaS. Nuestras métricas no son MRR ni ARR ni churn. Son:
- Tiempo medio por cotización (objetivo: bajarlo trimestre contra trimestre).
- Tasa de errores en documentación de aduana (objetivo: tender a cero, cada error son días de demora y multa).
- Margen real por contenedor (la tecnología es buena si sostiene o mejora el margen sin agregar headcount).
- NPS de clientes recurrentes, pero medido a 6 meses, no a la semana del onboarding.
Si una herramienta nueva no mueve una de estas cuatro agujas, no la metemos. Es así de simple.
Qué viene en 2026
Tres cosas que estamos construyendo este año:
- Agente IA interno de pre-cotización. Recibe un brief por WhatsApp, lo clasifica, busca en el catálogo, propone fábricas candidatas y arma un primer costo país. El humano revisa y cierra. No reemplaza al sourcer; le saca la parte aburrida.
- Dashboard de tracking en tiempo real para el cliente. Hoy el cliente pregunta por WhatsApp "¿cómo va mi contenedor?". Queremos que abra una URL y vea estado, ubicación y próximo hito sin tener que escribirle a Rodrigo a las 11 de la noche.
- Integración contable. Conectar el cotizador con la herramienta contable separada para que cada operación cerrada genere automáticamente factura, asiento y conciliación.
Cierre
Nada de esto es magia ni es estado del arte. Es stack pragmático construido por gente que tiene presupuesto limitado y que prefiere mover contenedores bien antes que ganar premios de arquitectura. Si querés ver cómo se traduce esto en el día a día de un cliente, está descrito en cómo trabajamos; y si querés el contexto de por qué pienso así sobre construir vs comprar, lo cuento en mi historia —ingeniero electrónico de la UPC, máster en robótica en La Salle, EMBA en EAE, fundé Pluxer en 2019, la vendí en 2023, y aprendí ahí que el software es palanca, no producto, cuando tu negocio real está en otro lado.