Rate Tracking - Mi supervisor de tasas de cambio personal

Comencé este proyecto porque extrañaba tener la libertad de llevar una idea desde el concepto hasta producción. Cuando trabajas para una empresa, muchas veces estás siguiendo el roadmap de alguien más y no siempre hay espacio para los proyectos que realmente te importan. Construir algo desde cero es un gran ejercicio: no solo para mantenerte al día con las últimas tecnologías, sino también para afinar tu capacidad de levantar requerimientos, diseñar valor para el usuario y, finalmente, lanzar un producto que funcione.

Por qué comenzó este proyecto

La idea nació de una necesidad muy personal: quería una forma de recibir notificaciones cuando la tasa de cambio entre mi moneda local y la de mi país de origen (Colombia) fuera favorable, para poder enviar dinero a casa en el mejor momento posible.

Claro, existen muchas herramientas y servicios (Google, Yahoo, otras apps financieras o billeteras digitales) que pueden ayudar. Pero yo quería algo personalizado, hecho a mi medida, que pudiera responder una pregunta muy concreta:

“Hoy, ¿es un buen día para enviar dinero a casa?”

Además, me impuse algunas restricciones:

El proyecto debía tomar el menor tiempo posible.
Debía costar nada (o casi nada).
Y la primera versión (MVP) debía ser accesible tanto desde la web como desde el móvil, por si en algún momento encontraba otros usuarios a quienes también les resultara útil.

Versión corta: ¿lo logré? Sí!

Después de varios meses de trabajo, construí el producto. Puedes verlo aquí: Rate Tracking (Web).

También hay una versión para Android aquí: Google Play — Closed Test.

En cuanto al costo, fue prácticamente gratis. El único gasto fue la tarifa única de la cuenta de Google Play Developer (alrededor de 25 USD). El backend (servidor, base de datos y tareas programadas) estuvo completamente alojado usando servicios gratuitos o serverless. Esto implicó una base de datos pequeña (suficiente solo para un MVP) y un servidor mínimo que se activa únicamente cuando es necesario. Para los trabajos en segundo plano, utilicé GitHub Workflows, que siguen siendo gratuitos dentro de ciertos límites.

¿Fue rápido de crear? Gracias a usar una herramienta como Cursor (mi “aliado” durante el desarrollo), el tiempo se redujo considerablemente. Aun así, tomó varios meses llegar a lo que considero una versión “aceptable”. Esto me enseñó que incluso un producto relativamente liviano requiere bastante trabajo para estar listo para producción… y eso antes de pensar en iterar para muchos usuarios.

Qué significó esto para mí — y para un producto futuro

Pude llevar un proyecto completo desde la idea hasta un producto en vivo. Solo eso ya es muy gratificante.
Aprendí a diseñar pensando en web y móvil desde el inicio (lo que mejora mucho la flexibilidad a futuro).
Validé que es posible construir un servicio útil con un presupuesto mínimo y una infraestructura muy simple, ideal para un MVP.
Y, lo más importante, construí algo que resuelve un problema real para mí. Si algún día encuentro a más personas con la misma necesidad (saber cuándo enviar dinero a casa), ya tengo una base funcional.

Versión larga

En esta sección profundizo en cómo construí el producto. Ojalá sea útil para cualquiera que quiera empezar a crear algo desde cero y, de paso, aprovechar los “superpoderes” de la IA que muchos solemos pasar por alto.

Ideación

Esta fue la primera fase. Empecé haciéndome dos preguntas muy simples:

¿Qué es exactamente lo que quiero construir?
¿Cuál es la versión mínima que resolvería mi problema?

Anoté la idea central, esbocé una solución básica y luego usé ChatGPT para refinarla. Tras varias iteraciones, el concepto se volvió mucho más claro y tuve una mejor idea de lo que quería lograr.

Preparación

Con la idea definida, el siguiente paso fue pensar en el diseño del sistema: los componentes necesarios para que todo funcionara.

Ser ingeniero full-stack ayudó bastante aquí. Sabía que, como mínimo, necesitaría:

Un backend
Un frontend
Un sistema de tareas programadas (cron jobs) para las alertas
Una base de datos
Un servicio gratuito desde donde obtener las tasas de cambio

Por supuesto, también le pedí sugerencias a ChatGPT y —como era de esperarse— las respuestas coincidieron bastante con lo que ya tenía en mente. El diseño final quedó así:

Backend serverless
Frontend basado en React
Un servidor (o runner) para los cron jobs
Una base de datos relacional
Una API pública con plan gratuito para obtener tasas de cambio

Más adelante aprendí que encontrar un servicio gratuito que mantenga un servidor activo 24/7 para cron jobs es casi imposible… pero volveré a ese punto en un momento.

Elección de tecnologías

Como llevo muchos años trabajando con JavaScript, quise mantener todo dentro de ese ecosistema. Le pedí recomendaciones a ChatGPT y, nuevamente, coincidieron con lo que ya estaba considerando.

Frontend

Elegí Expo porque permite apuntar a web, Android e iOS desde una sola base de código, lo cual es perfecto para un MVP.

Backend

ChatGPT recomendó NestJS, que es una excelente opción para aplicaciones grandes gracias a su estructura y separación de responsabilidades. Pero para algo sencillo, introduce bastante boilerplate.

En su lugar, opté por Node.js y Express, lo que me permitió avanzar rápido con el mínimo overhead.

