Qué es Mi Plante
Tiempo de lectura: ~30 minutos. Al terminar esta página deberías ser capaz de explicar Mi Plante a un amigo no técnico en tres oraciones, y a un ingeniero senior en quince.
Si solo tienes diez minutos, lee las secciones 1, 4 y 10. Vuelve al resto antes de escribir tu primer PR.
1. El pitch en 30 segundos
Mi Plante es un marketplace de crédito para colombianos que no pueden acceder fácilmente a una tarjeta de crédito.
Los clientes navegan productos de negocios aliados (llamados aliados), los compran a crédito con cuotas mensuales (llamadas cuotas), y pagan esas cuotas a través de la factura de servicios públicos de EMCALI que ya llega a su casa cada mes.
Si quieres una sola línea para un pitch deck:
“Klarna conoce a MercadoLibre, conoce a tu factura de la luz.”
- Klarna: paga en cuotas sin tarjeta de crédito.
- MercadoLibre: un marketplace con cientos de productos de muchos vendedores.
- Tu factura de la luz: el canal de recaudo es la factura de EMCALI que el cliente ya paga cada mes.
Stack: Laravel 12 + Inertia.js + Vue 3 + MySQL. El codebase está en español para el dominio, en inglés para el boilerplate del framework. El ticket promedio es de alrededor de 3.000.000 COP (~600 USD).
2. Por qué existe Mi Plante
La brecha de crédito colombiana
En Colombia, el crédito de consumo tradicional sin garantía es difícil de acceder para la mayoría de los trabajadores:
- Las tarjetas de crédito de los bancos exigen empleo formal, una historia crediticia larga y normalmente un ingreso mínimo que excluye a amplios sectores de la población.
- El “crédito de libre inversión” (préstamos personales) exige lo mismo.
- El crédito informal (gota a gota, prestamistas) es depredador y muchas veces ilegal.
- El crédito retail (Codensa, Falabella, Alkosto) existe pero está fragmentado por cada retailer y con frecuencia exige codeudor o “deudor solidario”.
Al mismo tiempo, la mayoría de los hogares de clase trabajadora pagan su factura de servicios públicos (EMCALI en Cali, EPM en Medellín, Codensa en Bogotá) todos los meses sin falta. Tienen que hacerlo. Si no pagas la factura, te cortan la luz. Así que las facturas de servicios públicos son uno de los pagos recurrentes más disciplinados de un hogar colombiano.
La intuición de Mi Plante
Si un cliente ya paga su factura de EMCALI de forma confiable, ese comportamiento de pago es una señal de crédito más fuerte que un puntaje FICO, y la propia factura de EMCALI es un canal de recaudo más fuerte que una cuenta bancaria o un débito automático a tarjeta de crédito.
Mi Plante combina tres piezas:
- Un marketplace donde los negocios aliados (aliados) listan productos.
- Un pipeline de decisión crediticia que usa burós de crédito colombianos (DataCrédito, TransUnion, Experian CrossCore) para validar identidad e historia crediticia.
- EMCALI como rail de recaudo. Cuando un cliente compra a crédito, Mi Plante agrega la cuota mensual a la factura de servicios públicos de EMCALI del cliente. El cliente paga la factura. EMCALI le transfiere el dinero de la cuota a Mi Plante. Mi Plante le paga al aliado.
El cliente nunca tiene que recordar una fecha de vencimiento separada, nunca tiene que ingresar una tarjeta de crédito, y puede repartir una compra de 3M COP en 6-60 meses a una tasa fija.
Por qué esto funciona primero en Cali
Mi Plante tiene sede en Cali. EMCALI es la empresa de servicios públicos de Cali. La primera integración es específicamente con EMCALI, lo que significa que el mercado de lanzamiento está naturalmente acotado al área de servicio de EMCALI. La expansión futura requeriría integrar EPM (Medellín), Codensa (Bogotá), CHEC, EBSA, etc. Hoy el producto es funcionalmente Cali primero.
3. Quiénes están involucrados — los actores
Mi Plante tiene cinco categorías de actores. Memoriza estos nombres; están en todas partes del codebase.
3.1 Cliente (Cliente)
El usuario final. Un colombiano del día a día — típicamente de ingresos bajos o medios-bajos — que quiere comprar un producto a crédito.
- Tiene un cupo (línea de crédito). Asignado después de que corre el pipeline de aprobación crediticia.
- Tiene un cupo disponible (crédito disponible). Se decrementa cada vez que compra algo a crédito.
- Paga cuotas a través de su factura mensual de EMCALI.
- Vive en un hogar con una membresía EMCALI verificada (número de factura, dirección).
En código: App\Models\Cliente (el perfil crediticio) + App\Models\User (la identidad de autenticación) + App\Models\Persona (el registro de identidad legal con cédula). Un humano = una Persona = (típicamente) un User = (típicamente) un Cliente.
3.2 Aliado / Socio (Aliado, Empresa)
Un negocio que vende productos a través del marketplace. En el código se llama tanto Aliado (el rol conceptual) como Empresa (el modelo real).
- Una Empresa tiene una o más Sucursales.
- Cada Sucursal tiene Empleados — humanos que usan el portal de aliados para procesar órdenes, registrar ventas, gestionar inventario.
- La Empresa publica su catálogo: Productos, Marcas, Líneas (categorías), Precios (variantes de precio).
- La Empresa tiene un canal_venta (online, físico, ambos) que dirige parte del comportamiento de UX.
En código: App\Models\Empresa, App\Models\Sucursal, App\Models\Producto, App\Models\Marca, App\Models\Linea, App\Models\Precio. Los empleados son filas de App\Models\User con guard = 'app' (el guard del portal de aliados) vinculadas a una Empresa vía user_empresa y opcionalmente a una Sucursal.
3.3 Mi Plante (el operador)
La compañía en sí. Tiene personal interno que:
- Revisa las Postulaciones (solicitudes de aliados) antes de aprobar un nuevo socio.
- Monitorea señales de fraude y sobrescribe decisiones.
- Atiende tickets de soporte al cliente.
- Configura las constantes de crédito (tasa de interés, tasa de seguro, fee de estudio).
El personal de Mi Plante inicia sesión a través del mismo portal de aliados que usan los aliados, pero con roles de administrador (administrador, administrador_comercial, administrador_financiero). Son usuarios del guard app, vinculados a la única Empresa MASTER.
En código: hay una fila especial de Empresa de tipo EmpresaType::MASTER que representa a Mi Plante en sí. La empresa Mi Plante sembrada en seeders recibe esa marca. Ver database/seeders/EmpresaSeeder.php.
3.4 EMCALI (la empresa de servicios públicos)
EMCALI es la empresa de servicios públicos municipal de Cali. Desde la perspectiva de Mi Plante, EMCALI provee dos cosas:
- Una API de consulta de membresía — dados la dirección de un cliente y dos números recientes de factura, confirmar que el cliente realmente vive ahí y es el titular de la cuenta. Esta es la puerta de entrada para la aprobación de crédito. Se invoca desde
App\Services\EmcaliMembresiaService. - Un canal de facturación — una vez que se genera una cuota, se adjunta a la próxima factura de EMCALI del cliente. El mecanismo operativo real de cómo las cuotas llegan a la factura de EMCALI no es totalmente visible en el repo hoy; lo que sí es visible es el camino de verificación de la membresía. El recaudo en sí es en gran medida un proceso externo/operativo.
3.5 Burós de crédito y socios de firma
El pipeline de decisión crediticia conversa con tres burós de crédito y un proveedor de firma digital. No memorices los endpoints; solo memoriza qué hace cada uno.
| Socio | Tipo | Para qué lo usa Mi Plante | Clase de servicio |
|---|---|---|---|
| TransUnion | Buró de crédito | Legal check (Fase 1): coincidencia de nombre, estado del documento (vigente/no vigente), listas legales | App\Services\LegalCheckService |
| Experian CrossCore | Identidad + crédito | Validación de identidad (Fases 2-5): “¿esta persona es quien dice ser?”, OTP, cuestionario basado en conocimiento | App\Services\IdentityValidationService |
| DataCrédito | Buró de crédito | Validación HDC (Fase 6): puntaje de historia crediticia | App\Services\DataCreditoService, App\Services\HDCValidationService |
| Certicámara | Firma digital | Firmar el pagaré digital (Pagaré) | App\Services\CerticamaraService |
| Core Crédito / SHIVAM | Core bancario interno | Registrar líneas de crédito en el sistema bancario de back-office | App\Services\CreditoService, App\Services\CoreCreditoService |
Cada uno está cableado vía config/services.php y las variables de entorno bajo EXPIRIAN_*, TRANSUNION_*, DATACREDITO_*, CERTICAMARA_*, CORE_CREDITO_*. Ver docs/audit/03-env-config-matrix.md para el inventario completo.
4. El recorrido del cliente
Este es el camino que recorre un cliente desde la primera visita hasta la primera cuota. Internalízalo — es lo que toca el 80% del producto.
Paso 0 — Descubrimiento
El cliente llega a miplante.com desde un canal de marketing (Google, Instagram, referido de un amigo). La página de inicio muestra:
- Productos destacados
- Categorías populares (shared prop
popular_categories) - Un CTA “Consultar Cupo” para que visitantes nuevos puedan previsualizar su línea de crédito
Rutas tocadas: GET /, GET /productos, GET /productos/{producto}, GET /marcas, GET /lineas. Todas públicas, sin auth requerida.
Paso 1 — Navegando
El cliente navega el marketplace sin una cuenta. Puede:
- Ver productos y precios
- Filtrar por categoría (
linea) y marca (marca) - Agregar ítems al wishlist (
lista-deseos) — funcionalidad limitada sin auth - Agregar ítems al carrito — funcionalidad limitada sin auth
Nota: un problema conocido es que carrito y lista-deseos están técnicamente registradas como rutas públicas pero operativamente fallan para invitados porque los controladores asumen un usuario autenticado. Esta es una de las trampas que te encontrarás más adelante (docs/onboarding/03-development-setup/03-common-gotchas.md).
Paso 2 — Registro
Cuando el cliente intenta hacer checkout, se topa con el muro: necesita una cuenta. El registro ocurre vía POST /register (flujo Laravel Breeze) creando filas de Persona + User.
En este punto el cliente tiene una cuenta pero aún no tiene fila de Cliente — y no tiene cupo. El “perfil crediticio” se crea cuando completa el paso de registro.
Paso 3 — Completar Registro
El cliente ahora es enrutado a GET /usuario/completar-registro. Envía:
- Dirección (
direccion,barrio,ciudad,departamento) - Dos números recientes de factura de EMCALI (
factura_numero_1,factura_numero_2)
Flujo de backend (App\Services\ClienteService + App\Services\EmcaliMembresiaService):
- Llamar la API de membresía de EMCALI con los datos del cliente
- Validar que las facturas coincidan con los últimos 6 meses para esa dirección
- Validar similitud de dirección (umbral por defecto 70%, configurable vía
app.porcentaje_minimo_similitud_direccion) - Consultar el estrato del cliente (estrato socioeconómico, 1-6) desde la respuesta de EMCALI
- Asignar un cupo inicial basado en estrato:
- E1: 2.5M COP
- E2: 3M COP
- E3: 3.5M COP
- E4-6: 4M COP
- Persistir
Cliente.cupo_asignado,Cliente.cupo_disponible,Cliente.registro_completado_en = now()
El cliente ahora tiene un perfil crediticio pero aún no ha sido aprobado para ninguna compra específica. El cupo es provisional. La aprobación completa ocurre la primera vez en el checkout.
Paso 4 — Agregar al carrito y hacer click en checkout
El cliente agrega productos al carrito (POST /carrito) y hace click en checkout (GET /checkout).
Se dispara el middleware:
auth— debe estar logueadocliente_registro_completo— debe haber completado el registroverificar_cliente_presenta_mora— no debe estar en mora (estado por defecto)
Si cualquiera de esos falla, el cliente es devuelto. De lo contrario aterriza en la pantalla de checkout.
Paso 5 — Aprobación crediticia (el pipeline de 7 pasos)
Este es el corazón del negocio. La primera vez que un cliente quiere comprar, pasa por el pipeline completo. Las compras posteriores pueden saltarse fases si el cliente ya tiene una aprobación reciente exitosa (la regla es >= 5 ProcessTypes con FINISH_SUCCESS en el mes actual — ver App\Services\AprobarCupoService).
El pipeline (docs/audit/12-credit-approval-workflow-diagram.md tiene el Mermaid completo):
| Fase | Qué ocurre | Llamada externa | Tiempo típico |
|---|---|---|---|
| 0 — Completar registro | Ya hecho arriba. Cupo asignado provisionalmente. | EMCALI | ~5 s |
| 1 — Legal check | Documento está vigente, nombre coincide, no hay listas legales | TransUnion | ~10 s |
| 2 — Validación de identidad | ”¿Es la misma persona?” chequeo básico | Experian | ~10 s |
| 3 — Generación de OTP | Enviar OTP vía email + SMS | Experian | ~5 s |
| 4 — Verificación de OTP | El cliente ingresa el código | Experian | depende del usuario |
| 5 — Preguntas de conocimiento | ”¿Cuál era tu dirección en 2019?” tipo | Experian | depende del usuario |
| 6 — Validación HDC | Obtener puntaje de historia crediticia | DataCrédito | ~15 s |
| 7 — Aprobación / extensión de cupo | Comparar puntaje, decidir monto final del cupo, opcionalmente extender | DataCrédito + EMCALI | ~5 s |
Tiempo total en el mundo real: alrededor de 5-7 minutos si el cliente responde rápido y todas las APIs externas responden.
Aplica un límite diario: un cliente solo puede intentar el pipeline 2 veces por día (middleware check_intentos_limite_diarios, cuenta los eventos LEGAL_CHECK / START en la tabla aprobar_cupo_eventos).
Paso 6 — Pagaré (pagaré digital)
Si la aprobación tiene éxito, el cliente necesita firmar un pagaré digital a través de Certicámara antes de que la compra se finalice. Este es el instrumento legal que le da a Mi Plante el derecho a cobrar.
Mecanismo:
App\Services\CerticamaraService::crearPagare()crea el pagaré del lado de Certicámara.- El cliente firma a través del flujo de Certicámara (típicamente enlace por email + verificación de identidad).
- Certicámara envía un webhook cuando la firma se completa.
- El webhook dispara
App\Jobs\ValidarPagareDigital→App\Jobs\ProcesarPagareDigital→App\Jobs\GenerarCreditoDeVenta.
Aquí también viven dos de los peores landmines del codebase (registrarEnCerticamara() siempre retorna false; las cuotas se pueden generar dos veces). Ver docs/onboarding/04-the-landmines/ para el desglose completo. Por ahora: cuando leas sobre el Pagaré en código, espera bugs.
Paso 7 — Cuotas adjuntas a la factura de EMCALI
Después de que el pagaré se firma y el crédito se genera:
- Se crea una fila
Venta(una por vendedor / Empresa) conestado = APROBADA. - Se crean filas
Cuota— una por cuota, confecha_vencimientoalineada a la facturación mensual de EMCALI. - La primera cuota incluye un monto_estudio_credito extra (fee de estudio de crédito).
- Cada cuota incluye capital + interés + seguro de vida (
seguro_vida). - La fianza/garantía (
fianza) se cobra solo en el primer cuarto de cuotas.
El cliente ahora ve estas cuotas como ítems de línea en su próxima factura de EMCALI. Paga la factura de EMCALI. EMCALI le envía el dinero a Mi Plante. Mi Plante le paga al aliado el monto original de la compra.
Paso 8 — Relación continua
Una vez que el cliente tiene un perfil crediticio activo, puede:
- Hacer compras adicionales contra el cupo disponible
- Aumentar su cupo (el flujo Extender Cupo en la Fase 7)
- Cancelar órdenes que no han sido entregadas (
OrdenCompra::estado = CANCELADA / RECHAZADA / ABANDONADA) - Ver su historial de cuotas
- Actualizar su teléfono, contraseña, perfil
Si cae en mora (cuotas vencidas), el middleware VerificarClientePresentaMora bloquea nuevas compras hasta que se ponga al día.
5. El recorrido del aliado
Menos superficie de producto que el lado del cliente, pero importante operativamente.
Paso A — Postulación
Un aliado potencial envía una Postulacion (solicitud). Diligencia:
- Nombre de la compañía, NIT, representante legal
- Direcciones de sucursales
- En qué líneas (categorías) quiere vender
- Información de contacto
En código: App\Models\PostulacionAliado, App\Services\PostulacionService. La solicitud se persiste, y operaciones de Mi Plante recibe una notificación (InformarDePostulacionCreada).
Paso B — Aprobación / rechazo por operaciones de Mi Plante
El personal de operaciones de Mi Plante revisa la postulación. Pueden:
- Aprobarla → dispara el evento
PostulacionDeAliadoAprobada→ envía un enlace firmado de invitación al postulante - Rechazarla / descartarla → dispara el evento
PostulacionDeAliadoRechazadaODescartada
Si se aprueba, el postulante recibe un email con URL firmada y registra su cuenta real de aliado en /aliados/postulacion/{postulacion}/registro. Un problema conocido: el GET está firmado pero el endpoint POST no lo está, lo que técnicamente permite que alguien evite la garantía del enlace firmado. Este es un hallazgo del doc-16, anotado por contexto.
Paso C — Carga de catálogo
Una vez registrado, el aliado carga su catálogo:
- Productos — productos
- Marcas — marcas (pueden ya existir; se pueden vincular)
- Líneas — categorías (elegidas del árbol global)
- Precios — variantes de precio por producto, con niveles de inventario
Existe una ruta de importación masiva vía Excel/CSV: App\Jobs\IniciarCargaMasivaProducto lee una hoja de cálculo a través de App\Services\SpreadSheetService y crea filas en batch. Se usa cuando un aliado migra desde un sistema existente.
Paso D — Configurar sucursales y empleados
El aliado configura:
- Sucursales — sucursales físicas con sus propias direcciones e inventario
- Empleados — usuarios en el guard
app, vinculados a una Sucursal, con acceso basado en roles (administrador,administrador_comercial,administrador_financiero,empleado)
Paso E — Recibir órdenes
Cuando un cliente compra a este aliado:
- Se crea una fila
Ventapara la sucursal del aliado (una Venta por vendedor por orden) - El aliado ve la venta en su portal en
/aliados/ventas - Procesa la entrega / fulfillment
- Marca la venta como
ENTREGADAcuando es entregada
La máquina de estados de Venta tiene estos estados (ver App\Enum\Facturacion\EstadoVenta):
PENDIENTE → APROBADA → ENTREGADA → LEGALIZADA → COMPLETADA
Más estados de salida: RECHAZADA, ABANDONADA, DEVUELTA.
Nota: la máquina de estados documentada y la máquina de estados real divergen en algunos puntos. LEGALIZADA, COMPLETADA, DEVUELTA existen como enums pero no tienen triggers explícitos en el código — se setean externamente / manualmente. El audit doc 08 cubre esto.
Paso F — Recibir pago
El aliado recibe pago de Mi Plante por el monto original de la compra de cada venta completada. Mi Plante absorbe el riesgo crediticio y se queda con el margen de interés/seguro/fee de estudio.
Advertencia honesta: el flujo de payout (cómo y cuándo los aliados realmente reciben dinero de Mi Plante) no es totalmente visible en este repo hoy. No hay pipeline de Venta → payout en el código. Lo tratamos como un proceso contable manual / externo y lo marcamos como una brecha por investigar. Ver docs/onboarding/01-business/03-the-money-flow.md para el desglose más profundo.
6. El modelo de ingresos de Mi Plante
Mi Plante gana dinero en cada venta a crédito a través de tres componentes, todos configurados como shared props de Inertia:
| Componente | Tipo | Valor por defecto | Dónde se configura |
|---|---|---|---|
Interés en cuotas (tasa_nominal) | Recurrente por cuota | 0.01914 (1.914% mensual) | env TASA_NOMINAL, expuesto vía middleware HandleInertiaRequests como credito.tasa_nominal |
Seguro de vida (seguro_vida) | Recurrente por cuota | 0.01 (1% del capital mensual) | env SEGURO_VIDA → credito.seguro_vida |
Fee de estudio de crédito (monto_estudio_credito) | Único, solo primera cuota | 25,000 COP | env MONTO_ESTUDIO_CREDITO → credito.monto_estudio_credito |
Fianza (porcentaje_fianza) | Primer cuarto de cuotas | configurable | env, expuesto vía credito.porcentaje_fianza |
Los números mostrados arriba son los defaults de .env.example. Producción puede usar números diferentes — no podemos ver los valores de env de producción. El punto es que todos están configurados por env y se renderizan a cada página vía HandleInertiaRequests::share().
Esto importa: cuando cambias TASA_NOMINAL en .env, debes correr php artisan config:clear y el cambio afectará cada nueva venta creada desde ese punto en adelante. Las cuotas existentes (ya creadas) no se recalculan retroactivamente.
Implicación para el costo del crédito: una compra de 1.000.000 COP a 12 cuotas con los defaults generaría aproximadamente 1.128.500 COP de pagos totales por parte del cliente — alrededor del 12.8% all-in sobre 12 meses (cálculo aproximado, ver 03-the-money-flow.md para el cálculo preciso).
7. Por qué la aprobación crediticia es el flujo central
Si solo entiendes profundamente una parte del sistema, que sea el pipeline de aprobación crediticia.
Razones:
- Las unit economics dependen de él. Malas decisiones crediticias → defaults → pérdida. Las cuotas son principalmente repago de capital, así que un préstamo defaulteado se come años de margen.
- Toca a cada socio externo. TransUnion, Experian (×4 endpoints en 4 fases), DataCrédito, EMCALI. Si entiendes el pipeline, entiendes el 80% del mapa de integraciones.
- Es el camino más lento. Los clientes pasan la mayor parte del tiempo aquí. Las ganancias y pérdidas de UX son más grandes aquí.
- Es donde viven los landmines. Límite diario, umbrales de puntaje, enforcement de OTP, idempotencia. Los bugs encontrados en el audit doc 16 se concentran en esta área.
- Es donde vive el compliance. Habeas Data (Ley 1581 + 1266), retención de datos, KYC. La PII fluye por aquí.
Lee docs/audit/12-credit-approval-workflow-diagram.md de cabo a rabo, luego traza una fase end-to-end en el código (punto de partida sugerido: App\Services\LegalCheckService para la fase más simple, luego App\Services\IdentityValidationService para la más larga).
8. Por qué el codebase está en español
Los conceptos de dominio están en español; el boilerplate del framework está en inglés. Esto es intencional, no descuidado.
Ejemplos que verás:
| Español (dominio) | Inglés (framework) |
|---|---|
Cliente, Empresa, Sucursal, Empleado | Service, Controller, DTO, Request |
Venta, Cuota, Pagare, Cupo | Model, Migration, Seeder, Job |
creado_en, actualizado_en, aprobado_en | created_at (solo en tablas del framework), updated_at |
aprobar_cupo_eventos, lista_deseos | permissions, roles (Spatie) |
Rutas: /usuario/cupo/legal-check, /aliados/ventas, /mis-compras | n/a — las rutas siguen el dominio |
Por qué español para el dominio:
- Los usuarios hablan español. Aliados, clientes y personal de soporte operan en español. Mantener los nombres de campos en español reduce bugs de traducción (e.g. nunca tienes que mapear
cliente_idacustomer_iden una consulta). - La terminología legal y financiera está en español. Pagaré, fianza, seguro de vida, mora, cupo, cuota — estos tienen significados legales específicos en el comercio colombiano. Las aproximaciones en inglés (“promissory note”, “bond”, “credit line”) pierden matices.
- Reduce la traducción entre PRD y código. Operaciones escribe specs en español usando términos de dominio. Los ingenieros codifican en los mismos términos. No se necesita traducción de glosario.
Regla de estilo para código nuevo:
- Nuevos modelos de dominio / migraciones / rutas / variables / controllers: español.
- Nuevo código de framework: inglés. Clases de servicio, jobs, factories, providers.
- Casos bilingües: comentarios, mensajes de excepción, tests. El inglés está bien para comentarios técnicos; las cadenas hacia el usuario van a localización.
- Existe un
docs/audit/15-glossary.mdsi olvidas qué significa un término.
9. El estado actual de Mi Plante
Lee esto con cuidado porque define qué puedes romper.
- Marketplace en producción. Clientes vivos, ventas vivas, cuotas vivas. El sistema procesa dinero real.
- En un programa de estabilización. Una nueva funcionalidad (financiamiento parcial de crédito — permitir que los clientes dividan una compra entre crédito y efectivo para ítems de mayor valor) se está agregando en paralelo con bug fixes.
- Sin monitoreo externo. No hay Sentry, no hay APM. El equipo se entera de bugs por tickets de soporte al cliente. Acostúmbrate a depender de logs y del log-viewer in-app en
/aliados/log-viewer. - Los tests cubren solo backend. ~47 feature tests en PHPUnit. Cero tests de frontend. Vitest está en
package.jsonpero no está configurado. - Una sola base de datos, sin read replica. MySQL guarda datos de negocio, sesiones, cache, jobs de cola, logs de negocio custom, logs de error de frontend. Un único punto de falla.
- Sin Dockerfile, sin CI/CD de deploy. El despliegue es lo que el equipo anterior hizo manualmente. No conocemos la topología de producción solo desde el repo.
Esto no es inusual para una fintech que escaló de cero a product-market-fit con un equipo pequeño. Es también por qué auditamos antes de desplegar funcionalidades.
Tu postura por defecto en el día 1: sé cuidadoso con prod. Lee antes de escribir. Ante la duda, pregunta a tu tech lead.
10. Lo que Mi Plante NO es
Comparaciones útiles para anclar tu modelo mental, con las diferencias afinadas.
No es un banco
- Mi Plante no recibe depósitos de clientes.
- Mi Plante no es una institución financiera regulada en el sentido bancario.
- Mi Plante es una fintech que origina crédito y recauda vía EMCALI, pero el dinero prestado viene del balance propio de Mi Plante (y presumiblemente futuro capital externo).
No es una tarjeta de crédito
- No hay tarjeta.
- No es parte de los rails de Visa/Mastercard.
- El cupo no es rotativo en el sentido de tarjeta de crédito — cada compra genera un cronograma de cuotas de plazo fijo que tiene que pagarse. No hay opción de “pago mínimo”.
No es Klarna / Afterpay
- Klarna es BNPL post-compra: el cliente va a un comerciante normal, elige Klarna en el checkout, Klarna le paga al comerciante, el cliente le paga a Klarna después. Klarna hace decisión de riesgo muy rápida en el checkout, frecuentemente sin consulta a buró de crédito.
- Mi Plante es aprobación crediticia pre-compra con integración de marketplace: el cliente entra al propio marketplace de Mi Plante, pasa por un pipeline multi-paso de aprobación crediticia con consultas a burós, firma un pagaré legal, y solo entonces puede comprar. La relación crediticia es duradera a través de compras vía el cupo, no por transacción.
No es MercadoLibre / Amazon
- MercadoLibre es un marketplace; los vendedores manejan su propio crédito y pagos (vía MercadoPago, pero la decisión crediticia no es propia de MercadoLibre per se).
- Mi Plante es dueño de la decisión crediticia y es dueño del rail de recaudo. El marketplace es el vehículo para el crédito, no al revés. Si quitas el pipeline de crédito, Mi Plante es solo un pequeño sitio de e-commerce.
No es “BNPL para todo”
- El crédito de Mi Plante está atado a bienes durables específicos (electrodomésticos, motos, computadores, salud, educación, viajes, hogar, etc.). El árbol de Líneas (
database/seeders/LineaSeeder.php) define qué es elegible y los plazos mínimo/máximo de cuotas por categoría. - Por ejemplo: las máquinas de coser permiten 11-60 cuotas. Los cursos de educación de corto plazo permiten 6-12. Las motos permiten hasta 72. Cada línea tiene un
plazo_minimoy unplazo_maximo.
11. Orden de lectura desde aquí
Has terminado el primer documento del Día 1. Sigue:
docs/onboarding/01-business/02-who-are-the-users.md— los personas. Clientes y aliados colombianos reales y personal de Mi Plante. Lee esto para tener empatía cuando veas un ticket de bug.docs/onboarding/01-business/03-the-money-flow.md— sigue un peso desde el bolsillo del cliente hasta el payout al aliado. Diagramas incluidos.docs/onboarding/02-codebase-tour/— el recorrido del codebase (Día 1 tarde).docs/onboarding/03-development-setup/— pon la app a correr localmente (Día 2 mañana).docs/onboarding/04-the-landmines/— los bugs que te encontrarás en la semana 1.docs/audit/— la auditoría canónica. Úsala como referencia, no como tutorial. Los 16 documentos ahí son la fuente de verdad para lo que el sistema realmente hace.
Si un compañero alguna vez describe el producto distinto de lo que está en este documento, confía en el código, pero pregunta por qué la descripción difiere. A veces la diferencia es intención del producto vs. comportamiento real. A veces es un bug. Cualquiera de los dos vale la pena saberlo.
Bienvenido a Mi Plante.