Iniciar con una fase de arquitectura y definición de un mes, que produce los requerimientos formales del sistema y el presupuesto en firme, seguida de un producto mínimo viable de cinco meses publicado en tienda de aplicaciones, concentrado en atraer usuarios en Bogotá y capturar la demanda real del mercado.

El mercado colombiano de motocicletas ha crecido de forma sostenida y acelerada, pero la relación entre el propietario y su vehículo sigue siendo enteramente informal. La motocicleta se compra, se usa intensamente y se vende sin que exista un registro de lo que se le hizo, cuándo se le hizo ni cuánto costó sostenerla. Esa ausencia de información no es un inconveniente menor: origina un ciclo que se repite en millones de vehículos y que destruye valor en cada vuelta.

El siguiente ejercicio corresponde a un repartidor con un recorrido mensual de 3.120 kilómetros sobre una motocicleta de 125 centímetros cúbicos, que es el segmento que concentra el 47 % del mercado colombiano. Todos los valores se calculan con precios públicos vigentes y el método de cálculo se declara en cada línea, para que el grupo promotor pueda verificarlo o ajustarlo.

Un domicilio de cinco kilómetros se remunera entre 2.500 y 3.100 pesos. A 247 pesos por kilómetro, ese domicilio consume cerca de 1.235 pesos en costos del vehículo, es decir entre el 40 % y el 49 % de lo que se le paga por él. El margen real de la operación depende por completo de un costo por kilómetro que el propietario no conoce, no mide y no controla, y que en el transcurso de un año asciende a cerca de 9.300.000 pesos. La plataforma propuesta convierte ese dato invisible en información disponible, y lo hace sin exigirle al usuario ningún conocimiento contable.

Construir y poner en operación la aplicación que establece la identidad digital de la motocicleta en Colombia, entregando desde la primera versión publicada un beneficio inmediato y gratuito al propietario, y estableciendo con ello los dos activos sobre los cuales la empresa desarrollará sus líneas de ingreso en las fases siguientes: una base de usuarios activos y un directorio propio de talleres y almacenes verificados.

La forma habitual de ejecutar un proyecto de esta naturaleza consiste en construir la totalidad del alcance en privado y publicar una sola vez, al cierre. Esa forma tiene dos defectos que este proyecto no puede permitirse: retrasa la captura de datos hasta el último mes, y somete diez meses de decisiones de producto a suposiciones que nadie verificó.

La estrategia propuesta es la contraria. Se construye primero el núcleo utilizable, es decir, el conjunto mínimo de funciones que ya le sirve a un motociclista por sí solo, se publica en la tienda de Android, y a partir de ese momento el producto se completa mediante actualizaciones planificadas mientras los usuarios ya están adentro.

Esta es la lista completa y verificable de lo que estará disponible en la tienda de Android en el mes 4, y en la tienda de Apple en el mes 5. No es una versión de prueba ni un adelanto: es un producto publicado, estable y utilizable de forma permanente.

Este es el activo nuevo más valioso que produce el Producto Mínimo Viable y merece explicación detallada, porque su construcción combina trabajo de ingeniería del proponente con trabajo de campo de la empresa.

La forma más rápida de construir un directorio de negocios sería extraer de forma automatizada la información de un servicio comercial de mapas. El proponente no lo recomienda y expone por qué, porque es una decisión que compromete jurídicamente a la empresa y no al desarrollador.

La ruta recomendada produce un directorio con menos datos al principio y más valor al final, porque cada registro pasa por una verificación humana de la empresa o por el registro voluntario del propio dueño. Ese es un dato que ningún competidor puede copiar de internet, precisamente porque no está en internet. La validación jurídica definitiva del origen de los datos y de sus condiciones de atribución se incorpora como entregable obligatorio de la Fase 0, con concepto del abogado de la empresa.

El aporte que se solicita a la empresa en este frente. La construcción automática del listado la ejecuta el proponente. La verificación telefónica no. Se propone que la empresa asigne esa tarea a su responsable comercial durante las semanas 28 a 32, con una meta de 300 establecimientos verificados antes del cierre del piloto. Es un trabajo de aproximadamente 25 a 30 horas repartidas en cinco semanas, no requiere conocimiento técnico alguno, y produce dos resultados a la vez: convierte un listado público en un activo propio y abre la relación comercial con los talleres que la empresa necesitará en la Fase 2.

Esta tabla existe para que no quede ninguna ambigüedad sobre qué se construye y qué no. La columna de descripción explica en lenguaje llano el alcance exacto de cada requerimiento, incluyendo lo que expresamente no hace.

Se declara de forma anticipada para que no exista diferencia entre lo esperado y lo entregado.

Se propone incorporar estos criterios al contrato, de modo que el éxito del proyecto se evalúe sobre indicadores acordados de antemano y no sobre percepciones. Gracias al lanzamiento anticipado, todos se miden con seis meses de operación real y no con dos semanas de piloto.

