PROPUESTA DE PROYECTO · CNL-CSD02

Desarrollo de API Bidireccional para Tabster (Integración con Sistemas POS Externos)

PREPARED FOR

Victor Rivas

01

Resumen

Esta propuesta contempla el desarrollo de una capa de integración bidireccional para Tabster, construida sobre el backend y la lógica de negocio que ya existen y están validados en producción (Firestore, Cloud Functions, Stripe, roles de Restaurante/Mesero/Cliente).

‍

Esta capa tiene dos direcciones de trabajo:

‍

  1. API pública de Tabster (saliente): para que sistemas externos —como Soft Restaurant, Clover, Epos Now u otros POS/ERP de restaurantes— puedan conectarse a Tabster y adoptar su funcionalidad de pagos, división de cuenta, pedidos y facturación.
  2. Integraciones de Tabster hacia POS externos (entrante): para que Tabster pueda leer y sincronizar datos (menú, órdenes, estatus) directamente desde sistemas POS ya instalados en los restaurantes, normalizando la información de cada uno en un modelo de datos común.

‍

Con base en el análisis técnico de 8 POS relevantes en el mercado (Soft Restaurant, Epos Now, Oracle MICROS/Simphony, Corntech, Parrot, PoloTab, Clover y Wansoft), identificamos que no todos representan el mismo esfuerzo ni el mismo riesgo de tiempo: algunos ofrecen portales de desarrollador self-service, mientras que otros dependen de que el proveedor entregue credenciales, documentación o acceso a sandbox antes de poder estimar el desarrollo real. Esta propuesta está estructurada para avanzar con velocidad donde es posible, y sin comprometer plazos donde depende de terceros.

Objetivo

El objetivo del proyecto es evolucionar Tabster de ser únicamente una app propia a convertirse en una plataforma de intercambio de datos, capaz de:

‍

  • Exponerse hacia afuera: que otros sistemas se integren a Tabster mediante una API pública, documentada y segura.
  • Conectarse hacia adentro: que Tabster pueda sincronizarse con los sistemas POS que ya usan los restaurantes, sin obligarlos a migrar de sistema.

‍

Esto abre una nueva fuente de negocio (licenciar el acceso a Tabster a otros restaurantes o proveedores de software) y, al mismo tiempo, reduce la fricción de adopción para restaurantes que ya operan con un POS instalado.

‍

La solución debe ser:

‍

  • Agnóstica de lenguaje o sistema: consumible vía HTTP estándar (REST + JSON), sin depender de un SDK específico.
  • Segura y controlada por permisos: cada integrador con sus propias credenciales, scopes y límites de uso.
  • Escalable: capaz de soportar múltiples restaurantes e integradores concurrentes.
  • Sostenible: con documentación, versionado y monitoreo que permitan mantenerla sin romper integraciones existentes.
  • Realista frente a la dependencia de terceros: el plan de trabajo distingue explícitamente entre lo que depende de nuestro equipo y lo que depende de que un proveedor externo (ej. Soft Restaurant) entregue acceso.
02

From challenge
to clear direction.

01

Solución propuesta

Se desarrollará una capa de integración bidireccional sobre la infraestructura ya existente de Tabster (Firebase / Cloud Functions), dividida en dos frentes:

‍

A. API pública de Tabster (saliente)

‍

1. Diseño y arquitectura de la API

‍

  • Definición de recursos y endpoints (cuentas, pedidos, mesas, pagos, menú, facturación, usuarios/roles).
  • Especificación en formato OpenAPI/Swagger.
  • Versionado desde el día uno (/v1/...).

‍

2. Autenticación y control de acceso

‍

  • Emisión de API keys por integrador/restaurante, con scopes y permisos granulares.
  • Rate limiting por credencial y logging de cada request.

‍

3. Endpoints públicos sobre la lógica ya existente

‍

  • Adaptación de las funciones ya construidas (Rivio/functions, rivio-backend) a endpoints públicos y documentados: cuentas/mesas, pedidos, pagos vía Stripe, menú, facturación.

‍

4. Webhooks y eventos en tiempo real

‍

  • Notificación a sistemas externos ante nuevo pedido, pago confirmado, cuenta cerrada, etc.

‍

‍

B. Integraciones hacia POS externos (entrante)

‍

5. Capa de normalización / middleware

