Cómo crear una app móvil que registre una métrica por día

Define el objetivo: una métrica, una vez al día

Una app de “una métrica por día” hace exactamente una cosa: pide al usuario que registre un solo número (o un valor sencillo) una vez por día calendario. Sin formularios largos, sin listas de comprobación extensas, sin múltiples pestañas de datos. El objetivo es hacer que el registro diario se sienta tan sencillo como marcar una casilla.

Por qué una métrica reduce la fricción

La mayoría de las apps de seguimiento fallan por una razón aburrida: piden demasiado, con demasiada frecuencia. Cuando los usuarios tienen que recordar múltiples entradas, interpretar etiquetas o decidir qué “cuenta”, se saltan un día—y luego dejan de usarla.

Limitar la app a una métrica baja la carga mental:

• Una decisión (“¿Cuál es el número de hoy?”)
• Una acción (ingresarlo)
• Un momento (listo)

Esa simplicidad facilita mantener el hábito cuando la vida se complica—que es precisamente cuando el seguimiento suele ser más valioso.

Qué cuenta como “métrica”

Una métrica debe capturarse rápido y ser fácil de comparar con el tiempo. Buenos ejemplos incluyen:

• Estado de ánimo (1–10)
• Peso
• Pasos
• Ingesta de agua (vasos o litros)
• Horas de sueño
• Nivel de dolor (0–10)

La clave es que el usuario entienda la escala sin releer instrucciones cada día. Si tiene que pensar mucho qué número introducir, la app ya está perdiendo.

A quién ayuda (y por qué)

Este tipo de app es ideal para personas que desean un auto-chequeo ligero: crecimiento personal, rutinas de salud, experimentos de productividad o simplemente notar patrones. Funciona especialmente bien cuando los usuarios no necesitan precisión—necesitan consistencia.

Establece expectativas con claridad

Sé explícito sobre qué es y qué no es la app. Esto es un registro personal, no una herramienta de diagnóstico. Si rastreas cosas como dolor, estado de ánimo o sueño, evita afirmaciones médicas y presenta los datos como “tus notas a lo largo del tiempo”, no como consejo médico.

Elige las reglas de la métrica y los límites diarios

Una app de una métrica se mantiene simple solo si la métrica es inequívoca. Antes de diseñar pantallas o bases de datos, escribe las reglas en lenguaje llano para que los usuarios siempre sepan qué ingresar y cuándo.

Escoge la métrica y su unidad

Empieza eligiendo una sola cosa que la gente pueda medir de forma consistente. Luego escoge la unidad que coincida con cómo piensa la gente naturalmente:

• Número (p. ej., pasos, vasos de agua, minutos)
• Escala (p. ej., ánimo 1–5, dolor 0–10)
• Sí/No (p. ej., “¿Medité hoy?”)

Escribe la etiqueta exactamente como aparecerá en la app, incluyendo la unidad. Por ejemplo: “Sueño (horas)” es más claro que “Sueño”.

Establece rango y reglas de validación

La validación evita datos desordenados y reduce la frustración del usuario más adelante.

Para una métrica numérica, define:

• Mínimo y máximo (p. ej., 0–10)
• Si decimales están permitidos (7 vs 7.5)
• Qué ocurre con una entrada inválida (mensaje de error vs autocorrección)

Para una escala, define qué significa cada extremo (“0 = nada, 10 = lo peor imaginable”) para que los usuarios mantengan consistencia entre días.

Para sí/no, decide si “sin entrada” debe tratarse como “no” o como “desconocido”. Normalmente es mejor mantener “no registrado” distinto de “no”.

Define qué significa “un día”

Los usuarios esperan que la app siga su día local. Usa la zona horaria del usuario para agrupar entradas y establece un corte claro (típicamente la medianoche local).

También decide cómo manejarás los viajes. Un enfoque simple: cada día se basa en la zona horaria en el momento de la entrada, y los días pasados no cambian después.

Decide las reglas de rellenado (backfilling)

El backfilling puede ayudar a la honestidad y a la continuidad, pero ediciones ilimitadas pueden minar la confianza en las tendencias.

Elige una política y dilo claramente:

• Permitir rellenar por X días (común: 3–7)
• Permitir editar hoy y ayer solamente
• Permitir en cualquier momento, pero mostrar un indicador de “ingresado tarde”