La mayor pérdida de usuarios en aplicaciones de este tipo ocurre en la pantalla de creación de cuenta. El diseño propuesto invierte el orden: el usuario recibe un beneficio concreto antes de que se le pida cualquier dato personal.

La meta de diseño es que el usuario obtenga su primera respuesta útil en menos de noventa segundos desde la apertura de la aplicación, con un solo dato ingresado. Esta función está disponible desde la versión 1.0 publicada en el mes 4.

Este es el recorrido que convierte a la aplicación en algo que el usuario usa y no solo consulta. El recordatorio no termina en un aviso: termina en un taller cercano, y el paso por el taller alimenta de vuelta al sistema.

El mecanismo de crecimiento que se propone. La red de talleres no se construye con una fuerza de ventas que visite establecimientos uno por uno, porque ese esfuerzo no es sostenible ni escalable en esta etapa. Se construye con el propio usuario como intermediario: el motociclista llega al taller diciendo que lo encontró en la aplicación, y la aplicación le facilita invitarlo. Para el dueño del taller, el argumento no es una promesa comercial sino un hecho verificable: un cliente acaba de llegar por ese canal.

El registro que se le ofrece es deliberadamente mínimo. No se le pide que adopte un sistema, que capacite a su personal ni que cambie su forma de trabajar. Se le pide que confirme su número de teléfono y complete su ficha en cinco minutos, desde el mismo celular con el que atiende. Todo lo demás que un taller podría hacer en la plataforma se construye después, cuando ya esté adentro y con clientes llegando.

El grupo promotor debe tomar una decisión técnica con consecuencias directas sobre el presupuesto y el calendario: si el producto se construye una vez para las dos tiendas, o dos veces, una para cada una. La respuesta, verificada contra la práctica actual del sector, es que existe una tecnología que permite escribir la aplicación una sola vez y publicarla en las dos tiendas, y que esa es la única alternativa razonable para un proyecto de esta escala.

Una sola base de código no significa una sola publicación simultánea. Significa que el 85 % o más del trabajo se hace una sola vez y que la segunda tienda cuesta un incremento y no una duplicación. El resto del trabajo es específico de cada tienda y no puede eliminarse.

La arquitectura se organiza en capas con dependencias exclusivamente hacia el interior. Es una estructura deliberadamente conservadora: en un producto de etapa inicial, la arquitectura correcta no es la más avanzada, sino la que admite el mayor número de correcciones al menor costo. Es también la que permite publicar en el mes 4 y seguir agregando módulos sin rehacer lo construido.

Esta sección responde a una pregunta que ninguna propuesta debería dejar sin responder: además de los honorarios del desarrollo, cuánto dinero tiene que poner la empresa cada mes para que el producto exista y funcione. Todos los valores provienen de listas de precios públicas de los proveedores, consultadas en agosto de 2026, y se convierten a pesos a una tasa de planeación de 3.100 pesos por dólar. Los valores en dólares se conservan en la tabla para que la empresa pueda recalcularlos con la tasa del día.

Todas las cuentas se abren a nombre de la empresa desde el primer día, sin excepción. El proponente trabaja con accesos delegados y revocables, nunca con cuentas propias que después haya que transferir. Esta no es una formalidad: es la diferencia entre un activo que la empresa controla y un activo que depende de la buena voluntad de un proveedor al momento de la separación. Si mañana el grupo promotor decidiera cambiar de desarrollador, no habría un solo trámite de transferencia que hacer.

Esta es la configuración propuesta para el primer año: un servidor pequeño que atiende hasta cerca de diez mil usuarios y que escala después sin rehacer nada. La lógica de dimensionamiento es deliberada: no se paga hoy por capacidad que el producto todavía no necesita.

El gasto no es constante: durante los tres primeros meses solo existen entornos de trabajo, y el costo real empieza cuando la aplicación se publica y entran usuarios.

Cerca de dos millones de pesos, o menos de un millón y medio aplicando los créditos de bienvenida del proveedor de nube. Eso es lo que cuesta sostener toda la infraestructura tecnológica del producto durante su primer año completo de vida, incluyendo su publicación en las dos tiendas. Se recomienda de todos modos provisionar tres millones de pesos para el primer año, no porque se espere gastarlos, sino porque una reserva sobre un rubro de este tamaño no compromete el presupuesto y elimina la necesidad de aprobar gastos imprevistos.

Existen proveedores que ofrecen la misma capacidad inicial por menos dinero. La diferencia en el primer año sería del orden de un millón de pesos. Aun así, la recomendación es Amazon Web Services desde el primer día, por cuatro razones.

Con una condición expresa: los principios de arquitectura de la sección 7.6 prohíben el amarre al proveedor. El producto se construye con un motor de base de datos estándar y sin usar funciones exclusivas de ningún proveedor. La consecuencia es que si la empresa decidiera migrar por razones de costo, la migración sería una tarea de infraestructura de unas 40 horas y no una reescritura del producto. Se recomienda la comodidad del proveedor grande, pero no se acepta quedar atrapado en él.