‍

  • Diseño de un modelo de datos común (menú, órdenes, pagos, estatus) al que se traduce la información proveniente de cualquier POS, ya que —como confirma el análisis técnico— cada uno modela sus entidades de forma distinta.
  • Esta capa es la que permite que, a futuro, agregar un nuevo POS no implique rediseñar Tabster, solo agregar un adaptador nuevo.

‍

6. Adaptadores para POS de acceso abierto (prioridad Fase 1)

‍

  • Implementación real de conexión con Clover, Epos Now y/o Parrot — los tres con portales de desarrollador self-service, autenticación estándar (OAuth / API key + bearer token) y baja dependencia del proveedor.
  • Se prioriza al menos uno como prueba de concepto funcional dentro del plazo de 3 semanas.

‍

7. Descubrimiento y gestión de acceso para POS de fricción media/alta

‍

  • Para Soft Restaurant, PoloTab, Wansoft, Oracle MICROS/Simphony y Corntech: inicio de contacto formal con cada proveedor, solicitud de documentación técnica, credenciales y ambiente de pruebas (sandbox).
  • Este punto no incluye el desarrollo de la integración completa con estos POS —solo la gestión de acceso y el mapeo inicial de las entidades disponibles—, ya que su tiempo real depende de la respuesta del proveedor externo y no puede comprometerse de forma fija.
  • Soft Restaurant en particular requiere solicitar llaves por correo al proveedor antes de poder iniciar pruebas end-to-end.

‍

‍

C. Portal, documentación y seguridad (aplica a ambas direcciones)

‍

8. Portal básico para integradores

‍

  • Alta y gestión de API keys, visualización de uso y acceso centralizado a documentación.

‍

9. Documentación técnica

‍

  • Especificación Swagger/OpenAPI navegable, colección de Postman y guía de integración paso a paso.

‍

10. Seguridad, validaciones y monitoreo

‍

  • Validación y sanitización de cada request. Monitoreo de uso anómalo. Pruebas de integración end-to-end con al menos un sistema piloto en cada dirección.
02

Por qué este enfoque

Tabster ya cuenta con una arquitectura de backend real y probada en producción, lo cual hace viable construir la dirección saliente (API pública) en un plazo corto: no se construye lógica de negocio nueva, se expone y asegura la que ya existe.

‍

La dirección entrante (conectarse a POS externos) es un tipo de trabajo distinto: aquí el esfuerzo no depende solo de nuestro equipo, sino de qué tan abierto es cada proveedor. El análisis técnico realizado sobre 8 POS relevantes confirma una diferencia real:

‍

  • Clover, Epos Now y Parrot muestran documentación pública para desarrolladores y un patrón reconocible de autenticación (API key/OAuth + bearer token), por lo que representan el camino más rápido para una integración real.
  • Soft Restaurant y PoloTab tienen portales o vías de acceso, pero no completamente self-service: requieren solicitar credenciales directamente al proveedor, lo que agrega fricción comercial además del trabajo técnico.
  • Oracle MICROS/Simphony, Corntech y, en menor medida, Wansoft deben tratarse como integraciones asistidas por el proveedor, donde primero hay que validar acceso, documentación y sandbox antes de poder estimar el esfuerzo de desarrollo real.

‍

Por esta razón, la propuesta no compromete un plazo fijo de desarrollo completo para los 8 POS. En su lugar, la Fase 1 (3 semanas) construye la arquitectura completa —API pública, middleware de normalización y al menos un adaptador funcional con un POS abierto— y arranca en paralelo el proceso de solicitud de acceso con los proveedores de fricción media/alta. La integración completa con Soft Restaurant (y el resto) se estima como Fase 2, una vez que el proveedor correspondiente entregue credenciales, documentación y sandbox.

‍

Esta estructura evita dos riesgos: prometer un plazo que no depende de nosotros, y detener todo el proyecto en espera de un solo proveedor.

03

Beneficios

Al desarrollar esta capa bidireccional, Víctor obtiene:

‍

  • Una nueva línea de negocio: licenciar el acceso a Tabster a otros restaurantes, cadenas o proveedores de POS.
  • Menor fricción de adopción: restaurantes que ya usan un POS (Clover, Soft Restaurant, etc.) pueden integrarse sin migrar de sistema.
  • Una sola fuente de verdad de datos: el middleware de normalización evita que cada POS "hable distinto" dentro de Tabster.
  • Escalabilidad real hacia nuevos POS: agregar un proveedor adicional a futuro implica solo un adaptador nuevo, no rediseñar el sistema.
  • Priorización basada en evidencia técnica, no en suposiciones: se ataca primero lo que es rápido de lograr (Clover, Epos Now, Parrot) mientras se gestiona en paralelo el acceso a los proveedores más lentos.
  • Protección contractual ante demoras de terceros: el cronograma distingue claramente lo que depende de nuestro equipo de lo que depende de un proveedor externo como Soft Restaurant.
  • Documentación profesional para que cualquier equipo técnico externo se integre sin depender de soporte manual constante.
