Cuándo conviene una app de Shopify a medida

Casi todo el mundo llega a esta pregunta con la respuesta ya decidida, y normalmente por el lado equivocado. O una app del App Store se trata como gratis porque cuesta cuarenta dólares al mes, o construir se trata como la opción seria porque suena a ingeniería. Ninguna de las dos es una decisión. Decidir significa nombrar lo que cuesta de verdad cada una de las tres rutas y elegir la más barata que sobreviva los próximos dos años.

Hay tres rutas, no dos: instalar algo, configurar algo que ya tienes, o construir. La del medio es la que la gente se salta, y con frecuencia es la respuesta correcta.

Qué te compra de verdad una app del store

Una app instalada te compra una respuesta mantenida a un problema que no quieres poseer. Alguien más la mantiene funcionando cuando Shopify cambia una versión de API, absorbe la carga de soporte, y cubre los casos límite que todavía no se te ocurrieron. Para cualquier cosa que sea genuinamente un commodity — reseñas, respaldos, un widget básico de upsell, correo transaccional — es un trato excelente y construir es casi indefendible.

Lo que compras en realidad es el roadmap de alguien más. Está bien mientras tu requisito viva en medio de su roadmap y se quede ahí. Deja de estar bien en el momento exacto en que tu requisito se convierte en lo que ellos no van a construir, porque te importa a ti y a otros nueve comerciantes, y ellos tienen cuarenta mil.

Los costos que se olvidan no son la suscripción. Son el peso que la app le agrega al storefront cuando inyecta scripts, los datos de los que toma custodia, las ediciones de tema que deja al desinstalarse, y que cinco apps resolviendo cinco problemas vecinos terminarán contradiciéndose en el carrito. Diez apps a treinta dólares no son trescientos dólares al mes: son trescientos dólares al mes más todos los scripts que esas diez apps ponen en la página.

Dónde se acaba la configuración

Antes de construir, agota lo que la plataforma ya hace. Una proporción sorprendente de las peticiones de "necesitamos una app a medida" se resuelven con funciones nativas que nadie enumeró: definiciones de metafields y metaobjects para datos estructurados de producto, Shopify Flow para automatización del admin por eventos, reglas de combinación de descuentos, markets para precios y catálogos regionales, segmentos de clientes, bundles, selling plans, perfiles de envío.

La configuración se acaba de tres formas reconocibles, y conviene verlas venir.

La primera es expresividad. La regla que necesitas no se puede escribir con el vocabulario que ofrecen los ajustes. "Diez por ciento de descuento, pero no en tarjetas de regalo, y sin acumularse con el descuento de lealtad, y solo a partir de la segunda unidad" es una regla que la mayoría de los motores de promociones no puede enunciar, sin importar cuántas casillas tenga.

La segunda es ubicación. La lógica tiene que correr en un lugar al que ninguna app llega. El precio en checkout es el ejemplo más claro: ningún servicio externo puede recalcular un carrito desde afuera, y por eso ese trabajo pertenece a Shopify Functions y no a una integración con un webhook.

La tercera es propiedad del dato. En el momento en que la regla depende de un sistema que es tuyo — un ERP, un servicio de precios, una estructura de cuentas B2B, un almacén — ningún tercero puede codificarla, porque la mitad de las entradas viven detrás de tu firewall.

Qué cuesta de verdad ser dueño de una app

Aquí es donde se tuercen la mayoría de las decisiones de construir, porque la estimación cubre la funcionalidad y no la app. La funcionalidad quizá sean dos semanas. La app alrededor no es opcional y no es pequeña.

Auth y sesiones. Una app embebida tiene que manejar la instalación OAuth, guardar y refrescar tokens, verificar session tokens en cada petición, y comportarse bien cuando un comerciante reinstala, cambia de plan, o tiene dos cuentas de staff abiertas. Es un camino muy transitado, y sigue siendo trabajo real con consecuencias de seguridad si se hace a la ligera.

Webhooks. Los webhooks son la parte que decide en silencio si una app es confiable. Llegan fuera de orden. Llegan dos veces. No llegan y se reintentan después. Cada handler que escribas tiene que verificar su HMAC, ser idempotente, y responder rápido — o sea que el trabajo va a una cola y no dentro del handler. Una app cuyo webhook de pedidos procesa en línea es una app que va a perder un pedido la primera tarde ocupada.