Estas reglas hacen tus datos confiables y mantienen la promesa de “una vez al día”.

Define el alcance del MVP y criterios de éxito

Una app de una métrica gana por ser rápida y predecible. El MVP debe sentirse “terminado” porque hace un conjunto pequeño de cosas extremadamente bien—y rechaza todo lo demás.

Pantallas principales (limítalas a cuatro)

Hoy (Entrada): la pantalla principal donde el usuario registra el valor de hoy. Debe quedar claro qué significa “hoy” y si ya existe una entrada.

Historial (Calendario o lista): una vista simple de días recientes para escaneo rápido y la posibilidad de tocar un día para editar.

Tendencias: un gráfico básico que responda “¿cómo voy últimamente?” sin opciones extra.

Ajustes: los controles mínimos: nombre/unidades de la métrica, límite diario (si se necesita), recordatorios, exportar y aspectos básicos de privacidad.

Checklist de funciones para el MVP (estricto)

Para el primer lanzamiento, limita la funcionalidad a:

• Añadir/editar una entrada por día (incluyendo cambiar un día pasado)
• Ver los últimos 30 días en Historial
• Un gráfico básico (p. ej., línea de los últimos 30 días o promedio semanal)

Todo lo demás distrae al principio.

Diferir las “agradables de tener” tentadoras

Estas características suelen añadir complejidad a la UI, al modelo de datos y al soporte:

• Etiquetas o categorías
• Notas o diario extenso
• Métricas múltiples
• Compartir social, amigos, tablas de clasificación
• Gráficos avanzados, filtros, objetivos, gamificación de rachas

Si dudas sobre una función, probablemente no sea MVP.

Define criterios de éxito que puedas probar

Escribe algunos objetivos medibles para saber si el MVP funciona:

• Velocidad: registrar la entrada de hoy en menos de 10 segundos desde abrir la app
• Claridad: los usuarios pueden entender si ya registraron hoy sin buscar
• Confiabilidad: las entradas se guardan offline y nunca “desaparecen” tras reiniciar la app
• Engagement: un usuario puede encontrar y editar un día pasado en menos de 15 segundos

Estos criterios mantienen las decisiones centradas: cada idea nueva debe proteger velocidad, claridad y confianza.

Diseña una UI de entrada diaria simple y rápida

La pantalla “Hoy” es tu app. Si tarda más de unos segundos, la gente se lo salta. Apunta a una mirada, una acción, listo.

Haz la entrada verdaderamente con un toque

Elige un control que coincida con la forma de la métrica:

• Botones para conjuntos pequeños (p. ej., “Bajo / Medio / Alto”)
• Stepper (+/–) para conteos (p. ej., vasos de agua), con un máximo sensato
• Slider para rangos (p. ej., ánimo 1–10), idealmente con puntos de ajuste

El control elegido debe guardar con un solo toque. Evita pantallas de “Confirmar” salvo que la métrica sea irreversible (normalmente no lo es). Muestra retroalimentación inmediata como “Guardado para hoy” y el valor registrado.

Usa etiquetas y microcopy que quiten la duda

La gente no debe preguntarse qué significa “7”:

• Usa una etiqueta clara: “Pasos hoy” o “Nivel de dolor (0–10)”
• Añade una línea de ayuda corta: “Introduce tu mejor estimación—no se busca perfección.”
• Si el momento importa, dilo: “Registra cómo te sentiste en el día.”

Mantén el lenguaje consistente: la misma unidad, la misma escala, la misma redacción.

Fundamentos de accesibilidad que ayudan a todos

Usa objetivos táctiles grandes (aptos para el pulgar), alto contraste y tipografía legible. Soporta el tamaño de texto del sistema. Asegura que los controles tengan nombres significativos para lectores de pantalla (p. ej., “Aumentar valor” en lugar de “Botón”). No dependas solo del color para transmitir significado.

Notas: opcional, sin entorpecer

Un campo de notas puede añadir contexto (“dormí mal”, “día de viaje”), pero también puede ralentizar el registro. Mantenlo opcional y colapsado por defecto (“Añadir nota”). Considera una opción en ajustes para desactivar notas por completo para quien quiera máxima velocidad.

Planea el Historial y las Tendencias sin sobrecargar a los usuarios