04

Por qué Craft Next Labs

En Craft Next Labs, no solo creamos experiencias digitales, las diseñamos con propósito. Nuestro equipo cuenta con una profunda experiencia en diseño y desarrollo web, desarrollo móvil y estrategia digital, asegurando que cada proyecto esté diseñado para generar impacto.

‍

Vamos más allá de la estética, enfocándonos en funcionalidad, rendimiento y engagement del usuario. Desde el primer momento, nos comprometemos a ofrecer soluciones digitales innovadoras y de alto rendimiento que impulsen marcas, mejoren la experiencia del usuario y generen resultados reales.

‍

En Craft Next Labs ya conocemos Tabster de principio a fin: construimos su backend, su lógica de pagos, sus flujos de pedidos y su arquitectura en Firebase. No partimos de cero para entender el sistema — partimos de cero para exponerlo y conectarlo de forma segura y profesional, tanto hacia afuera como hacia los POS que ya usan los restaurantes.

‍

Además, evaluamos técnicamente cada uno de los 8 POS antes de cotizar, en lugar de asumir que todos se integran igual de rápido. Eso nos permite comprometer un plan de trabajo realista, en vez de una fecha genérica que probablemente no se cumpla en cuanto aparezca el primer proveedor lento.

03

Inversión

Desglose de inversión — Fase 1 (API bidireccional, 3 semanas):

‍

  • Diseño y arquitectura de la API pública (especificación OpenAPI, versionado, definición de recursos): - $18,000 MXN
  • Autenticación y control de acceso: API keys, scopes/permisos por integrador, rate limiting y logging. - $22,000 MXN
  • Adaptación de endpoints públicos sobre la lógica existente: Cuentas, mesas, pedidos, pagos (Stripe), menú y facturación. - $45,000 MXN
  • Webhooks y eventos en tiempo real (saliente): Notificaciones automáticas a sistemas externos. - $28,000 MXN
  • Capa de normalización / middleware (entrante): Modelo de datos común para menú, órdenes, pagos y estatus, independiente del POS de origen. - $30,000 MXN
  • Adaptador funcional con POS de acceso abierto (Clover, Epos Now o Parrot): Implementación real de al menos una integración entrante como prueba de concepto. - $35,000 MXN
  • Descubrimiento y gestión de acceso con POS de fricción media/alta (Soft Restaurant, PoloTab, Wansoft, Oracle MICROS, Corntech): Contacto con proveedores, solicitud de documentación/credenciales y mapeo inicial de entidades disponibles. No incluye desarrollo de integración completa. - $15,000 MXN
  • Portal básico para integradores: Alta de API keys, visualización de uso y documentación centralizada. - $20,000 MXN
  • Documentación técnica: Swagger/OpenAPI navegable, colección de Postman y guía de integración. - $10,000 MXN
  • Seguridad, validaciones y pruebas de integración end-to-end: - $15,000 MXN
  • Soporte: INCLUIDO POR 3 MESES - Corrección de errores y ajustes menores. Posterior a este periodo, $650 MXN por hora.

‍

Total estimado del proyecto (Fase 1): $238,000 MXN (NO INCLUYE IVA)

‍

Fase 2 (a cotizar por separado, sujeta a que los proveedores entreguen acceso):

  • Integración completa con Soft Restaurant una vez recibidas las llaves solicitadas.
  • Integración completa con PoloTab, Wansoft, Oracle MICROS/Simphony y Corntech, condicionada a la documentación, sandbox y acceso que cada proveedor confirme.
  • Hardening para alto volumen de integradores concurrentes (pruebas de carga, panel de administración avanzado, monitoreo con alertas).
PROJECT TOTAL
MXN
276080
Subtotal
238000
Tax rate
16

Costos adicionales

Este proyecto se apoya en la infraestructura ya existente de Tabster, pero exponerla y conectarla implica algunos costos externos no incluidos en el desarrollo:

