# Práctica 1 — Emprendimiento Empresarial
## Análisis de producto: módulo de Gestión Financiera Simple (SFM)

> Documento generado a partir del estado real del código y las decisiones tomadas
> durante el desarrollo (no es un plan de negocio previo redactado antes del
> desarrollo, sino una reconstrucción honesta hecha después de los hechos). Donde no
> existe evidencia o decisión documentada en el proyecto, se indica explícitamente
> como **"aún no definido"** en vez de inventar información.

---

## 1. Descripción general del proyecto

**Nombre del proyecto (tentativo):** "Gestión Financiera Simple" (alias interno `sfm`).
Es un módulo dentro de un sistema más grande llamado "Sistema Modular con Enfoque en
Roles" (repo `Laravel_roles`), que también incluye módulos de hoteles, restaurante,
cursos y ministerio de medios. No existe todavía un nombre de marca independiente
para el producto financiero por sí solo — **aún no definido**.

**¿En qué consiste?** Es una aplicación **web** (Laravel 13 + Livewire 4 + MaryUI/
DaisyUI), de uso vía navegador, con diseño responsive. No es una app móvil nativa ni
de escritorio. Existe una **base de API REST** (Laravel Sanctum) pensada para
alimentar una futura app móvil en Flutter, pero esa app **no se ha empezado a
construir** — solo existen los endpoints (`wallets`, `buckets`, `transactions`).

**Funcionalidades actualmente implementadas:**
- Dashboard financiero con KPIs (ingresos, egresos, neto, saldo total multi-moneda),
  gráfica de dona por tipo de gasto (necesidades/deseos/ahorro/apoyo/deudas), gráfica
  de tendencia de 6 meses, y filtros por mes/año/general.
- Billeteras (`Wallet`) con saldo derivado 100% de transacciones, en distintas monedas.
- Movimientos (`Transaction`): ingreso, egreso y transferencia entre billeteras, con
  selección múltiple y borrado seguro, filtros avanzados, exportación.
- Sobres/categorías (`Bucket`) con metodología tipo 50/30/20 (necesidad/deseo/ahorro/
  apoyo/deuda) y presupuesto por sobre.
- Presupuesto mensual histórico (`Budget`) — cada mes guarda su propio monto
  presupuestado y queda bloqueado (solo lectura) una vez transcurrido.
- Gastos fijos recurrentes (`RecurringExpense`) con pago rápido desde el dashboard.
- Grupo/hogar compartido (`Household`, `HouseholdExpense`, `HouseholdPayment`) para
  gastos divididos entre varias personas del mismo grupo familiar.
- Tarjetas de crédito y ciclos de facturación (`CreditCard`, `CardCycle`).
- Metas de ahorro (`SavingGoal`) enlazadas directamente a transacciones reales (no a
  un monto manual): el monto ahorrado se recalcula automáticamente según los
  movimientos marcados con esa meta, con botón de recalcular manual como red de
  seguridad.
- Plan de ahorro (`SavingsPlan`) — vista de disponible sin asignar vs. asignado a sobres.
- Reporte anual y libro mayor de billetera (`WalletLedger`) con paginación en base de
  datos.
- Proyección de flujo de caja a 30/60/90 días (ingreso estimado + gastos fijos +
  gasto variable histórico + aportes a metas).
- Multi-moneda con tasas de cambio manuales o vía API externa (freecurrencyapi.com),
  nunca asume conversión 1:1 si falta la tasa.
- Asistente de importación de estados de cuenta bancarios en CSV (4 pasos, detección
  de duplicados) y un "Data Center" genérico de importación/exportación CSV/Excel
  para todas las entidades del módulo.
- Manual de usuario integrado (16 secciones) filtrado por permisos.
- Auditoría/bitácora de cambios y permisos granulares por pantalla (Spatie Permission).
- API REST (Sanctum) para wallets/buckets/transactions, con los mismos permisos que
  la web — pensada para consumo desde una futura app móvil.

**Funcionalidades planeadas pero no implementadas:**
- App móvil en Flutter (decidida en análisis, no iniciada).
- Frontend público desacoplado (se evaluó Astro; decisión abierta, no tomada).
- Conversión automática de moneda en transferencias entre billeteras de distinta
  moneda (hoy se mueve el monto 1:1 sin convertir).
- Categorización automática de gastos, recomendaciones o cualquier componente de
  inteligencia artificial — **aún no definido**, no hay plan concreto ni decisión tomada.
- Blacklist de IPs a nivel de seguridad — decisión evaluada pero no implementada.