El costo de la infraestructura no crece con el número de usuarios registrados sino con seis variables concretas. Conocerlas permite anticipar el gasto en lugar de descubrirlo en la factura.

Las tres reglas de escalamiento que se comprometen en el contrato. Primera, se crece de forma vertical antes que horizontal. Duplicar el tamaño de una instancia es una operación de minutos y no exige cambios en el producto. Repartir la carga entre varias instancias exige trabajo de arquitectura. Se hace lo primero mientras alcance.

Segunda, no se anticipa capacidad. Cada aumento se dispara por un indicador medido, no por una previsión: procesamiento sostenido por encima del 70 %, memoria por encima del 80 %, o tiempo de respuesta de la búsqueda por encima de un segundo. Los tres quedan configurados como alarmas desde el día de la publicación.

Tercera, cada aumento se informa antes de ejecutarse. Ningún cambio de configuración que incremente el costo mensual se aplica sin aviso previo por escrito al grupo promotor. La empresa nunca recibe una factura que no haya autorizado.

En las semanas 5 y 6, antes de comprometer el grueso del presupuesto, se construye un prototipo funcional completo de una sola funcionalidad: el alta de una motocicleta por placa, con su plan de mantenimiento y su cálculo de próximo servicio, publicado y funcionando de extremo a extremo en las dos plataformas.

El cumplimiento del cronograma depende de estos insumos. Cada uno tiene una fecha límite y una consecuencia declarada si no llega a tiempo.

El proponente construye el producto; la marca la define la empresa. El nombre definitivo, el logotipo, la paleta de colores y las tipografías son decisiones de negocio que corresponden al grupo promotor, y pueden resolverse con un diseñador independiente o con una agencia, según lo prefiera.

Lo que sí se solicita de forma expresa es que esas definiciones estén cerradas antes de la semana 8. La razón es técnica y no estética: la interfaz del producto se construye sobre un sistema de estilos centralizado, y ese sistema se define una sola vez al comienzo. Recibir la marca a tiempo permite que el producto nazca alineado con ella. Recibirla en la semana 20 obligaría a revisar cada pantalla ya construida, con un costo estimado entre 25 y 40 horas que hoy no está en el presupuesto.

El proponente entrega el producto tecnológicamente sólido y visualmente consistente con la marca que reciba. La excelencia gráfica de esa marca es un resultado del trabajo de diseño que la empresa contrate, y por eso conviene que esa contratación se resuelva en las primeras semanas.

Los riesgos técnicos de este proyecto están bajo control; los riesgos que merecen atención son de negocio. Construir la aplicación es la parte previsible del plan, porque el alcance está cerrado, la arquitectura está definida y la capacidad está declarada con reserva. Lo que determina si el proyecto tiene éxito es que lleguen a tiempo los insumos de la sección 10.2, que la empresa ejecute la verificación del directorio y la captación de los primeros usuarios, y que el alcance no se expanda durante la ejecución. Por eso esta sección dedica más espacio a los riesgos del negocio que a los del software.

Esta sección se incluye para que el grupo promotor tenga visibilidad del recorrido completo. Ninguna de estas fases forma parte de la cotización de la sección 13, y cada una se cotizará por separado cuando llegue su momento, con la información que produzca el propio Producto Mínimo Viable.

El pago se estructura por hito verificado. Ningún desembolso se realiza contra tiempo transcurrido: todos se realizan contra un resultado comprobable.

Esta propuesta describe la construcción de un producto que se publica en la tienda de Android en el mes 4 y en la de Apple en el mes 5, y que sigue evolucionando durante seis meses con usuarios reales adentro. Está diseñada de forma deliberada para que la empresa no tenga que esperar diez meses para saber si su idea funciona.

El Producto Mínimo Viable está enfocado en el motociclista, con un alcance descrito requerimiento por requerimiento y con una declaración expresa de lo que no incluye. Ese enfoque no es una limitación de presupuesto: es la secuencia que permite que la Fase 2 tenga sobre qué construirse. Al terminar esta etapa, la empresa no tendrá solamente una aplicación publicada. Tendrá usuarios activos, un directorio propio de talleres y almacenes verificados, una red de establecimientos que se registraron por iniciativa propia y una medición real de lo que el mercado está pidiendo. Esos cuatro activos son el capital con el que se decide y se financia todo lo que venga después.

Las cifras de infraestructura, de precios de tienda y de costos de operación de esta propuesta provienen de listas de precios públicas vigentes y no de estimaciones. Las decisiones de tecnología se sustentan en evidencia y se someten a verificación en la semana 6, cuando todavía son reversibles. El origen de los datos del directorio se diseñó para que el activo resultante sea jurídicamente sólido y íntegramente de la empresa.