Una app de una métrica solo se siente “simple” si la pantalla de historial se mantiene calma. El objetivo es responder dos preguntas rápidamente: “¿Qué pasó?” y “¿Está cambiando?”—sin convertir la app en un panel de control.

Elige una vista principal de historial

Escoge una vista por defecto y haz lo demás secundario:

• Cuadrícula de calendario funciona bien cuando la métrica es realmente diaria y los usuarios piensan por semanas. Hace las lagunas obvias y permite escaneo rápido.
• Lista por fecha es mejor cuando las entradas necesitan contexto (notas, etiquetas) o cuando los usuarios suelen desplazarse hacia atrás.

Si ofreces ambas, no las presentes como pestañas iguales en el día uno. Comienza con una y esconde la alternativa detrás de un toggle simple.

Haz visibles los días faltantes (y honestos)

Decide de antemano cómo representar “sin entrada”. Trátalo como vacío, no cero, salvo que cero sea un valor significativo elegido por el usuario.

En la UI:

• Usa una celda vacía (calendario) o un valor “—” (lista)
• Diferencia visualmente el vacío del cero con espaciado o estilo más claro
• Permite añadir una entrada desde cualquier día pasado (dentro de tus reglas) para reparar huecos

Añade rachas con cuidado (o mantenlas opcionales)

Las rachas pueden motivar, pero también castigan. Si las incluyes:

• Mantén la redacción neutral (“días consecutivos registrados”)
• Que las rupturas sean informativas, no alarmantes
• Considera una tarjeta de racha desactivada por defecto, o muéstrala solo después de unos días de uso

Proporciona una vista de tendencias ligera

Las tendencias deben ser un resumen rápido, no una herramienta de graficado. Un enfoque práctico es mostrar promedios de 7/30/90 días (o sumas, según la métrica) con una frase corta como: “Últimos 7 días: 8.2 (sube desde 7.5).”

Evita múltiples tipos de gráficos. Un pequeño sparkline o una tira de barras es suficiente—especialmente si carga al instante y es legible de un vistazo.

Elige stack tecnológico y modelo de datos

Este tipo de app triunfa cuando se siente instantánea. Tus elecciones técnicas deben optimizar un rastreador diario simple que cargue rápido, funcione offline y sea fácil de mantener como MVP móvil.

Enfoque de plataforma: nativo vs cross-platform

Si quieres máxima integración con el SO (widgets, recordatorios del sistema, mejor rendimiento de scroll), ve nativo: Swift (iOS) y Kotlin (Android). Entregarás la experiencia más “en casa”, pero mantendrás dos bases de código.

Si la velocidad de entrega importa más, un framework multiplataforma suele ser suficiente para una app de hábitos:

• Flutter: UI consistente, buen rendimiento, excelente para UI personalizada
• React Native: iteración rápida, gran ecosistema, fácil contratación

Ambos enfoques funcionan bien para un flujo de una-pantalla-por-día.

Si quieres mover aún más rápido de idea a MVP funcional, una plataforma de creación vía chat como Koder.ai puede ayudarte a generar una app web React, un backend Go + PostgreSQL o un cliente móvil Flutter desde una simple conversación—y luego exportar el código cuando quieras poseerlo y ampliarlo.

Modelo de datos: mantenlo simple

Modela tu registro principal como una sola entrada diaria:

• Entry { date, value, createdAt, updatedAt, note? }

Usa una date canónica que represente el “día” del usuario (almacena como fecha ISO tipo YYYY-MM-DD), separada de los timestamps. Esto mantiene la validación directa: una entrada por día, sobrescribir o editar según sea necesario.

Conceptos básicos de arquitectura

Al menos, planifica estas capas:

• Pantallas: Hoy (entrada), Historial (lista), Tendencias (visualización sencilla), Ajustes
• Gestión de estado: algo predecible (ViewModel, Bloc, estilo Redux, etc.)
• Capa de validación: hacer cumplir “una vez al día”, rangos numéricos y límites opcionales de notas

Necesidades de terceros (lo mínimo)

Elige dependencias pequeñas y bien mantenidas:

• Base de datos local para una app offline-first (SQLite, Room, Core Data o un wrapper ligero)
• Librería de gráficos para tendencias (línea/barra, interacciones básicas)
• Reporte de crashes para atrapar problemas en el mundo real rápidamente

Añade analítica más adelante solo si no complica el flujo central.