**Población/usuario objetivo:** **aún no definido** como perfil formal de negocio. En
la práctica, el único usuario real hoy es el propio desarrollador y su grupo
familiar/hogar (a través del módulo Household). No hay usuarios externos, ni
encuestas, ni validación de mercado.

**Etapa del proyecto:** uso personal con datos reales (el propio autor lleva sus
finanzas reales en el sistema — de hecho existen recordatorios internos de nunca
tocar esa base de datos por accidente). No es un producto público ni comercial: no
tiene dominio propio desplegado (`APP_URL=http://localhost`, `APP_ENV=local`), no
tiene sistema de pagos, no tiene usuarios de pago. Podría describirse como un **MVP
funcional de uso personal**, más maduro que un prototipo pero sin validar como
negocio.

---

## 2. Problema que resuelve

**Problema específico identificado:** **aún no definido de forma explícita.** No
existe en el proyecto un documento de "problem statement" redactado antes de empezar
a construir — el primer commit del módulo (2026-01-04) es puramente técnico
("Creación de migraciones, seeders, modelos, rutas..."), sin una justificación de
negocio documentada. Lo que sí puede inferirse **razonablemente de las
funcionalidades construidas** (no es lo mismo que un research documentado) es que el
proyecto busca resolver: falta de visibilidad de en qué se gasta el dinero (por eso
existen los "sobres"/categorías con presupuesto), dificultad para sostener el ahorro
(metas de ahorro ligadas a movimientos reales, no solo un número aspiracional),
manejo de gastos compartidos en el hogar (módulo Household), y control de gastos fijos
recurrentes y tarjetas de crédito.

**¿A quién afecta?** **Aún no definido** como perfil de investigación. En la
práctica: al propio autor y su grupo familiar.

**¿Dónde ocurre?** Contexto confirmado: **Guatemala** — el sistema usa explícitamente
el timezone de Guatemala y soporta la moneda local (quetzal) junto con otras monedas.
Más allá de esto, no hay un estudio de contexto latinoamericano o de informalidad
laboral documentado — **aún no definido**.

**¿Con qué frecuencia ocurre?** **Aún no definido** de forma documentada, pero el
diseño del sistema asume uso frecuente/diario para el registro de movimientos y
ciclos mensuales para presupuestos y gastos fijos.

---

## 3. Evidencia del problema

**Aún no definido.** No existen en el proyecto datos, estudios, encuestas ni
estadísticas citadas (guatemaltecas ni latinoamericanas) sobre educación financiera,
ahorro, endeudamiento o uso de apps financieras. No se realizaron entrevistas ni
encuestas informales documentadas. No hay referencia a fuentes oficiales (Banguat,
Superintendencia de Bancos, INE) en ningún documento del repositorio. Esta es
honestamente la sección más débil del proyecto desde el punto de vista de
"emprendimiento validado" — el desarrollo partió de la necesidad personal del autor,
no de investigación de mercado.

---

## 4. Impacto

- **Impacto económico:** **aún no definido** — no hay medición ni estudio propio
  sobre cuánto le cuesta a alguien no llevar sus finanzas ordenadas.
- **Impacto social:** **aún no definido** — no hay investigación sobre estrés
  financiero o relaciones familiares asociadas al problema.
- **Impacto operativo (esto sí es verificable en el propio uso del sistema):** el
  sistema reemplaza el registro manual en hojas de cálculo o en la memoria por un
  flujo estructurado (billetera → movimiento → sobre/categoría → presupuesto), con
  reportes automáticos que antes requerirían armar manualmente. Esto es una
  observación derivada de lo que el software hace, no de un estudio de procesos de
  terceros.
- **Impacto tecnológico:** se puede señalar una brecha real que el proyecto sí
  atiende deliberadamente: soporte nativo de zona horaria y contexto de Guatemala, y
  soporte multi-moneda pensado para quien maneja quetzales junto con otra moneda
  (ej. dólares). Esto es una decisión de diseño confirmada en el código, no un
  hallazgo de investigación de mercado formal — no se comparó explícitamente contra
  apps existentes en español para el mercado guatemalteco.

---

## 5. Clientes / usuarios

**Cliente principal:** persona individual o su grupo familiar/hogar (no una empresa
ni una entidad gubernamental).

**Modelo:** **B2C.** Justificación: el sistema de permisos es por usuario individual,
el módulo `Household` está diseñado para compartir gastos entre miembros de un mismo
grupo/familia (no entre empleados de una organización), y no existe ningún concepto
de cliente institucional, facturación B2B, ni integración con entidades de gobierno.

---

## 6. Perfil de cliente ideal (ICP)

