Mariana era estudiante de ingeniería en sistemas y, como muchos de sus compañeros, vivía con el dilema de organizar su tiempo y su dinero. Cada mes empezaba con entusiasmo, compraba un nuevo cuaderno y anotaba todos sus gastos. Pero a la segunda semana, las hojas ya estaban llenas de tachones y cálculos incompletos. Al final del mes, siempre se preguntaba: “¿En qué se me fue el dinero?”

Un día, en la cafetería, vio a dos amigos discutiendo sobre una aplicación que usaban para registrar hábitos de estudio. Eso la hizo pensar: “¿Y si en vez de un cuaderno hiciera una app que me ayudara a registrar mis gastos y me mostrara un resumen bonito?”

Esa misma tarde abrió su libreta (la del mes, la de siempre) y empezó a escribir. Primero describió el problema y a quién ayudaría: estudiantes universitarios que quieren registrar sus gastos de forma rápida y visual.

Luego se imaginó a sí misma como usuaria y escribió tres frases:

• “Como estudiante, quiero anotar mis gastos de forma inmediata para no olvidarlos.”

• “Como estudiante, quiero ver una lista ordenada de mis gastos para darme cuenta en qué gasto más.”

• “Como estudiante, quiero ver un gráfico al final del mes para saber si me queda dinero.”

Cuando trató de pasar del papel a un dibujo, se dio cuenta de que necesitaba un flujo funcional. Dibujó un camino simple: abrir app → registrar gasto → ver lista → ver reporte mensual. Con ese esquema, empezó a imaginar pantallas: un botón grande con “+ gasto”, una lista con fechas y categorías, y al final un gráfico circular de colores.

Recordó a un profesor que siempre repetía: “Piensa en capas, no todo vive en la misma caja.” Así que en otra hoja hizo tres cajitas:

• Interfaz: las pantallas, botones y gráficos.

• Lógica: las reglas, por ejemplo, que cada gasto debe tener fecha, monto y categoría.

• Datos: el lugar donde se guarda todo, ya sea en el teléfono o en la nube.

Eso la llevó a la siguiente pregunta: “¿Dónde van a vivir mis datos?” Decidió que al inicio sería local (en su celular, con algo como una base de datos pequeña), pero que más adelante podría sincronizar con la nube para no perder la información. Dibujó un teléfono conectado a una nube y escribió: “Local primero, sincronización después.”

Para organizar los datos, escribió en su libreta dos opciones:

• Lista: para tener todos los gastos uno tras otro.

• Mapa/diccionario: para asociar categorías con montos totales (ej.: comida → 1200, transporte → 800).

Con eso, el cuaderno empezaba a tener más orden que nunca.

Finalmente, pensó en cómo hacer que todo funcionara de manera limpia. Había leído en un blog sobre MVVM: separar la interfaz (lo que ve el usuario), la lógica (cómo se procesan los gastos) y los datos (de dónde vienen). También encontró el patrón Repository, que servía para unir lo que está en el celular con lo que está en la nube. Dibujó un esquema sencillo con flechas: Pantallas → ViewModel → Repositorio → Base de datos / Nube.

Cuando terminó, cerró la libreta con una sonrisa. Todavía no tenía código, pero tenía algo más importante: un plano de arquitecta digital. Ahora entendía que antes de escribir una línea de programación, debía diseñar con intención.

Mariana era estudiante de ingeniería en sistemas y, como muchos de sus compañeros, vivía con el dilema de organizar su tiempo y su dinero. Cada mes empezaba con entusiasmo, compraba un nuevo cuaderno y anotaba todos sus gastos. Pero a la segunda semana, las hojas ya estaban llenas de tachones y cálculos incompletos. Al final del mes, siempre se preguntaba: “¿En qué se me fue el dinero?”

Un día, en la cafetería, vio a dos amigos discutiendo sobre una aplicación que usaban para registrar hábitos de estudio. Eso la hizo pensar: “¿Y si en vez de un cuaderno hiciera una app que me ayudara a registrar mis gastos y me mostrara un resumen bonito?”

Esa misma tarde abrió su libreta (la del mes, la de siempre) y empezó a escribir. Primero describió el problema y a quién ayudaría: estudiantes universitarios que quieren registrar sus gastos de forma rápida y visual.

Luego se imaginó a sí misma como usuaria y escribió tres frases:

• “Como estudiante, quiero anotar mis gastos de forma inmediata para no olvidarlos.”

• “Como estudiante, quiero ver una lista ordenada de mis gastos para darme cuenta en qué gasto más.”

• “Como estudiante, quiero ver un gráfico al final del mes para saber si me queda dinero.”

Cuando trató de pasar del papel a un dibujo, se dio cuenta de que necesitaba un flujo funcional. Dibujó un camino simple: abrir app → registrar gasto → ver lista → ver reporte mensual. Con ese esquema, empezó a imaginar pantallas: un botón grande con “+ gasto”, una lista con fechas y categorías, y al final un gráfico circular de colores.

Recordó a un profesor que siempre repetía: “Piensa en capas, no todo vive en la misma caja.” Así que en otra hoja hizo tres cajitas:

• Interfaz: las pantallas, botones y gráficos.

• Lógica: las reglas, por ejemplo, que cada gasto debe tener fecha, monto y categoría.

• Datos: el lugar donde se guarda todo, ya sea en el teléfono o en la nube.

Eso la llevó a la siguiente pregunta: “¿Dónde van a vivir mis datos?” Decidió que al inicio sería local (en su celular, con algo como una base de datos pequeña), pero que más adelante podría sincronizar con la nube para no perder la información. Dibujó un teléfono conectado a una nube y escribió: “Local primero, sincronización después.”

Para organizar los datos, escribió en su libreta dos opciones:

• Lista: para tener todos los gastos uno tras otro.

• Mapa/diccionario: para asociar categorías con montos totales (ej.: comida → 1200, transporte → 800).

Con eso, el cuaderno empezaba a tener más orden que nunca.

Finalmente, pensó en cómo hacer que todo funcionara de manera limpia. Había leído en un blog sobre MVVM: separar la interfaz (lo que ve el usuario), la lógica (cómo se procesan los gastos) y los datos (de dónde vienen). También encontró el patrón Repository, que servía para unir lo que está en el celular con lo que está en la nube. Dibujó un esquema sencillo con flechas: Pantallas → ViewModel → Repositorio → Base de datos / Nube.

Cuando terminó, cerró la libreta con una sonrisa. Todavía no tenía código, pero tenía algo más importante: un plano de arquitecta digital. Ahora entendía que antes de escribir una línea de programación, debía diseñar con intención.