‍

  • Mayor consumo de Firebase (Firestore reads/writes y Cloud Functions): al sumar tráfico de integradores externos y sincronización con POS. Estimado inicial: $10 – $40 USD/mes adicionales.
  • Herramienta de monitoreo/observabilidad (recomendada): para dar seguimiento a errores y uso anómalo. Estimado: $0 – $26 USD/mes.
  • Cuentas de desarrollador en plataformas de POS (si aplican): algunos proveedores (ej. Clover App Market) pueden requerir registro como desarrollador o partner; el costo varía por proveedor y se confirmará durante el descubrimiento técnico de cada uno.
  • Comisiones de Stripe: no cambian respecto a lo ya operado hoy.
  • Acuerdos comerciales con proveedores de POS o integradores (fuera de alcance técnico): cualquier convenio comercial, costo de partnership o licenciamiento exigido por Soft Restaurant, Oracle, Clover u otros proveedores para habilitar acceso corre por cuenta de Víctor/RIVIO.

‍

Nota: Los costos pueden variar dependiendo del volumen real de integradores, tráfico generado y de las condiciones comerciales que cada proveedor de POS exija para el acceso a su API.

04

Cronograma

Duración total estimada: 3 semanas (Fase 1)

‍

Fases del proyecto:

‍

  • Semana 1 – Arquitectura, autenticación y middleware: Especificación OpenAPI de la API pública. Sistema de API keys, scopes y rate limiting. Diseño del modelo de datos común (middleware de normalización) para integraciones entrantes. Inicio de contacto con proveedores de fricción media/alta (Soft Restaurant, PoloTab, Wansoft, Oracle MICROS, Corntech) para solicitar documentación y credenciales.
  • Semana 2 – Endpoints salientes y adaptador entrante: Adaptación de la lógica existente a endpoints públicos documentados (cuentas, pedidos, pagos, menú, facturación). Implementación de webhooks. Desarrollo del adaptador funcional con el primer POS de acceso abierto (Clover, Epos Now o Parrot).
  • Semana 3 – Documentación, seguridad y piloto: Documentación técnica completa (Swagger + Postman + guía de integración). Validaciones de seguridad y pruebas de integración end-to-end en ambas direcciones. Reporte de estatus de acceso con cada proveedor de fricción media/alta, como insumo para cotizar la Fase 2.

‍

Los tiempos pueden variar ligeramente dependiendo de la complejidad final de los endpoints solicitados. El desarrollo de integraciones completas con proveedores de fricción media/alta (Soft Restaurant, PoloTab, Wansoft, Oracle MICROS, Corntech) depende de que dichos proveedores entreguen documentación, credenciales y sandbox, y por lo tanto no forma parte del compromiso de tiempo de esta Fase 1.

05

Términos y condiciones

  • Las tarifas listadas corresponden exclusivamente al desarrollo descrito en la Fase 1 de esta propuesta. La integración completa con POS de fricción media/alta y el hardening de Fase 2 se considerarán fuera de alcance y se cotizarán por separado.
  • Para iniciar el proyecto, se requiere un anticipo del 50% del costo total.
  • El 50% restante se deberá cubrir al momento de la entrega y validación del piloto de integración.
  • El proyecto incluye soporte sin costo durante 3 meses posteriores a la entrega. Cualquier ajuste fuera de este periodo tendrá un costo de $650 MXN por hora.
  • Demoras causadas por proveedores externos de POS (falta de respuesta, credenciales no entregadas, documentación incompleta o negativa de acceso) no son responsabilidad de Craft Next Labs y no afectan el cumplimiento del plazo comprometido en la Fase 1; dichos puntos se retoman en la Fase 2 en cuanto el proveedor correspondiente habilite el acceso.
  • Los costos de infraestructura adicional (mayor consumo de Firebase, herramientas de monitoreo, cuentas de desarrollador de terceros) no están incluidos en el precio del desarrollo y deberán ser cubiertos directamente por el cliente.
  • Cualquier acuerdo comercial o de licenciamiento con proveedores de POS o integradores externos es responsabilidad exclusiva de Víctor/RIVIO y queda fuera del alcance técnico de esta propuesta.
  • Cualquier cambio significativo en el alcance de endpoints, lógica de negocio o número de integradores contemplados podrá cotizarse por separado.
  • En caso de cancelación del proyecto una vez iniciado el desarrollo, el cliente deberá cubrir los costos correspondientes al trabajo realizado hasta la fecha.
READY WHEN YOU ARE

¿Construimos lo que sigue?

Si tienes preguntas o quieres ajustar algún punto de esta propuesta, conversemos antes de avanzar.

Hablemos de la propuesta
↗