Almacena datos con fiabilidad (local-first) y permite exportar

Una app de una métrica por día funciona cuando nunca pierde entradas y nunca bloquea al usuario. Por eso el MVP debe ser local-first: la app funciona totalmente offline, guarda al instante y no requiere cuenta.

Empieza con almacenamiento solo local (MVP)

Elige una capa de base de datos probada en el dispositivo en lugar de intentar “guardar archivos”. Opciones comunes:

• SQLite (vía wrappers de plataforma) para máxima portabilidad y control
• Realm para un modelo de objetos simple y consultas fáciles
• Core Data (iOS) si quieres integración estrecha con el ecosistema Apple

Mantén el modelo de datos simple y durable: un registro con una clave de fecha, el valor de la métrica y metadatos ligeros (como “nota” o “createdAt”). La mayoría de problemas aparecen cuando no tratas la “fecha” con cuidado—almacena un identificador claro de día (ver sección de zona horaria) para que “una entrada por día” sea aplicable.

Offline por defecto (sincronización después)

Diseña la app para que cada entrada diaria confirme guardado sin conexión de red. Esto reduce fricción y elimina una categoría completa de fallos (caídas de login, downtime del servidor, mala cobertura).

Si añades sync más tarde, trátalo como una mejora, no como requisito:

• Mantén los datos locales como fuente de la verdad
• Usa una estrategia de conflicto que respete “un valor por día” (p. ej., gana la última edición, o pedir al usuario solo cuando sea necesario)

Da a los usuarios propiedad con exportación

Exportar genera confianza porque los usuarios saben que pueden irse con sus datos.

Ofrece al menos un formato simple:

• CSV para hojas de cálculo y análisis rápidos
• JSON para desarrolladores y estructura más detallada

Haz la exportación fácil de encontrar (Ajustes está bien) y que el archivo sea autoexplicativo: incluye el nombre de la métrica, la unidad (si la hay) y los pares fecha/valor.

Copias de seguridad sin forzar inicio de sesión

Para el MVP, confía en copias de seguridad de plataforma (backup de iCloud en iOS, backup de Google en Android) cuando corresponda.

Opcionalmente planea una “ruta de mejora”:

• Inicio de sesión opcional para habilitar restauración entre dispositivos
• Backup/restaurar explícito dentro de la app para usuarios avanzados

La clave es consistencia: los guardados locales deben ser inmediatos, las exportaciones fiables y las copias de seguridad una red de seguridad—no un obstáculo.

Añade recordatorios que los usuarios controlen

Los recordatorios pueden hacer que la app «pegue», pero también pueden ser la forma más rápida de ser desinstalada. El principio guía: los recordatorios deben sentirse como un empujón útil que el usuario controla, no como un sistema que acosa.

Deja que el usuario elija la hora (y lo desactive)

Comienza con una sola hora de recordatorio diaria en ajustes. Durante el onboarding, ofrece un valor por defecto sensato (por ejemplo, tarde temprano), y muestra inmediatamente un toggle claro para desactivar recordatorios por completo.

Controles simples:

• Selector de hora (hora local del dispositivo)
• Toggle “Recordatorio on/off”
• Opcional: “días tranquilos” más adelante (p. ej., fines de semana), pero no lo metas en el MVP

Redacta el texto de notificación de forma neutral

Copia corta y calmada reduce presión y culpa. Evita lenguaje de rachas y juicio.

Ejemplos:

• “Registra el número de hoy.”
• “Chequeo rápido: añade la entrada de hoy.”
• “¿Quieres registrar la métrica de hoy?”

Si la métrica tiene nombre, inclúyelo solo si es corto y no ambiguo.

Recordatorios perdidos: ofrece recuperar sin spam

Si el usuario no actúa, no sigas enviando notificaciones. Una por día es suficiente.

Dentro de la app, maneja los días perdidos con un aviso suave:

• “Aún no registraste hoy. ¿Lo registras ahora?”
• Si ayer también falta: “¿Quieres completar también ayer?”

Haz que “Ahora no” sea una opción de primera clase y no penalices al usuario con advertencias.

Opcional tras el MVP: superficies de entrada más rápidas

Cuando el bucle central esté estable, considera características de entrada rápida para reducir fricción:

