Cuando empecé a planificar Caladero, mi primer instinto fue pensar en el proyecto como "una app con un mapa donde se marcan puntos". Con el tiempo entendí que esa forma de pensarlo era demasiado limitada, y que el mapa es solo la capa visible de un problema mucho más amplio de modelado de datos, organización de la información y decisiones de producto que no tienen nada que ver con qué librería de mapas se usa.

El error de pensar "primero el mapa, luego lo demás"

Es tentador empezar un proyecto de este tipo integrando una librería de mapas, poniendo un marcador en pantalla y dando por resuelta la parte difícil. En la práctica, mostrar un punto en un mapa es la parte más sencilla técnicamente. Lo difícil viene después: qué información acompaña a ese punto, cómo se relaciona con otros puntos, cómo se filtra, cómo se busca, y qué pasa cuando el usuario tiene cien puntos guardados en vez de tres.

Si el diseño del modelo de datos se pospone porque "ya lo resolveremos cuando haga falta", el resultado casi siempre es una estructura de datos pensada solo para pintar marcadores, que hay que rehacer en cuanto aparece la primera funcionalidad real de filtrado o búsqueda.

El mapa es la interfaz, no el producto

En Caladero, lo que realmente importa para un pescador no es ver un mapa bonito, es poder responder preguntas como: "¿qué puntos tengo guardados en esta zona?", "¿cuáles marqué como productivos en primavera?", "¿qué nota dejé la última vez que estuve aquí?". El mapa es la forma más natural de presentar esa información espacialmente, pero el valor real está en los datos estructurados detrás de cada punto: fecha, tipo de pesca, notas, condiciones, capturas.

Esto cambia por completo el orden en que diseño las cosas. Antes de decidir qué aspecto visual tendrá un marcador en el mapa, decido qué campos tiene el modelo de datos de un "punto guardado", cómo se relaciona con el usuario que lo creó, y qué operaciones necesito poder hacer sobre esos datos: filtrar, ordenar, exportar, buscar por texto.

Un ejemplo práctico: de "marcador en el mapa" a modelo de datos real

La primera versión mental de un punto guardado en Caladero era prácticamente solo unas coordenadas y un nombre. En cuanto empecé a pensar en cómo se usaría de verdad, el modelo creció de forma natural:

data class PuntoGuardado(
    val id: String,
    val nombre: String,
    val latitud: Double,
    val longitud: Double,
    val tipoPesca: TipoPesca,
    val notas: String?,
    val fechaCreacion: Instant,
    val fechaUltimaVisita: Instant?,
    val esPrivado: Boolean
)

Ese campo esPrivado, por ejemplo, no surgió de pensar en el mapa, surgió de pensar en cómo se comporta un pescador real: hay puntos que se quieren guardar solo para uso propio y puntos que en el futuro se podrían querer compartir. Ese matiz no tiene nada que ver con qué librería de mapas se use para pintar el marcador, pero condiciona completamente cómo se diseña cualquier funcionalidad futura de exportar o compartir.

Capas de información, no solo capas de mapa

Cuando se habla de "capas" en el contexto de mapas, la mayoría piensa en capas visuales: satélite, relieve, carreteras. Pero en una app como Caladero, las capas más importantes son de otro tipo: capas de organización de los propios datos del usuario. Por ejemplo, puedo mostrar solo los puntos marcados como productivos, o solo los visitados en los últimos tres meses, o agrupar puntos por tramo de un mismo río. Ese tipo de filtrado no depende de la librería de mapas, depende de cómo esté modelada y consultada la base de datos local que hay detrás.

Este es también el motivo por el que la elección de tecnología de mapas (algo que trato en detalle en el artículo sobre MapLibre o Google Maps) es una decisión secundaria comparada con el diseño del modelo de datos. Un mapa técnicamente excelente pero con un modelo de datos pobre sigue siendo una app limitada; un mapa sencillo con un modelo de datos bien pensado puede resolver de verdad el problema del usuario.

Funcionar sin conexión, no solo mostrar el mapa

Otra dimensión que se olvida fácilmente al pensar "es una app de mapas" es qué pasa sin conexión. Un pescador en una zona sin cobertura necesita poder consultar sus puntos guardados igual que en cualquier otro momento, no solo ver un mapa en blanco porque las teselas del mapa no se pudieron descargar. Esto conecta directamente con el enfoque que explico en el artículo sobre desarrollo local-first: los datos del usuario, incluidos sus puntos guardados, tienen que estar disponibles localmente independientemente de si el propio mapa base puede cargarse o no en ese momento.

Errores que cometí por pensar solo en el mapa

El primer error fue diseñar la pantalla de detalle de un punto pensando únicamente en qué se mostraba al pulsar sobre el marcador, sin pensar antes en qué información necesitaba realmente guardar sobre ese punto. Tuve que rehacer esa pantalla dos veces porque cada vez que añadía un campo nuevo al modelo de datos (como el tipo de pesca o la fecha de última visita), la interfaz que ya tenía construida no encajaba bien con la nueva información.

El segundo error fue subestimar cuánto trabajo de interfaz hace falta para gestionar decenas o cientos de puntos guardados, no solo tres o cuatro de prueba. Un mapa con tres marcadores se ve bien casi con cualquier diseño; un mapa con doscientos puntos necesita agrupación visual (clustering), filtros accesibles y una lista alternativa al propio mapa para no depender solo de tocar marcadores pequeños en pantalla. Esa necesidad no aparece hasta que se prueba con datos realistas, y es un error común probar solo con dos o tres puntos de ejemplo durante todo el desarrollo.

Conclusión

El componente de mapa es, en la práctica, la parte menos determinante del éxito de una app como Caladero. Lo que realmente define si la app resuelve un problema real es el modelo de datos detrás de cada punto, cómo se organiza esa información, y si sigue siendo útil incluso sin conexión a internet. Pensar el proyecto desde el principio como "una app de gestión de información geográfica personal" en vez de "una app de mapas" cambia el orden en que se toman las decisiones, y en mi experiencia, ese cambio de enfoque evita bastante trabajo repetido más adelante.