**Aún no definido formalmente** — no existe un ICP documentado ni validado con
usuarios reales fuera del propio autor. Como hipótesis razonable (no validada):
alguien con alfabetización digital media-alta, acceso a smartphone/computadora,
maneja más de una cuenta o billetera (efectivo + banco, posiblemente otra moneda), y
tiene la disciplina o el interés de registrar sus movimientos con cierta regularidad
— el sistema no ofrece hoy sincronización bancaria automática, así que exige registro
manual o importación periódica de CSV. Su disposición real a adoptarlo,
beneficio esperado, y nivel de urgencia del problema: **aún no definido**, no se ha
probado con nadie fuera del entorno del propio desarrollador.

---

## 7. Mapa de empatía

**Aún no definido.** No se realizó investigación de usuario (entrevistas,
observación, encuestas) que sustente un mapa de empatía real. Completar este punto
con contenido inventado sería contradecir el estado real del proyecto.

---

## 8. Oportunidad de negocio

**Aún no definido como análisis competitivo formal.** No existe en el proyecto una
comparación documentada contra otras herramientas (Fintonic, Money Lover, Excel,
etc.), ni una tesis de mercado escrita. Lo único documentado es una decisión técnica
(ver `docs/ideas/api-y-app-movil.md`) sobre cómo evolucionar la arquitectura hacia
app móvil y frontend público, pero ese documento es de arquitectura, no de
oportunidad de mercado. Quiénes se beneficiarían directa e indirectamente: **aún no
definido** más allá de "el autor y su hogar" como beneficiarios directos actuales.

---

## 9. Hipótesis de negocio

- **Hipótesis del problema:** **aún no definida** de forma explícita por el proyecto
  (ver punto 2 y 3).
- **Hipótesis de la solución:** puede reconstruirse desde lo implementado: un sistema
  simple de billeteras + categorías con presupuesto + metas de ahorro ligadas a
  movimientos reales reduce la fricción de llevar finanzas personales ordenadas,
  frente a alternativas como hojas de cálculo (más manuales) o apps genéricas no
  adaptadas al contexto de quien las usa.
- **Hipótesis del modelo de ingresos:** **aún no definida por el usuario** — hoy el
  proyecto es de uso personal, sin sistema de pagos ni planes. Como hipótesis
  razonable que el proyecto podría explorar si se convirtiera en producto: modelo
  freemium, con el registro de movimientos, billeteras y presupuesto básico gratis,
  y funciones "avanzadas" (ya existentes en el código, como Proyección de Flujo de
  Caja, Import Bancario o multi-moneda con conversión automática) como capa premium
  de pago único o suscripción baja. Es una hipótesis mía razonada sobre la
  arquitectura actual, no una decisión tomada por el usuario.

---

## 10. Propuesta de solución

- **Tipo:** aplicación web (Laravel + Livewire), con una capa de API REST (Sanctum)
  ya construida como base para una futura app móvil híbrida — hoy el consumidor real
  de esa API todavía no existe.
- **¿Usa inteligencia artificial?** No. No hay categorización automática, recomendaciones
  ni chatbot financiero implementados, ni tampoco un plan concreto documentado para
  agregarlo — **aún no definido**.
- **Funcionalidades principales** (lista real, ver punto 1 para el detalle completo):
  registro de movimientos (ingreso/egreso/transferencia), presupuestos mensuales por
  categoría, metas de ahorro ligadas a movimientos reales, reportes (dashboard, anual,
  libro mayor), proyección de flujo de caja, gastos fijos recurrentes, gastos
  compartidos en grupo/hogar, tarjetas de crédito y ciclos, multi-moneda con tasas de
  cambio, importación de estados de cuenta bancarios en CSV y exportación/importación
  masiva de datos. No hay sincronización bancaria automática (open banking) — todo
  ingreso de datos es manual o vía CSV.

---

## 11. Diseño conceptual / flujo de uso

**Flujo real de un usuario nuevo:**
1. Inicia sesión (autenticación por usuario/contraseña).
2. Llega al Dashboard Financiero (resumen de billeteras, KPIs, presupuesto, gráficas).
3. Crea sus Billeteras (efectivo, cuenta bancaria, tarjeta, etc.), cada una con su moneda.
4. Revisa/ajusta los Sobres (categorías tipo necesidad/deseo/ahorro/apoyo/deuda) — el
   sistema trae un seeder de sobres recomendados que se pueden aplicar de una vez.
5. Registra Movimientos (ingresos, egresos, transferencias entre billeteras),
   asignando sobre y, opcionalmente, meta de ahorro.