• Widget en la pantalla de inicio que muestre “Hoy: vacío” con añadir en un toque
• Acciones rápidas (mantener presionado el icono) como “Registrar hoy”

Añádelas solo si acortan significativamente el camino a la entrada diaria.

Privacidad, seguridad y bases de confianza

La confianza es una característica. Una app de una métrica tiene la gran ventaja de poder diseñarse para recopilar casi nada—y explicarlo claramente.

Recopila solo lo necesario

Por defecto guarda solo el valor diario, la fecha y (si se necesita) la unidad. Evita recopilar lo que convierta un simple rastreador en perfilado personal: no listas de contactos, no ubicación precisa, no identificadores publicitarios y no preguntas demográficas “útiles”.

Si ofreces notas o etiquetas, trátalas como potencialmente sensibles. Hazlas opcionales, cortas y nunca obligatorias.

Sé explícito sobre dónde viven los datos

Explica el almacenamiento en lenguaje llano dentro de la app:

• En el dispositivo: el historial métrico se guarda localmente para que la app funcione offline.
• En la nube (si aplica): si añades sincronización después, hazla opt-in, explica qué se sube y ofrece forma de desactivar y eliminar datos en la nube.

Incluso sin nube, los usuarios deben saber si desinstalar borra todo y cómo funciona la exportación.

Seguridad básica acorde a la simplicidad

Protege contra cotilleos casuales:

• Bloqueo de app (agradable de tener): PIN opcional o biometría
• Privacidad en pantalla: considera ocultar valores sensibles en la vista de cambio de app
• Defaults seguros: no mostrar la métrica en notificaciones a menos que el usuario lo active

Haz la privacidad fácil de encontrar

Pon un elemento claro “Privacy Policy” en Ajustes etiquetado exactamente así e incluye la ruta de ejemplo como texto: /privacy. Acompáñalo de un resumen corto y legible: qué guardas, dónde y qué no recopilas.

Mide lo que importa: analítica para una app de una métrica

Una app de una métrica debe sentirse tranquila y enfocada—tu analítica debe ser igual. El objetivo no es rastrear todo; es confirmar que la gente puede añadir el valor de hoy rápido, seguir haciéndolo y confiar en la app con sus datos.

Define los pocos eventos que valen la pena

Empieza con un conjunto mínimo de eventos que mapeen el recorrido del usuario:

• Instalación / primera apertura (para entender adquisición vs activación)
• Primera entrada creada (el momento “aha”)
• Entrada diaria completada (la acción central)
• Exportación usada (señal de usuario avanzado y confianza)

Si añades recordatorios luego, registra recordatorio activado/desactivado como eventos de configuración (no como puntuación de comportamiento).

Retención y rachas sin recopilar valores crudos

Puedes aprender mucho sin guardar la métrica. Prefiere agregados y propiedades derivadas, como:

• Si se hizo una entrada hoy (sí/no)
• Longitud de racha en el momento de la entrada (p. ej., 0, 1–3, 4–7, 8–30, 31+)
• Días activos en los últimos 7/30

Esto permite entender curvas de retención y distribución de rachas evitando valores sensibles.

Analítica respetuosa con la privacidad por defecto

Usa herramientas que soporten:

• Opt-out (y opt-in cuando sea requerido)
• Identificadores mínimos (evitar listas de contactos, ubicación precisa o ID de publicidad)
• Controles claros de retención de datos

Métricas para juzgar mejoras

Vincula cambios de producto a un pequeño cuadro de mando:

• Time-to-entry (mediana de segundos desde abrir la app hasta guardar la entrada)
• Retención a 7 días (¿volvieron y completaron una entrada?)
• Tasa de completado por apertura (¿estás reduciendo fricción?)

Si un cambio no mejora alguna de estas, quizá sea complejidad disfrazada de progreso.

Prueba las partes complicadas: fechas, zonas horarias, casos límite

Una app de una métrica parece simple hasta que chocás con la realidad del calendario. La mayoría de los bugs “misteriosos” aparecen cuando un usuario viaja, cambia la hora del dispositivo o intenta ingresar el valor de ayer a las 00:01. Un plan de pruebas pequeño y enfocado te ahorrará semanas de soporte.

Construye un plan de pruebas compacto para el tiempo

Define qué significa “un día” en tu app (normalmente el día local del usuario) y prueba los límites explícitamente:

• Límites de fecha: 11:59 p.m. vs 12:00 a.m.; ingresar justo antes/después de medianoche; app corriendo durante la medianoche
• Cambios de zona horaria: crear una entrada, cambiar la zona, abrir la app—¿la entrada permanece en el día intencionado?
• Transiciones DST: el día con “hora faltante” y el día con “hora repetida”; comportamiento de recordatorios; cálculos de tendencias
• Año bisiesto: 29 de feb en años bisiestos; comportamiento al navegar el historial alrededor de esa fecha

Un truco útil: escribir tests usando “relojes” fijos (mocked current time) para que los resultados no dependan del momento en que se ejecuten.

Valida edición, backfill y estados vacíos

Los casos límite suelen venir del comportamiento normal del usuario:

• Editar entradas: cambiar el valor de hoy, deshacer, sobrescribir con otro valor; confirmar que UI y dato almacenado coinciden
• Límites de backfill: intentar añadir valores fuera de la ventana permitida; asegurar que el mensaje sea claro
• Duplicados: intentar añadir una segunda entrada el mismo día; verificar que la app o lo bloquea o lo convierte en edición
• Estados vacíos: primer lanzamiento sin datos, borrar la última entrada, historial con huecos—gráficos y listas deben mantenerse estables y amigables

Añade tests unitarios para las reglas que no se ven a simple vista

Prioriza tests unitarios para:

• Conversión fecha→clave-de-día (qué string/ID representa “el día”)
• Validación (rangos permitidos, campos obligatorios, una entrada por día)
• Agregaciones (rachas, promedios semanales) a través de zonas horarias/DST

Haz pruebas en dispositivos reales para la UX y accesibilidad

Los simuladores no detectan todo. Prueba al menos en un dispositivo pequeño y otro grande, además de:

• Texto grande / tipo dinámico
• Alto contraste / modo oscuro
• Orden de foco y etiquetas de lector de pantalla
• Uso con una mano: ¿pueden añadir el valor de hoy rápidamente sin taps precisos?

Si estas pruebas pasan, la app se sentirá “aburridamente fiable”, que es justo lo que el seguimiento diario necesita.

Lanzamiento, onboarding y plan de iteración

Una app de una métrica vive o muere por su claridad. Tu lanzamiento debe hacer que la “entrada diaria” sea obvia, y la primera semana tras el lanzamiento debe centrarse en suavizar fricciones—no en añadir funciones.

Aspectos básicos para App Store / Play Store

La ficha en la store es parte del producto. Manténla visual y específica:

• Prepara capturas sencillas que muestren: (1) ingresar el valor de hoy, (2) ver historial reciente, (3) una vista ligera de tendencias
• Escribe una descripción corta que explique la promesa en una frase: “Registra un número por día en menos de 10 segundos.”
• Haz que el ícono y el nombre sean fáciles de reconocer y buscar; evita juegos de palabras que oculten lo que hace

Precio: elige un modelo claro

Elige un modelo de precio que puedas explicar en una línea. Para un rastreador simple, la complejidad daña la confianza:

• Gratis (con propina/donación opcional)
• Pago único
• Suscripción (solo si ofreces valor continuo como sincronización entre dispositivos o insights avanzados)

Onboarding que ocupe una pantalla

El onboarding debe preparar lo mínimo para empezar.

Pide:

• Nombre y unidad de la métrica (p. ej., “Peso, kg”)
• Dirección de objetivo opcional (subir/bajar/mantener)
• Hora de recordatorio (con “Saltar” fácil)

Luego lleva al usuario directamente a “Hoy”. Evita tutoriales en varios pasos.

Iteración post-lanzamiento

Trata el primer lanzamiento como una herramienta de aprendizaje:

• Monitorea crashes y rendimiento a diario la primera semana
• Recoge feedback con un aviso ligero tras unas entradas
• Prioriza arreglos que reduzcan entradas perdidas: fechas confusas, historial difícil de encontrar, recordatorios molestos
• Lanza actualizaciones pequeñas con frecuencia, centradas en los 1–2 puntos de dolor principales

Si construyes e iteras rápido, herramientas como Koder.ai pueden acortar el ciclo: prototipa el MVP por chat, desplegar/hostear, snapshot y revertir cambios con seguridad, y exportar el código cuando quieras pasar a un pipeline de ingeniería a más largo plazo.