E-commerce de Funko Pops con Angular y Laravel: de la Entrevista al Deploy

El inicio: “Solo es un carrito de compras, ¿no?”

Cuando me asignaron el proyecto final para obtener mi título de Analista de Sistemas, pensé que sería relativamente simple. Después de algunas entrevistas sobre mi experiencia, me propusieron desarrollar un e-commerce completo para venta de Funko Pops.

“Seguro es un CRUD con carrito”, pensé. Estaba equivocado.

Este proyecto me enseñó que un e-commerce real no es solo “mostrar productos y cobrar”. Implica gestión compleja de inventario, múltiples variaciones de productos, sistemas de descuentos, integración de pagos, manejo de sesiones, reportes y mucho más.

En este artículo comparto todo el proceso: desde las entrevistas iniciales hasta el deploy, los desafíos que enfrenté y lo que aprendí en el camino.

Fase 1: Las entrevistas que cambiaron todo

El proyecto comenzó con algo que me sorprendió: entrevistas simuladas con los “propietarios” del negocio. Aunque eran ficticias, debíamos tratarlas como reales para aprender a levantar requisitos correctamente.

Lo que descubrí en las entrevistas:

• No era “solo vender muñecos” - Necesitaban productos con múltiples variaciones (colores, tamaños, ediciones especiales) cada una con su propio precio y stock
• Querían dos sistemas de descuentos diferentes: automáticos por fecha (como Black Friday) y cupones manuales que los clientes ingresan
• Precios en dos monedas: ARS y USD, con el tipo de cambio guardado en cada venta
• Categorías jerárquicas: 3 niveles de profundidad (Ej: Películas > Marvel > Avengers)
• Sistema de reseñas: Pero solo podían opinar quienes compraron el producto
• Panel administrativo robusto: Con reportes, filtros y exportación de datos

Después de 3 sesiones de entrevistas, documenté 25 requisitos funcionales que organicé usando el método MoSCoW (Must Have, Should Have, Could Have, Won’t Have).

Primera gran lección: Nunca subestimes la fase de requisitos. Los 3 días que invertí aquí me ahorraron semanas de retrabajos después. Es más fácil cambiar un documento que reescribir código.

Fase 2: Decisiones de arquitectura

Con los requisitos claros, tuve que decidir cómo construir el sistema.

Stack tecnológico elegido:

• Backend: Laravel (PHP) - Para crear la API REST
• Frontend: Angular - Para la interfaz de usuario
• Base de datos: MySQL
• Pagos: Mercado Pago
• Envíos: Correo Argentino
• Autenticación: JWT (tokens de sesión)

¿Por qué estas tecnologías?

Laravel porque:

• Tiene herramientas excelentes para manejar relaciones complejas entre datos (productos, categorías, variaciones)
• Sistema de migraciones que facilita versionar la base de datos
• Manejo sencillo de archivos para las imágenes de productos
• Soporte nativo para “eliminación lógica” (marcar como eliminado sin borrar realmente)

Angular porque:

• Necesitaba una aplicación de página única (SPA) para mejor experiencia de usuario
• TypeScript hace el código más predecible y mantenible
• Sistema de rutas con protección (usuarios normales vs administradores)
• Componentes reutilizables

Separé frontend y backend completamente, esto me permitió desarrollar ambos en paralelo y, en el futuro, poder escalarlos de forma independiente.

Segunda lección: Elegir bien las tecnologías al inicio es crucial. Cambiarlas a mitad de proyecto es casi como empezar de cero.

Fase 3: El corazón del sistema - La base de datos

Aquí es donde las cosas se pusieron serias. Diseñé una base de datos con más de 25 tablas interrelacionadas.

Las tablas principales:

• Usuarios: Clientes y administradores con sus datos personales
• Productos: Información base (nombre, descripción, precio, imágenes)
• Variaciones de productos: Cada combinación (Ej: “Rojo-Grande”) con su propio stock y precio
• Categorías: Organizadas en árbol de 3 niveles
• Marcas: Fabricantes de los productos
• Descuentos: Campañas automáticas por fecha
• Cupones: Códigos que los usuarios ingresan manualmente
• Carrito: Persiste entre sesiones (no se pierde al cerrar el navegador)
• Ventas: Registro histórico de todas las compras
• Reseñas: Comentarios y calificaciones vinculadas a compras reales