6. Configura Gastos Fijos recurrentes y, si aplica, un Grupo/Hogar para gastos
   compartidos.
7. Consulta reportes: Dashboard, Plan de Ahorro, Reporte Anual, Proyección de Flujo
   de Caja, Presupuesto Mensual.
8. Opcionalmente importa movimientos masivos desde un CSV bancario o vía el Data
   Center genérico.

**Módulos (dentro del propio módulo SFM):** Dashboard, Billeteras, Movimientos,
Sobres, Gastos Fijos, Grupo/Hogar, Tarjetas de Crédito, Ciclos de Tarjeta, Plan de
Ahorro, Metas de Ahorro, Reporte Anual, Data Center, Proyección de Flujo de Caja,
Presupuesto Mensual, Tasas de Cambio, Importación Bancaria, Manual de Usuario.

**Infraestructura tecnológica:**
- Backend: PHP 8.5, Laravel 13, Livewire 4 (+ Volt), Spatie Permission (roles y
  permisos granulares).
- Frontend: MaryUI sobre DaisyUI 5, Tailwind CSS 4, Alpine.js, Chart.js (gráficas,
  carga diferida).
- Base de datos: **MySQL 8.0+** es el motor requerido según el README oficial del
  proyecto (algunas consultas, como el libro mayor de billetera, usan funciones de
  ventana que requieren MySQL 8; la suite de pruebas no corre sobre SQLite por
  migraciones específicas de MySQL).
- Autenticación de API: Laravel Sanctum (tokens Bearer, sin modo SPA-stateful).
- Hosting: **aún no definido** — no hay despliegue en un dominio propio todavía
  (entorno actual configurado como local).
- API externa opcional: freecurrencyapi.com para actualizar tasas de cambio (con
  clave propia del usuario, nunca compartida).

**Datos que maneja el sistema:** ingresos, egresos y transferencias con fecha, monto
y moneda; billeteras y sus saldos; categorías/sobres con su tipo (necesidad, deseo,
ahorro, apoyo, deuda) y presupuesto asociado; gastos fijos recurrentes; tarjetas de
crédito y sus ciclos de facturación; metas de ahorro y su progreso; presupuestos
mensuales históricos; tasas de cambio entre monedas; grupos/hogares y los pagos que
sus miembros hacen de gastos compartidos; bitácora de auditoría de cambios.

---

## 12. Modelo de negocio

**Opinión:** el proyecto está claramente en fase de **idea/emprendimiento inicial**,
por lo que un **Lean Canvas** es la herramienta apropiada, no un Business Model
Canvas. Justificación: no hay clientes de pago, no hay canales de adquisición, no hay
socios clave ni estructura de costos institucional que analizar — hoy es
esencialmente un proyecto de un solo desarrollador para uso propio, sin validación de
mercado (ver puntos 3, 6, 7 y 8, todos marcados como "aún no definido"). Un Business
Model Canvas asumiría una madurez de negocio (relaciones con clientes existentes,
estructura de ingresos activa, socios) que este proyecto todavía no tiene.

---

## 13. Categoría tecnológica

El proyecto encaja claramente como **FinTech** (gestión financiera personal): registro
de transacciones, presupuestos, metas de ahorro, multi-moneda y proyección de flujo
de caja son funciones típicas de esa categoría.

¿Elementos de otra categoría? **Componente de IA:** no implementado — **aún no
definido** si se planea agregarlo. **Componente educativo (EdTech):** el sistema
tiene un Manual de Usuario integrado (ayuda a usar la herramienta), pero eso es
documentación de producto, no contenido educativo de finanzas personales (no hay
tips financieros, cursos ni contenido pedagógico dentro del módulo SFM). El sistema sí
tiene un módulo de Cursos (`cm`) en el proyecto general, pero es independiente y no
está integrado con el módulo financiero — por lo tanto, no corresponde clasificar SFM
como EdTech hoy.

---

## Nota final de honestidad

Los puntos 3 (evidencia del problema), 6 (ICP), 7 (mapa de empatía) y 8 (oportunidad
de negocio) son los más débiles del proyecto visto como emprendimiento: nacieron como
una necesidad personal del desarrollador y crecieron por funcionalidades técnicas
(commits sucesivos), no por un proceso de descubrimiento de cliente. Si se va a usar
este planteamiento como base de una tarea de emprendimiento, vale la pena ser
transparente sobre esto y, si el curso lo permite, usarlo como punto de partida para
hacer ahora ese research pendiente (encuestas informales, entrevistas a 3-5 personas
del entorno guatemalteco) en vez de presentarlo como si ya existiera.
