Qué mueve de verdad el coste de una app de Shopify
Sin horquilla de precio, porque quien la da sin ver tu tienda está adivinando. Las siete variables que mueven la cifra y cómo pedir un presupuesto comparable.
Guía9 de agosto de 20265 min de lectura
Este artículo no trae una horquilla de precio. Es a propósito, y es lo más útil que hay en él.
Las horquillas que se publican para «desarrollo de apps de Shopify» salen de una muestra de proyectos que no tienen nada que ver entre sí, y el número que te llevas se convierte en un ancla contra la que luego negocias, casi siempre mal, porque todavía no puedes saber en qué extremo del rango cae lo tuyo. Lo que sí conviene saber es qué mueve la cifra, para que cuando te llegue un presupuesto real sepas leerlo.
Las variables, más o menos por impacto
1. La distribución
El factor más grande con diferencia, y se decide antes de hablar de ninguna función. Una app custom se instala en una tienda y puede dar por hechos su catálogo, sus reglas de fulfillment, su calidad de datos. Una app pública tiene que funcionar en toda tienda que la instale: cada supuesto se vuelve un ajuste, cada caso límite hay que atenderlo en general, y hay un ciclo de revisión entre tú y cada publicación.
Casi todo el coste del software es generalidad. La distribución pública compra generalidad y se paga en alcance, no en horas por función. Escribimos aparte cómo elegir entre las dos.
2. Con cuántos sistemas tiene que hablar
Una app que solo lee y escribe en Shopify es un problema acotado. Una que además tiene que hablar con un ERP, un 3PL y un sistema contable son cuatro integraciones, y las de terceros son donde se va el calendario: su documentación es peor, sus entornos de prueba son peores y sus modos de fallo los absorbes tú.
La pregunta que aquí predice el coste no es cuántos sistemas, sino quién es dueño de cada uno. Una API que controlas se porta bien. Una API que controla el proveedor de un cliente, con una ventana de cambios que no ves, no.
3. Si guarda estado
Una app que lee Shopify, calcula algo y escribe de vuelta es bastante más barata que una que lleva sus propios registros. En cuanto guardas datos asumes migraciones, copias de seguridad, una postura de privacidad y unos webhooks obligatorios de cumplimiento que tienen que borrar de verdad, no devolver un 200.
4. Qué tiene que ser visible
Una interfaz embebida en el admin es un proyecto de front-end de verdad, con las convenciones de diseño de Shopify que seguir. Un proceso programado con una página de log no lo es. Una parte sorprendente de lo que se plantea como «una app» necesita lo segundo y se presupuesta como lo primero, porque el brief decía app.
5. Tiempo real o programado
«Cuando entre un pedido» y «cada noche» son sistemas distintos. El trabajo por webhook necesita idempotencia, manejo de reintentos y una forma de ponerse al día tras una caída, porque los webhooks pueden llegar dos veces, desordenados o no llegar. El programado puede ser más simple y muchas veces basta. Conviene decidirlo explícitamente y no heredarlo de una frase del brief.
6. Cuánta de la lógica se conoce de verdad
Donde las reglas ya existen —en una hoja, en un documento, en un proceso que funciona— la implementación es todo el trabajo. Donde hay que descubrirlas entrevistando a gente que no se pone de acuerdo, el descubrimiento es el trabajo y la implementación es la parte fácil. La segunda no es más cara por hora: es menos predecible, que es justo lo que un precio cerrado tiene que valorar.
7. La parte que casi nadie presupuesta
Shopify publica una versión nueva de la API cada trimestre y da soporte a cada una durante un año. Una app que nadie mantiene no falla poco a poco: funciona, se retira una versión y deja de funcionar. Súmale la rotación de tokens, los cambios de scopes cuando la app crece y las actualizaciones de dependencias.
Cueste lo que cueste construirla, la pregunta honesta es quién se hace responsable dentro de dieciocho meses. Presupuestar la construcción y no el mantenimiento es la forma más común de que una app salga cara.
Desliza la figura para verla completa
Qué especificar antes de pedirle un número a nadie
Los presupuestos se vuelven comparables cuando el brief es específico en esto, y vagos cuando no:
La distribución. Una tienda, o la App Store.
Los sistemas. Con nombre, con quién es dueño de cada uno y si sus APIs están documentadas.
El disparador. Tiempo real ante un evento, o programado.
Los datos. Qué guarda la app y durante cuánto tiempo.
La superficie. Interfaz embebida, o un proceso con página de estado.
La regla que no puede romperse nunca. Todo proyecto tiene una: no sobrevender, no exponer precios mayoristas al retail, no cobrar dos veces. Dila, porque determina cuántas pruebas se justifican.
Quién la mantiene después. Tu equipo, o quien la construyó.
Cómo leer el presupuesto que te devuelvan
Un presupuesto que merece comparación tiene un alcance que reconoces, una lista explícita de lo excluido, un acuerdo de mantenimiento con nombre y una frase sobre quién posee el código y la cuenta de Shopify Partner donde vive.
Un presupuesto que es solo un número y una duración no es más barato. Es solo menos específico sobre qué pasa cuando el alcance resulte ser mayor, y esa conversación llega siempre.
Si tienes las siete respuestas de arriba, buena parte de la estimación ya está escrita. Mándanoslas y recibirás un alcance en vez de un rango; y si la respuesta honesta es que no necesitas una app, preferimos decirlo en ese momento y no después.