Decisiones clave del diseño:

1. Eliminación lógica en todas las tablas - Nunca borrar datos físicamente, solo marcar como eliminados. Esto permite recuperar información y mantener historial completo.

2. Variaciones anidadas - Un producto puede tener variaciones padre-hijo. Por ejemplo: Color Rojo (padre) → Tamaño pequeño, mediano, grande (hijos).

3. Sistema flexible de descuentos - Un descuento puede aplicarse a productos específicos, marcas completas o categorías enteras. La prioridad es: Producto > Marca > Categoría.

4. Doble moneda desde el inicio - Cada producto tiene precio en ARS y USD. Cada venta guarda el tipo de cambio del día para referencias futuras.

Tercera lección: Invertí 2 semanas solo diseñando la base de datos en papel antes de escribir una línea de código. Esto evitó tener que hacer migraciones complejas después. Un buen modelo de datos es el 60% del éxito del proyecto.

Fase 4: Desarrollo del Backend

Con la base de datos lista, empecé a construir la API que conectaría todo.

Los desafíos más interesantes:

1. Sistema de descuentos multicapa

Este fue probablemente el aspecto más complejo. Tenía que:

• Aplicar descuentos automáticos si había campañas activas en ese momento
• Permitir que los usuarios ingresen cupones manualmente
• Respetar una jerarquía clara (producto específico > marca > categoría)
• Calcular correctamente tanto porcentajes como montos fijos
• Permitir aplicar descuento automático Y cupón al mismo tiempo

La lógica busca en orden: primero si hay descuento para ese producto específico, si no, busca para su marca, y si no, para su categoría. Se aplica el primero que encuentre válido.

2. Carrito persistente

El carrito se guarda en la base de datos, no en cookies o almacenamiento local. Esto significa que:

• No se pierde si el usuario cierra el navegador
• Funciona en cualquier dispositivo donde inicie sesión
• Permite al administrador ver carritos abandonados para análisis

3. Integración con Mercado Pago

Esta fue una de las partes más complejas. El flujo funciona así:

1. Usuario confirma la compra
2. Se crea una “venta temporal” en mi sistema
3. Se redirige al usuario a Mercado Pago
4. Usuario paga (o no)
5. Mercado Pago me notifica el resultado mediante un webhook
6. Si el pago fue exitoso: creo la venta definitiva, actualizo el stock, vacío el carrito y envío email de confirmación
7. Si falló: elimino la venta temporal y el usuario puede intentar de nuevo

4. Actualización automática de stock

Cada vez que se confirma una venta, el sistema:

• Reduce el stock de cada producto o variación vendida
• Si algún producto se queda sin stock, automáticamente se oculta del catálogo
• Los administradores reciben alertas de productos con stock bajo

Cuarta lección: Las integraciones con sistemas externos (pagos, envíos) siempre son más complejas de lo esperado. Siempre hay casos extremos: ¿qué pasa si el usuario cierra la ventana durante el pago? ¿Y si la conexión falla? Hay que contemplar todo.

Fase 5: Frontend y experiencia de usuario

Con el backend funcionando, me enfoqué en crear una interfaz intuitiva y atractiva.

Estructura del frontend:

Organicé la aplicación en 3 áreas principales:

• Zona pública: Catálogo, detalle de productos, búsqueda (accesible para todos)
• Zona de usuario: Login, carrito, checkout, historial de compras
• Panel admin: Dashboard, gestión de productos, ventas, descuentos, reportes

Funcionalidades destacadas:

Sistema de búsqueda y filtros combinables:

• Por texto (busca en título y descripción)
• Por categorías (los 3 niveles)
• Por marca
• Por rango de precios
• Por colores disponibles
• Solo productos con reseñas

Todos los filtros se pueden combinar libremente y funcionan en tiempo real.

Carrito inteligente:

• Muestra el precio unitario, subtotal por producto y total general
• Calcula descuentos automáticos en tiempo real
• Permite aplicar cupones con validación inmediata
• Muestra el ahorro total logrado
• Si no hay stock suficiente, avisa al momento

Protección de rutas:

• Las rutas de usuario requieren estar logueado
• Las rutas de admin verifican que el usuario sea administrador
• Si intentas acceder sin permisos, te redirige al login o al home

Quinta lección: La experiencia de usuario es tan importante como la funcionalidad. Un sistema robusto con una interfaz confusa fracasará igual.