Billing. Si la app le cobra a comerciantes y es pública, los cobros pasan por la Billing API de Shopify — recurrentes, por uso o únicos. Eso significa modelar planes, manejar altas y bajas a mitad de ciclo, y conciliar lo que Shopify dice que el comerciante tiene contra lo que cree tu base de datos.

Review. Una app pública se revisa antes de listarse, y los requisitos no son solo funcionales: OAuth correcto, los webhooks de compliance obligatorios, una política de privacidad, un flujo de soporte que funcione. La aprobación es decisión de Shopify, y nadie puede prometer la fecha.

Hosting y operación. La app es un servicio que ahora operas. Necesita dónde vivir, una base de datos, logs que puedas buscar, alertas cuando el procesamiento de webhooks se atore, y un plan para el día en que se deprecie una versión de API. Ese último es el costo recurrente que nadie presupuesta: una app no se termina, se mantiene.

Pública, custom o privada: tres facturas muy distintas

"Construir una app" son tres decisiones separadas usando un solo nombre, y el modelo de distribución cambia el costo más que la funcionalidad.

Una app custom o privada para una tienda

Distribuida a una sola tienda, sin listar, sin review. Nada de billing que construir, sin assets de listing, sin calendario de revisión, y una superficie de compliance mucho menor. Esto es lo que la mayoría de los comerciantes necesita de verdad cuando dice "app", y es la forma más barata de ser dueño de una lógica que es genuinamente tuya. Es la forma de casi todo el trabajo descrito en nuestra página de apps privadas.

Una app pública

Listada en el App Store, instalable por cualquiera, revisada, cobrada por Shopify. Ahora operas un producto con inquilinos — soporte, onboarding, versionado, y la certeza de que algún comerciante la usará de una forma para la que no la diseñaste. Construir esto porque un comerciante necesita una funcionalidad es el error más caro del terreno. Construirlo porque piensas venderlo es otro proyecto por completo, con otro plan.

Una Function que resulta necesitar una app alrededor

Las Functions se despliegan a través de una app, y eso confunde la pregunta. Si lo único que necesitas es un Cart Transform o una regla de descuento, la app es un vehículo de entrega, no un producto: casi nada de admin embebido, configuración en metafields, prácticamente nada que hospedar. La conversación de alcance debería separar esas dos cosas, porque "necesitamos una app" y "necesitamos una Function que viaja dentro de una app mínima" tienen precios radicalmente distintos.

Las señales que significan construir

En la práctica, estas son las que se sostienen:

• La lógica es el diferenciador. Si la regla es una razón por la que te eligen — cómo pones precios, cómo asignas stock, cómo controlas el acceso B2B — no debería vivir dentro del producto de otro.
• Se están cosiendo tres o más apps. Cuando el workaround es la app A exportando a una hoja que lee la app B, la integración ya es un sistema del que eres dueño sin ninguna de las ventajas de serlo.
• La regla tiene que correr dentro del checkout. No hay ruta de configuración para esto. O es una Function o no pasa.
• Tus propios datos son una entrada. Si la mitad de las entradas están en un ERP, un almacén o un servicio de precios, ninguna app instalada puede verlas.
• La suscripción superó al desarrollo. Una herramienta de seiscientos al mes que cubre el treinta por ciento de lo que necesitas es un desarrollo que se paga solo, y esa aritmética conviene hacerla en papel y no en una junta.
• Desinstalar sería una crisis. Si que un proveedor desaparezca detendría tu operación, ya dependes de eso como infraestructura y lo pagas como suscripción.

Y las señales que significan no construir: el requisito es común, el mercado de apps tiene tres respuestas maduras, el volumen es tan bajo que una persona haciéndolo a mano sale genuinamente más barato, o nadie ha escrito todavía la regla en prosa. Ese último no es broma: una regla que no puedes enunciar en un párrafo tampoco la puedes cotizar, y es el predictor más confiable de una app que tarda el triple de lo debido.

La pregunta debajo de la pregunta

"¿Deberíamos construir una app?" rara vez es la pregunta real. La real es si esta pieza de lógica es tuya — si querrías que sobreviviera a que un proveedor desaparezca, si codifica algo sobre cómo funciona tu negocio, si alguien más podría mantenerla sin que le expliques tu operación primero.

Si la respuesta es no, instala algo y sigue adelante. Si la respuesta es sí, poséela bien en vez de aproximarla entre cuatro suscripciones y una hoja de cálculo. Todo lo que hay en nuestra página de apps a medida parte de esa distinción, y la llamada de alcance suele dedicarle más tiempo a eso que a la lista de funcionalidades.