Edwin Trigos — Software Architect & Full Stack Developer
Software Architect and Full Stack Developer with 5+ years building production systems in .NET, Clean Architecture, fintech, and cloud infrastructure. Based in Bucaramanga, Colombia. Remote-ready.
About
I design and build production-grade systems end-to-end: from clean architecture foundations to cloud deployment. My current focus is on financial systems (loan origination, credit bureaus, risk management) and B2B SaaS platforms. I write detailed case studies documenting the real architecture decisions, metrics, and tradeoffs from systems I've shipped.
Production Case Studies
Sistema de Originación de Crédito (LOS) — Fábricas de Crédito QUAC
Problem: La empresa no contaba con un sistema digital de originación de crédito. Las solicitudes se procesaban de forma manual, tomando días en completarse, sin validación de identidad ni detección de fraude. Cada solicitud requería revisión humana sin automatización, generando demoras, errores de conciliación y exposición a suplantación de identidad.
Solution: Diseñé y construí el sistema completo desde cero. En la capa de datos: DDL con 4 esquemas lógicos (cfg/cat/fab/aud), 30+ tablas transaccionales, máquina de estados de 23 estados, y 27 stored procedures optimizados. En la capa de servicios: API REST en .NET con Clean Architecture — repositorios por esquema, servicios por dominio funcional (Estudio, Tercero, OTP, Biometría) y controladores por canal (Admin/Tienda/Web/Handoff). Implementé el SOVI (Sistema Orquestador de Validación de Identidad) con patrón Strategy para verificación por bot de voz + validación manual, con motor de decisiones catalog-driven (sin if/switch hardcodeados). Integré detección de fraude con análisis biométrico de fotografías y un flujo completo de auditoría INSERT-ONLY.
Impact: 114+ endpoints API en 6 capas BFF (Admin/Core/Tienda/Web/Handoff/Util). 27 stored procedures en producción. 23 estados de ciclo de vida de crédito con trazabilidad completa. Verificación de identidad automatizada vía bot de voz con plan B manual como ciudadano de primera clase. Auditoría inmutable de todas las operaciones.
SOVI — Sistema Orquestador de Validación de Identidad
Problem: El sistema de originación de crédito (LOS) requería validar la identidad del cliente en tiempo real mientras estaba activo en el flujo de solicitud. Sin esta validación, el riesgo de suplantación de identidad era crítico. Necesitaba un sistema que funcionara tanto automatizado (bot de voz) como con respaldo manual, con trazabilidad completa de cada intento.
Solution: Diseñé el SOVI con tres tablas especializadas (catálogo de diagnósticos, campañas por estudio, intentos con biometría). Implementé el patrón Strategy con dos estrategias: BotValidacionStrategy (automático vía bot de voz) y ManualValidacionStrategy (asesor humano como plan B). El motor de decisiones no tiene if/switch hardcodeados — cada diagnóstico del bot dispara una AccionSistema desde el catálogo en base de datos. Cada intento registra timestamps, URL de audio y datos biométricos para auditoría completa.
Impact: Validación de identidad en tiempo real sin intervención humana en el flujo estándar. Plan B manual como ciudadano de primera clase (no un fallback after-thought). Motor de decisiones catalog-driven: agregar nuevos diagnósticos no requiere cambios de código. Trazabilidad completa por estudio con 10+ diagnósticos de bot categorizados.
API de Integración con Burós de Crédito — Datacredito
Problem: El proceso de consulta a centrales de riesgo (Datacredito) requería integración manual con formatos legacy. Las consultas tardaban más de 3 segundos en promedio por falta de índices optimizados, las credenciales de cada servicio estaban hardcodeadas en código y archivos de configuración dispersos, y cuando una consulta fallaba no había forma de saber si el problema era del proveedor, de la red, o de los datos de entrada. Sin trazabilidad: cero registro de respuestas, cero auditoría de fallos, cero posibilidad de reproducir un error reportado por un usuario.
Solution: Construí una API REST en .NET 8 con Dapper + SQL Server. Para la resiliencia: Polly con circuit breaker (separa fallos del proveedor del resto del sistema) + retry policy exponencial. Para las credenciales: diseñé un patrón de CredentialFactory con interfaz ICredentialProvider (las credenciales se consultan desde base de datos, no del código), con caché por servicio y expiración automática — agregar un nuevo proveedor es una fila en una tabla, no un cambio de código. Para la trazabilidad: middleware de request/response logging con sanitización de campos sensibles (números de documento, claves), Serilog con tres pipelines (consola + archivo + base de datos), y el patrón always-register que persiste el resultado de cada consulta con su campo FueExitoso tanto en éxito como en fallo. Arquitectura en 3 capas (Web/Data/Common) con inyección de dependencias, optimización de índices en las tablas de historial, y procedimientos almacenados específicos por cada uno de los 5 servicios del proveedor (Preselecta, CrossCore, Historia, Evidente, Reconocer).
Impact: Reducción drástica de tiempos de consulta (de 3+ segundos a sub-segundo) mediante índices optimizados y caché de credenciales. CredentialFactory centralizado: cero duplicación de claves, agregar un nuevo proveedor sin desplegar código. Resiliencia operativa: circuit breaker aísla fallos del proveedor sin afectar otras integraciones. Trazabilidad completa: cada consulta queda registrada con su respuesta real del proveedor — cuando un analista reporta un fallo, se reproduce en segundos abriendo la tabla de auditoría. Patrón always-register: FueExitoso=true/false para todos los servicios, sin excepciones. Arquitectura preparada para migración a .NET 10 sin cambios estructurales.
Sistema de Nómina — Generación de Documentos para Franquicias
Problem: El ERP manejaba 45+ tipos de nómina (contratos, terminaciones, cartas) con rutas de documentos estáticas. Una cadena de franquicias de tiendas de ropa requería 3 nuevos tipos de nómina (Comercial, Administrativa, Temporada) con sus propias plantillas Crystal Reports, pero el sistema existente usaba rutas compartidas que no permitían personalización por tipo.
Solution: Extendí el sistema de enrutamiento de documentos del CRM para soportar los 3 nuevos tipos de nómina de la cadena de franquicias. Modifiqué el controlador para actualizar la lógica de enrutamiento dinámico: añadí los IDs 46/47/48 al array de nóminas por cuotas, agregué casos específicos en el método de resolución de nombres, y creé 21 archivos .rpt (7 por nómina) en una nueva carpeta dedicada. Todo siguiendo el patrón existente sin afectar las 45+ nóminas legacy.
Impact: Extensión no-invasiva: 0 breaks en nóminas legacy. 21 plantillas Crystal Reports organizadas por tipo de nómina. Patrón reusable para futuros tipos de contrato. Sistema de enrutamiento dinámico probado con 48 tipos de nómina.
Problem: La API V2 del sistema de originación de crédito tenía dominios backend bien estructurados (AUD, CAT, CFG, FAB), pero la interfaz de administración no reflejaba esta separación. El monitoreo en tiempo real (auditoría, colas de crédito) estaba mezclado con la configuración CRUD (catálogos, reglas de negocio), creando una experiencia confusa para el operador.
Solution: Diseñé la reestructuración del módulo Admin en dos macro-módulos: "Panel de Control" (dashboard de monitoreo consumiendo endpoints AUD + FAB read-only) y "Módulo Administrar" (interfaz tipo navegador con tabs: Catálogos/CAT, Workflow/CFG, Operación/FAB). Mapeé cada área del backend a su macro-módulo correspondiente, delegando la gestión de roles/permisos a la aplicación host. La navegación refleja la arquitectura limpia del backend.
Impact: Separación clara de responsabilidades UI (monitoreo vs. configuración). Arquitectura escalable: agregar nuevas capacidades solo requiere crear un nuevo tab en el macro-módulo correspondiente. Sin duplicación de lógica de permisos. Consistencia con la arquitectura limpia del backend.
Portfolio con Arquitectura Híbrida (React 19 + Vite)
Problem: Los portfolios de desarrolladores muestran código pero no el impacto de negocio. Depender exclusivamente de la API de GitHub para mostrar proyectos oculta el trabajo más valioso: sistemas privados empresariales bajo NDA. Necesitaba una plataforma que vendiera ingeniería, no solo repositorios públicos.
Solution: Diseñé una arquitectura híbrida: capa de contenido curado (casos de estudio en TypeScript con formato STAR, experiencia laboral, blog) como fuente principal de verdad, y API de GitHub como widget secundario de actividad. Implementé i18n nativo (ES/EN), design system editorial pixel-art con sombras pixeladas y tipografía de periódico, y animaciones con Framer Motion. Construido con React 19 + Vite + TypeScript + Tailwind CSS v4.
Impact: Arquitectura que prioriza el impacto de negocio sobre el código fuente. Casos de estudio con NDA sin exponer información confidencial. i18n nativo sin librerías externas. Design system propio que diferencia visualmente de portfolios genéricos. Agregar un caso de estudio = 1 objeto TypeScript.
API Centralizada de Comunicaciones por Email — Infobip como Proveedor Único
Problem: La empresa operaba con 5 silos independientes de envío de emails: cada sistema (ERP, CRM, portal de proveedores, sistema de originación de crédito, portal de empleados) llamaba directo al proveedor con sus propias credenciales, su propia lógica de retry, y su propio formato. Cuando un email no llegaba, el tiempo medio de diagnóstico era de 30 minutos — había que revisar logs en 5 servidores distintos, identificar cuál de los 8 buzones falló, y reconstruir la petición a mano. Los nombres de stored procedures internos (prefijo sp_ interno) filtraban contexto de negocio en logs compartidos con proveedores externos, comprometiendo la separación de responsabilidades. Cero trazabilidad cross-system: no se podía responder "¿cuántos emails se enviaron a proveedores en las últimas 24 horas?" sin escribir una query nueva cada vez.
Solution: Diseñé una API REST unificadora en .NET 8 con Clean Architecture estricta en 4 capas (Api / Application / Domain / Infrastructure). En la capa de Dominio definí la interfaz IEmailProvider con un único método EnviarCorreoConAdjuntosAsync, abstracta sobre cualquier proveedor. En la capa de Application implementé el EmailService que orquesta: validación, plantillas por contexto, persistencia de la transacción con GUID propio antes de llamar al proveedor, y reintento exponencial. En Infrastructure implementé el adaptador InfobipProvider con HttpClient tipado y Polly para circuit breaker. Las 8 cuentas multi-tenant se configuran en appsettings.json con nombres genéricos por contexto de negocio (no por sistema origen), permitiendo ruteo por contexto sin hardcodear. Cada transacción de email se persiste con un GUID como identidad propia — el nuestro, no el del proveedor — trazable desde el log de aplicación hasta la respuesta HTTP. Serilog con 3 pipelines (consola + archivo rotativo + tabla de auditoría en BD) con sanitización de adjuntos, PII y credenciales. Implementé el patrón de plantilla-por-contexto: cada tipo de email (notificación a proveedor, recordatorio a cliente, alerta interna) tiene su template con tokens tipados en lugar de string interpolation, eliminando errores de placeholder.
Impact: Tiempo medio de diagnóstico de email no entregado: de 30 minutos a 5 segundos (búsqueda por GUID en la tabla de auditoría). Cero credenciales hardcodeadas: las 8 cuentas viven en BD con encriptación, rotables sin redeploy. Cambio de proveedor de email: de "reescribir 5 integraciones" a "implementar un nuevo IEmailProvider" — medido en horas, no semanas. Cero emails huérfanos: cada transacción tiene estado persistido antes de llamar al proveedor, no se pierde traceability si el request falla a mitad de camino. Logs de proveedor compartidos sin filtrar contexto de negocio: nombres de sp_ internos ofuscados, prefijos de negocio en mensajes de log removidos. 7 controladores REST (uno por canal de consumo: admin, suppliers, employees, batch, webhooks, monitoring, admin-tools) consumiendo el mismo servicio de aplicación — cero duplicación de lógica entre canales.
Harmony-Music — Mantenedor de App Flutter Open Source de Música Multiplataforma
Problem: El creador original marcó el repositorio como "no mantenido" en diciembre 2025, dejando una app Flutter cross-platform (Android, Windows, Linux) con dependencias abandonadas (ionicons roto con Dart 3.12), flags de migrador de Gradle sin limpiar, código que crasheaba en runtime (RangeError por indexWhere devolviendo -1), y sin herramientas de debugging. La app usaba una API no documentada (InnerTube de YouTube Music) que cambiaba sin aviso, rompiendo búsquedas y bucketing de resultados.
Solution: Apliqué una metodología de triage en 4 fases: (1) Build primero — Gradle 8.14, AGP 8.11.1, Kotlin 2.2.20 con DSL moderno, removí flags del migrador, migré a Flutter built-in Kotlin. (2) Deprecaciones — 19 commits reemplazando withOpacity por withValues(alpha:), Color.value por toARGB32(), ThemeData getters por colorScheme, removí ionicons. (3) Runtime — reescribí el bucketing de búsqueda para responder al nuevo formato plano de InnerTube (24/25 resultados caían en buckets huérfanos), agregué guardas de indexWhere, mejoré el logging estructurado de HTTP. (4) Tooling — construí un ResponseRecorder que captura respuestas crudas a disco y un logger con colores ANSI para inspeccionar cambios de API offline. La arquitectura de audio usa just_audio + media_kit + audio_service + SMTC para cubrir 3 plataformas con una sola API Dart.
Impact: ~36 commits en 3 días que llevaron la app de "no compila" a "release v1.12.2" con toolchain moderno. Búsqueda funcional con nuevo formato de InnerTube (clasificación por pageType, top 10 por bucket). Build limpio con Flutter 3.44+. Audio funcional en 3 plataformas con engines separados pero API unificada. Documentación completa (setup, contributing, API surface map, Postman collection). App mantenida activamente en GitHub con releases y changelog.
STARSOL — Plataforma SaaS para Gestión Integral de Riesgos
Problem: Las entidades del sector solidario (cooperativas, fondos de empleados) enfrentaban procesos manuales para la gestión de riesgos SARLAFT, SARC y SIAR, con flujos de originación de crédito y monitoreo normativo sin digitalizar. El servidor web monolítico se convertía en cuello de botella al procesar archivos financieros pesados de forma sincrónica, degradando la experiencia del usuario.
Solution: Diseñé y construí STARSOL desde cero como plataforma SaaS B2B en PHP con Laravel, implementando una arquitectura asíncrona con 3 background workers que procesan jobs simultáneamente, desacoplando completamente la carga de archivos del hilo principal del servidor web. Para la gestión avanzada de archivos, desarrollé una aplicación cliente en .NET MAUI con capacidad offline que se sincroniza con el backend en la nube. A nivel de infraestructura, aprovisioné entornos de alta disponibilidad en AWS con prácticas CI/CD, garantizando escalabilidad para el procesamiento de datos financieros sensibles.
Impact: Arquitectura asíncrona que eliminó cuellos de botella del servidor web mediante 3 workers simultáneos. Aplicación cliente .NET MAUI con sincronización offline para gestión de archivos financieros. Infraestructura cloud en AWS con alta disponibilidad y CI/CD. Plataforma SaaS B2B completa para el sector solidario cubriendo SARLAFT, SARC y SIAR.
Technical Blog
Clean Architecture en un Sistema de Originación de Crédito: Cómo evité el caos antes de escribir la primera línea de código
Cuando te dan un proyecto desde cero, la tentación es abrir Visual Studio y empezar a escribir controladores. Pero sin una estructura clara, en 3 meses tienes un Big Ball of Mud. Así diseñé la arquitectura del LOS antes de escribir una línea de código de producción.
Eliminé todos los if/switch de mi motor de decisiones (y por qué deberías hacer lo mismo)
Cuando construyes un sistema que toma decisiones basadas en diagnósticos externos (un bot de voz, un servicio de validación), la tentación es escribir switch(mensaje) { case "ERROR": ... }. Eso es deuda técnica inmediata. Te cuento cómo lo evité con un motor catalog-driven.
Centralicé todos los correos de la empresa en una API con Clean Architecture (y dejé de preguntarle al proveedor qué pasó)
Cada área de la empresa gestionaba el correo por su cuenta, con su propia implementación, su propia clave API, y su propia definición de "éxito". Hasta que el proveedor decía "no me llegó el comprobante" y nadie sabía qué pasó. Así diseñé una API centralizada que eliminó el black box de las comunicaciones empresariales.
Diseñé un ERP donde la capa de presentación (Blazor) y la REST API son intercambiables gracias a Clean Architecture
Cómo logré que Blazor y la API compartieran exactamente la misma lógica de negocio en un ERP de producción mediante inyección de dependencias en Clean Architecture, eliminando duplicación y acelerando el desarrollo de características.
Todo el error handling de mi API se reduce a dos archivos: así eliminé los try-catch de mis controladores
. Category: arquitectura. Tags: arquitectura, .NET, ASP.NET Core, patrones, C#.
Cada controller tenía su propio try-catch, cada error devolvía un formato distinto, y los mensajes mezclaban detalles técnicos con reglas de negocio. Unificarlo todo en dos archivos — DomainExceptions.cs + ExceptionHandlingMiddleware — cambió la forma en que pensamos los errores.
No uso Entity Framework. En 3 años de ERP, cero migraciones, cero N+1, cero sorpresas en producción
Cada vez que alguien dice "usa EF Core, es el estándar", me pregunto si su base de datos tiene 200 stored procedures legacy y un equipo de DBA. Te cuento por qué elegimos Dapper puro y cómo vivimos para contarlo.
Versioné 24 controladores de una API en producción sin cambiar ni una sola URL existente
. Category: arquitectura. Tags: API, arquitectura, .NET, ASP.NET Core, patrones.
Cuando 24 controladores están en producción y los clientes no pueden actualizarse todos al mismo tiempo, romper URLs no es una opción. Así implementé versionado transparente con rutas duales sin que ningún consumidor legacy se enterara.
Una orden de trabajo recorre 3 sistemas sin que ninguno se acople al otro: el orquestador es un método, no un microservicio
Cuando una orden de producción necesita notificar por email, guardar PDFs en la nube y actualizar el estado en otro sistema, la tentación es crear un orquestador. Pero a veces el orquestador correcto es un método de 30 líneas.
Lo que realmente heredas al hacer un fork de un proyecto Flutter "no mantenido"
Un repo "no mantenido" no significa "no compila". Significa: paquetes abandonados, flags de migrador olvidados, código que crashea en runtime con -1 fuera de rango, y cero herramientas de debugging. Cuando forké Harmony-Music en junio 2026, ese fue el estado real. Acá está la metodología de triage en 4 fases que usé para llevarlo de "no compila" a release v1.12.2.
Audio multiplataforma en Flutter: dos engines, una API, tres plataformas
No existe un solo engine de audio en Flutter que cubra Android, Windows y Linux con la misma calidad. La solución no es elegir uno: es componer. just_audio como API unificada, media_kit como backend en desktop, audio_service para lifecycle y notificación, SMTC para media keys en Windows. Acá está la arquitectura real, los offsets platform-specific, y los bugs que solo aparecen en desktop.
Cuando tu app depende de una API que no controlas: reverse-engineering YouTube Music
Harmony-Music no usa la API oficial de YouTube. Usa InnerTube, la API interna que YouTube Music expone a su propia web app, reverse-engineered desde hace años. Cuando YouTube cambia el formato de respuesta (sin changelog, sin docs, sin warning), 24 de 25 resultados de búsqueda caen en buckets huérfanos. Acá está la historia de reescribir el bucketing, clasificar por pageType, y construir un ResponseRecorder para diff offline.
El precio de la modernización: actualizar un proyecto Flutter abandonado a Flutter 3.5+
Actualizar un proyecto Flutter que estuvo 6 meses sin mantenimiento no es un bump de versión. Es una cadena acoplada: SDK de Flutter, AGP, Gradle, Kotlin, plugins, deprecaciones de Dart, deprecaciones de Material, paquetes abandonados. Cuando forké Harmony-Music, el "upgrade tax" fue 19 commits separados. Acá está el orden correcto, los commits que rompieron todo, y la métrica que nadie te dice sobre migrar.
Audio en background en Android 14+ cuando heredaste código de Android 9
Una app de música que heredaste con código de Android 9 tiene tres problemas para correr en Android 14+: scoped storage mató Permission.storage, foreground service types son estrictos, y cualquier API nativa (como el equalizer) necesita un bridge JNI porque no hay package Dart. Acá está la solución completa: SDK-version-aware permissions, JNI para Equalizer, y la config de audio_service que mantiene la música viva en background.
BOT Ubica + Prueba de Vida: cómo validé identidad biométrica en tiempo real con fallback humano y catálogo de diagnósticos
En un sistema de originación de crédito, validar identidad no es solo confirmar un número de documento. Es probar que la persona está viva, está en el lugar que dice estar, y no es un deepfake. Acá está cómo diseñé BOT Ubica (bot de voz + geolocalización) más Prueba de Vida V2 (liveness detection con OAuth) más un motor de decisiones catalog-driven con 9 códigos de diagnóstico, fallback manual como ciudadano de primera clase, y un selector de buró de crédito configurable sin redeploy.
Mantenedor Open Source (Fork) & Desarrollador Flutter — Harmony-Music
Period: Jun 2026 – Presente. Location: Colombia (Remoto). Current.
Tomé el mantenimiento del fork de Harmony-Music (app Flutter de música streaming para Android, Windows y Linux) tras el abandono del creador original en diciembre 2025, aplicando una metodología de triage en 4 fases que llevó la app de "no compila" a release v1.12.2 con toolchain moderno
Modernicé el stack de build completo — Gradle 8.14, AGP 8.11.1, Kotlin 2.2.20 con DSL moderno — removiendo flags residuales del Flutter migrator y migrando al Kotlin built-in de Flutter para preparar la app para Flutter 3.5+
Resolví 19 olas de deprecaciones de Flutter 3.4x+ (withOpacity→withValues, Color.value→toARGB32, ThemeData getters→colorScheme, ionicons→Material Icons) en 19 commits separados, demostrando capacidad de ejecutar auditorías de código a gran escala
Reescribí el bucketing de búsqueda de YouTube Music cuando InnerTube cambió su formato de respuesta (24/25 resultados caían en buckets huérfanos), implementando clasificación por pageType con límite de 10 por bucket y construyendo un ResponseRecorder para diff de respuestas crudas
Arquitecto de Software Cloud & Desarrollador Independiente — STARSOL
Period: Ene 2024 – Presente. Location: Colombia (Remoto). Current.
Lideré el diseño arquitectónico, desarrollo end-to-end y despliegue en la nube de STARSOL, una plataforma SaaS B2B para el sector solidario que gestiona el Sistema Integral de Administración de Riesgos (SARLAFT, SARC, SIAR), digitalizando y automatizando flujos complejos de originación de crédito y monitoreo normativo
Diseñé una arquitectura asíncrona con 3 background workers procesando jobs simultáneamente para desacoplar tareas pesadas del hilo principal del servidor web (PHP/Laravel), eliminando cuellos de botella en el procesamiento de archivos financieros
Orquesté el aprovisionamiento de entornos de alta disponibilidad en AWS con prácticas CI/CD, garantizando escalabilidad y seguridad para el procesamiento de datos financieros sensibles
Construí desde cero el Sistema de Originación de Crédito (LOS) con Clean Architecture en .NET 8 — DDL con 30+ tablas y 4 esquemas lógicos, 27 stored procedures, API REST con 114+ endpoints organizados en 6 capas BFF sin duplicación de lógica entre canales
Diseñé el SOVI (Sistema Orquestador de Validación de Identidad) con patrón Strategy para verificación por bot de voz + respaldo manual, implementando un motor de decisiones catalog-driven que eliminó todo if/switch hardcodeado del flujo de validación
Implementé la API de integración con burós de crédito (Datacredito) en .NET 8 con patrones de resiliencia (Polly circuit breaker + retry policy), autenticación JWT y logging estructurado con Serilog, reduciendo tiempos de consulta de 3s a 400ms mediante optimización de índices y queries
Lideré la migración forzada de la aplicación móvil empresarial de Xamarin Forms a Flutter tras la depreciación de Xamarin por Microsoft, restaurando la disponibilidad en App Store y dotando al proyecto de un stack móvil moderno, fluido y mantenible
Desarrollé y mantuve integraciones con APIs de terceros (burós de crédito CIFIN, pasarelas de pago, servicios de mensajería Infobip) procesando miles de transacciones diarias
Implementé APIs REST en .NET con Dapper y SQL Server, optimizando consultas mediante índices y caching que redujeron tiempos de respuesta de 3s a 400ms
Construí sistemas de reportes automatizados con Crystal Reports integrados al ERP, eliminando horas de trabajo manual del equipo de análisis
Participé en la migración de aplicaciones .NET Framework a .NET Core, aplicando inyección de dependencias y patrones modernos de arquitectura
Desarrollador Full Stack .NET — Cliente — Franquicias de Ropa
Period: 2025 – 2026. Location: Colombia (Remoto).
Extendí el sistema de enrutamiento de documentos del CRM corporativo para soportar 3 nuevos tipos de nómina (Comercial, Administrativa, Temporada) para una cadena de franquicias de tiendas de ropa, agregando IDs y casos específicos sin afectar los 45+ tipos legacy existentes
Diseñé e implementé 21 plantillas Crystal Reports (7 por tipo de nómina) organizadas en una estructura de carpetas dedicada, siguiendo el patrón del sistema existente para mantener consistencia
Implementé enrutamiento dinámico de documentos modificando la lógica de generación de contratos, cartas y terminaciones, logrando una extensión no-invasiva sin regressiones en la operación existente
Desarrollador Full Stack (.NET & JavaScript) — CAMPUSLANDS
Period: Feb 2023 – Ene 2024. Location: Colombia.
Desarrollé una solución de software integral bajo metodología ágil Scrum para la gestión operativa de un modelo logístico
Diseñé un backend altamente escalable en .NET fundamentado en principios SOLID con Fluent API para mapeo de datos
Orquesté el diseño, normalización y administración de la base de datos relacional en MySQL
Consumí los servicios backend a través de un frontend dinámico e interactivo construido con JavaScript, asegurando calidad y mantenibilidad del código a largo plazo
Fui responsable del desarrollo end-to-end de la plataforma web comercial, gestionando todo el ciclo de vida del producto: desde la toma de requerimientos y diseño de interfaces (UI/UX) mediante mockups, hasta la implementación técnica utilizando PHP, JavaScript, HTML y CSS
Ejecuté la integración de la lógica de negocio, la optimización de contenidos y el despliegue automatizado en servidores de producción, garantizando la estabilidad del sitio
Ingeniería en Desarrollo de Sistemas — Unidades Tecnológicas de Santander (UTS)
Period: 2024 – Presente
Formación en ingeniería de software, arquitectura de sistemas, bases de datos avanzadas y gestión de proyectos tecnológicos.
Tecnología en Sistemas — Unidades Tecnológicas de Santander (UTS)
Period: 2024 – 2026
Tecnología en Análisis y Desarrollo de Sistemas de Información (ADSI) — SENA — Centro de Producción Limpia (LOPE), Nariño
Period: 2022 – 2024
Entrenamiento Intensivo en Desarrollo de Software (Bootcamp) — Campuslands
Period: 2023 – 2024
Bootcamp de 10 meses con formación intensiva en .NET, Java, Spring Boot, SQL, arquitectura limpia y metodologías ágiles.
Testimonials
Trabajar con Edwin en el diseño y construcción de nuestra plataforma de créditos fue una experiencia transformadora. No solo entendió el negocio desde el día uno, sino que diseñó una arquitectura que nos permite escalar sin miedo a romper lo que ya funciona. Su enfoque en la trazabilidad y la auditoría nos dio la confianza que necesitábamos para operar en un sector tan regulado como el financiero.
— Cliente — Fábricas de Crédito QUAC, Director de Operaciones at Fábricas de Crédito QUAC
Edwin tiene una capacidad única para ver el panorama completo: no solo sabe cómo implementar una API, sino que entiende cómo esa API encaja en el flujo de negocio, cómo va a escalar, y qué va a pasar cuando el negocio cambie. Es de esas personas con las que das gracias de trabajar porque sabes que el código que escribe no va a darte dolores de cabeza en producción.