Base de datos

Quería algo estructurado, confiable y con lecturas rápidas. Una base de datos relacional, como PostgreSQL, era la elección obvia.

Cron jobs

Para las tareas programadas, simples scripts en Node.js fueron más que suficientes.

Infraestructura

Al inicio planeé desplegar todo en Vercel, pero pronto me di cuenta de que está optimizado principalmente para frontend y APIs de Next.js. Yo quería que mi backend fuera independiente y serverless.

Después de investigar un poco —y hacer más consultas a ChatGPT— encontré Render, que ofrece instancias serverless con integración CI sencilla. Funcionó perfecto para alojar el backend.

Para el frontend, me quedé con Vercel porque:

Su plan gratuito es excelente
La integración con GitHub es extremadamente simple

Además, Vercel ofrece una opción gratuita de PostgreSQL a través de Neon, que fue increíblemente fácil de configurar. El plan gratuito incluye 500 MB de almacenamiento y autoescalado de 0,25 CU a 2 CU, más que suficiente para un MVP.

Con la base de datos y el backend listos, quedaba una pieza clave: de dónde obtener las tasas de cambio más actualizadas. Investigando —y con ayuda de ChatGPT— llegué a Open Exchange Rates. Es uno de los proveedores más consistentes y confiables y su plan gratuito tiene límites perfectamente razonables para un MVP.

La parte complicada: los cron jobs

Este fue el mayor reto. Pensé que necesitaba un servidor corriendo 24/7 para que los cron jobs se ejecutaran en horarios específicos. Todos los proveedores que revisé cobraban por eso, incluso las opciones más baratas en GCP y AWS.

Estuve muy cerca de pagar.

Hasta que tuve otra conversación con ChatGPT y caí en cuenta de algo clave:

GitHub Actions soporta cron schedules… y es gratis dentro de límites razonables.

Para un MVP que ejecuta tareas dos veces al día, GitHub Actions fue perfecto. Problema resuelto.

Arquitectura

Con todas las piezas definidas, el diseño completo del sistema quedó armado.

Desarrollo

Durante el desarrollo, quería evitar perder tiempo en boilerplate. Prefería enfocarme en decisiones de producto y lógica. Para eso usé Cursor y, más adelante, Antigravity para ayudarme a generar código.

Antes de generar nada, definí reglas claras para los agentes de IA, basadas en lo que para mí es importante en una base de código:

Separación de responsabilidades: cada archivo en su propia carpeta y con una función clara
Tests unitarios: cada archivo generado debía incluir sus propios tests
Reutilización: antes de generar código nuevo, verificar si ya existía un patrón similar
Mantenibilidad: documentar funciones complejas; si la complejidad supera 7, dividirla

Estas reglas fueron evolucionando. Al principio, la IA generaba soluciones funcionales, pero el código era difícil de leer y mantener. Ajusté las reglas hasta que el código generado fuera limpio, consistente y fácil de mejorar.

Ese se convirtió en mi principio principal: la IA debe producir código que yo pueda entender y mejorar fácilmente más adelante.

Despliegue

El despliegue fue bastante sencillo.

Frontend (Expo en Vercel)

Conecté el repositorio de GitHub, configuré los comandos de build para Expo y listo.

Backend (Render)

Render maneja los despliegues automáticamente mediante la integración con GitHub.

Cron jobs (GitHub Actions)

Para las tareas programadas, solo necesité un workflow dentro de .github/workflows/:

YAML

name: Release to Google Play

on:
  pull_request:
    types:
      - closed
    branches:
      - main

permissions:
  contents: read

jobs:
  release-android:
    # Run only for merged release PRs
    if: |
      github.event.pull_request.merged == true &&
      (contains(github.event.pull_request.title, 'chore: release') ||
       contains(github.event.pull_request.head.ref, 'release-please'))
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Setup EAS CLI
        uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}

      - name: Build Android App Bundle
        run: eas build --platform android --profile production --non-interactive --wait

      - name: Submit to Google Play
        run: eas submit --platform android --profile production --non-interactive --latest
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}

Despliegue en Android

Mientras escribo esto, aún no he construido la versión para iOS, así que me enfoqué exclusivamente en Android.

Necesitas una cuenta de Google Play Developer, que ahora cuesta una tarifa única de 25 USD. Hace diez años era gratis, pero probablemente el costo ayuda a mejorar la calidad de la tienda.

Después de crear la cuenta, hay un proceso largo de onboarding donde debes proporcionar información personal (o de la empresa). Solo entonces puedes crear el proyecto de la app.

Pero eso no es suficiente para publicarla…

Debes pasar por varias fases de testing:

Pruebas internas
Pruebas cerradas
Pruebas abiertas
Completar 12 pruebas durante 14 días en testing cerrado
Revisión final de Google

Solo después de todo eso, tu app puede salir a producción.

Actualmente sigo en la fase de testing cerrado, así que si quieres ayudar:

Desde web → https://play.google.com/apps/testing/com.ratetracking.app
Desde Android → https://play.google.com/store/apps/details?id=com.ratetracking.app

Automatizando lanzamientos en Android

Para automatizar los despliegues usé EAS CLI, que es la herramienta recomendada por Expo.

Una vez configurado, creé una GitHub Action que construye y sube la app automáticamente cada vez que se hace merge a un PR de release.