Fase 6: Panel administrativo

El panel admin fue crucial para que los “dueños del negocio” pudieran gestionar todo sin ayuda técnica.

Lo que pueden hacer los administradores:

• Dashboard con métricas en tiempo real: Ventas del mes, productos más vendidos, stock bajo, gráficos de tendencias
• Gestión completa de productos: Crear, editar, eliminar, subir múltiples imágenes, definir variaciones
• Sistema de categorías visual: Árbol interactivo de 3 niveles
• Creación de campañas de descuentos: Con fechas de inicio/fin, aplicación selectiva
• Generación de cupones: Con límites de uso y códigos personalizables
• Historial de ventas con filtros avanzados: Por fecha, cliente, marca, categoría, método de pago
• Reportes exportables: Excel y PDF con toda la información de ventas

Los reportes incluyen: datos del cliente, productos comprados, cantidades, precios, descuentos aplicados y dirección de envío completa.

Fase 7: Testing y ajustes finales

Antes del deploy, dediqué tiempo a probar todo exhaustivamente.

Lo que probé:

• Flujo completo de compra: Desde agregar al carrito hasta recibir el email de confirmación
• Casos extremos de stock: ¿Qué pasa si dos personas intentan comprar el último producto al mismo tiempo?
• Descuentos combinados: Verificar que se calculen correctamente en todas las combinaciones posibles
• Formularios con datos inválidos: Mails mal formados, contraseñas débiles, campos vacíos
• Pagos fallidos: Que el sistema maneje correctamente cuando alguien cancela el pago
• Responsividad: Que funcione bien en móviles, tablets y desktop

Encontré y corregí varios bugs que no había anticipado, especialmente en la lógica de descuentos con productos que tenían variaciones.

Fase 8: Deploy y producción

Finalmente llegó el momento de poner todo en producción.

Configuraciones importantes:

• Variables de entorno separadas para desarrollo y producción
• Certificado SSL para conexiones seguras (HTTPS)
• Configuración de CORS para que el frontend pudiera comunicarse con el backend
• Optimización de imágenes automática
• Caché de consultas frecuentes
• Logs de errores para debugging

Resultados y lecciones finales

Lo que salió bien:

• Arquitectura escalable - Separar frontend y backend fue la mejor decisión
• Base de datos bien diseñada - No tuve que hacer migraciones complejas después
• Sistema de descuentos flexible - Puede adaptarse a cualquier estrategia de ventas
• Panel admin intuitivo - Los “clientes” pudieron usarlo sin capacitación
• Integración de pagos robusta - Maneja correctamente casos extremos

Lo que mejoraría:

• Testing automatizado desde el inicio - Hice todo manualmente y llevó mucho tiempo
• Documentación más detallada - A mitad de proyecto olvidaba por qué tomé ciertas decisiones
• Implementar caché antes - Algunas consultas eran lentas hasta que agregué caché
• Sistema de notificaciones - Quedó fuera del alcance pero hubiera sido útil

Las grandes lecciones:

1. La planificación vale oro — Los 3 días de entrevistas y 2 semanas de diseño de BD me ahorraron meses de retrabajos.

2. Los requisitos cambiarán (y está bien) — Aprendí a ser flexible y a priorizar. No todo tiene que estar en la primera versión.

3. Las integraciones son complejas — Mercado Pago, Correo Argentino, emails… cada integración tiene sus particularidades y casos extremos.

4. La experiencia de usuario importa tanto como la funcionalidad — Un sistema técnicamente perfecto pero difícil de usar es un fracaso.

5. Documentar las decisiones es crucial — A los 2 meses no recordaba por qué había elegido ciertas soluciones. Documentar me salvó varias veces.

Este proyecto me enseñó más que todos los cursos que tomé. Enfrentarme a problemas reales, tomar decisiones de arquitectura y ver cómo todas las piezas se conectan fue invaluable.

Si tuviera que dar un consejo a alguien que está por empezar un proyecto similar: invierte tiempo en planificar y diseñar antes de escribir código. Es tentador empezar a programar de inmediato, pero cada hora invertida en planificación te ahorra días de retrabajos.

El e-commerce funciona, es escalable y está listo para crecer. Pero más importante que eso: aprendí a pensar como un ingeniero de software, no solo como un programador.

Y eso, para mí, fue el verdadero logro de este proyecto final.