Allá por 2021, un cliente me llegó con lo que sonaba como un brief directo: "Necesitamos un sitio de subastas. Como eBay, pero de nicho, piezas de motocicletas clásicas." Tres meses, dos prototipos abandonados, y una avería en producción genuinamente vergonzosa después, tenía opiniones. Fuertes. Al final lo logramos, pero no lo construiría de la misma manera ahora. Ni de cerca.
Punto clave: una plataforma de subastas para 2026 es Next.js, Supabase con canales en tiempo real para pujas en vivo, y Stripe; la parte difícil es mantener la integridad del estado de pujas bajo concurrencia, no el stack.
Las plataformas de subastas son engañosamente difíciles. En la superficie es solo listados, pujas, y un temporizador. Pero en el momento en que dos usuarios pujan dentro de milisegundos uno del otro, o tu conexión WebSocket se cae justo cuando la cuenta regresiva llega a cero, o tu procesador de pagos se agota mid-captura, de repente estás explicándole a un vendedor muy enojado por qué su BSA Lightning de 1967 se vendió por £12. Así que déjame caminar a través de lo que realmente construiría en 2026, herramienta por herramienta, decisión por decisión.
---
La Decisión de Arquitectura Central: ¿Monolito o Servicios?
No dejes que nadie te venda microservicios para una primera versión. Lo digo en serio.
He visto este error repetidamente, fundador contrata un consultor, consultor diagrama ocho servicios separados en una pizarra, todos asienten, y seis meses después nada se lanza porque el equipo está debugueando latencia inter-servicio en una plataforma con 40 usuarios. Para un MVP de subastas o incluso un producto moderadamente escalado (digamos, menos de 50,000 usuarios activos mensuales), un monolito modular es la llamada correcta.
Lo que alcanzaría: Next.js en el frontend y capa API, con un backend Node.js. No porque sea tendencia. Porque el modelo de componentes de servidor en Next.js 14+ genuinamente reduce la complejidad de páginas de listados de subastas donde el SEO realmente importa, quieres esas descripciones de lotes indexadas. Las rutas API manejan cosas más ligeras; la materia pesada en tiempo real vive en otro lado (más sobre eso en un momento).
¿Base de datos? PostgreSQL. Siempre PostgreSQL para cualquier cosa transaccional. Las subastas son profundamente relacionales, usuarios, lotes, pujas, reservas, facturas, y quieres restricciones de clave foránea haciendo trabajo real, no lógica de aplicación basada en vibraciones. Lo ejecutaría en Supabase en 2026 porque obtienes Postgres, seguridad a nivel de fila, y una capa de suscripción en tiempo real incorporada, lo que colapsa lo que solía ser tres preocupaciones de infraestructura separadas en una sola factura.
---
Ofertas en Tiempo Real: La Parte Que Te Romperá
Aquí es donde la mayoría de plataformas de subastas mueren. O al menos cojean.
El problema fundamental: las pujas tienen que sentirse instantáneas, tienen que ser consistentes, y tienen que manejar condiciones de carrera correctamente. Si dos usuarios envían una puja en el mismo milisegundo, uno de ellos gana. La base de datos decide quién. No el frontend, no el balanceador de carga, la base de datos, vía una transacción correctamente escrita con SELECT FOR UPDATE.
Para la capa en tiempo real en sí, usaría Ably en 2026 en lugar de rodar WebSockets crudos. Intenté el enfoque crudo en un proyecto de subasta de propiedades en Seahawk allá por 2022, socket.io auto-alojado, Redis pub/sub, todo. Estuvo bien hasta que no lo estuvo. Ably te da orden de mensajes garantizado, recuperación de estado de conexión (así que si el teléfono de un postor cambia de WiFi a 4G a mitad de la subasta, no se pierden silenciosamente la puja ganadora), y un dashboard sensato. El precio a escala es real, pero para la mayoría de operadores de subastas es ruido comparado con la complejidad de infraestructura.
Manejando el Problema de "Bid Sniping"
Auction sniping, colocar una puja en los últimos segundos, es una característica o un bug dependiendo de tu cliente. eBay famosamente lo permite. Muchas casas de subastas especializadas extienden el temporizador por 30-60 segundos si una puja llega en el minuto final. Esto se llama lógica de "soft close" o "anti-sniping". Constrúyelo desde el primer día. La regla es simple:
- La oferta llega con menos de N segundos restantes
- La transacción confirma que la oferta es válida y la más alta
- El tiempo de finalización de la subasta se extiende N segundos
- La nueva hora de finalización se transmite a todos los clientes conectados a través de Ably
Son quizás 40 líneas de lógica de servidor. Saltarse esto e implementarlo después es un dolor de cabeza que no quieres tener.
---
Pagos: No te Compliques
He visto a gente recurrir a configuraciones de pago exóticas en sitios de subastas porque las subastas tienen requisitos raros: capturas datos de pago por adelantado, cobras solo cuando el lote se cierra, podría necesitar retener un depósito, podría necesitar reembolsar de inmediato si alguien hace una oferta superior. Todo cierto. Todo solucionable con Stripe sin salir de la documentación de Stripe.
Stripe en 2026 sigue siendo la respuesta correcta para la gran mayoría de operadores de subastas. Específicamente:
- Stripe Payment Intents para el flujo estándar de puja-a-cargo
capture_method: manualpara autorizar una tarjeta sin cobrarla (esencial para retenciones de depósito)- Stripe Connect si estás construyendo un marketplace donde múltiples vendedores reciben pagos
Lo que sí marcaría: no autorices tarjetas por el valor total del lote por adelantado a menos que tengas asesoría legal que diga que debes hacerlo. Autoriza un depósito (10-25% es común en el mundo de las subastas), luego captura o anula una vez que se cierre el lote. Tus tasas de rechazo de tarjetas te lo agradecerán.
Para casas de subastas de mayor valor, autos clásicos, bellas artes, ese tipo de cosas, querrás permitir transferencia bancaria. Stripe ahora maneja esto razonablemente bien a través de sus productos de enlace de pago e invoices, pero seguirás necesitando a un humano en el ciclo para la reconciliación. Construye una simple cola de administrador para eso; no automatices lo que no necesita automatización.
---
Búsqueda y Filtrado: Typesense, No Elasticsearch
Honestamente, la pregunta de búsqueda en plataformas de subastas está subestimada. Los usuarios necesitan filtrar por categoría, precio actual, tiempo restante, condición, ubicación. Lo necesitan rápido.
Elasticsearch es excesivo para la mayoría de sitios de subastas y un dolor genuino de operar. Typesense es lo que usaría. Es código abierto, puedes autohospedarlo en un droplet de DigitalOcean de $6 o usar Typesense Cloud, y la calidad de búsqueda es excelente para datos de estilo catálogo. Sincroniza tu tabla de lotes PostgreSQL con Typesense a través de un gancho simple de cambio-captura-de-datos o un trabajo cron cada 30 segundos (la sincronización en tiempo real de precios de lotes de subasta es bonita pero raramente necesaria para búsqueda).
Lo que Typesense no maneja bien out of the box: geosearch para artículos de recogida solamente. Tiene geo filtering, pero si tu sitio de subastas tiene inventario pesado de "recogida local solamente", dedica media jornada a esa configuración temprano. Yo no lo hice, en un sitio de subastas de maquinaria de jardín en 2023, y lo retro-equipamos después con el doble de esfuerzo.
---
Infraestructura y Hosting
Aquí está mi configuración predeterminada para 2026:
- Vercel para el frontend de Next.js y rutas API, deployments sin configuración, URLs de vista previa por rama, funciones edge donde sea necesario
- Supabase para PostgreSQL y autenticación
- Ably para WebSockets
- Typesense Cloud para búsqueda
- Cloudflare al frente de todo, el tier gratuito maneja DDoS, optimización de imágenes y caching sin complicaciones
- Uploadcare o Cloudinary para imágenes de lotes subidas por vendedores (nunca almacenes cargas de usuarios en tu propio servidor en 2026, por favor)
Ese stack no tiene Kubernetes, sin cluster Redis autogestionado, sin contratar a alguien de DevOps. Un desarrollador solo o un equipo pequeño puede operarlo. Y críticamente, escala sin necesidad de rediseñar. Vercel y Supabase manejarán el pico de tráfico cuando tu sitio salga mencionado en una publicación especializada y 8,000 personas lo visiten en una hora.
Un Error de Infraestructura que Sigo Viendo
La gente se olvida de los trabajos en segundo plano. Los eventos de cierre de subasta no los dispara el usuario, suceden en una marca de tiempo específica, del lado del servidor. Necesitas un programador de trabajos confiable. Yo usaría Inngest para esto en 2026. Maneja disparadores basados en tiempo, reintentos y te da un registro de eventos que es realmente útil cuando estás depurando "por qué el lote 447 se cerró sin enviar el email al ganador". No uses un cron simple en tu servidor. Cuando tu servidor se reinicia, tu estado cron se va.
---
Herramientas de Administrador y Vendedor
Los vendedores necesitan crear listados, subir imágenes, establecer precios de reserva, y ver historiales de pujas. Los compradores necesitan listas de vigilancia, alertas de pujas, y descargas de facturas. Estas no son características glamorosas. Son las que los clientes te llaman a las 9pm un jueves.
Para el panel de administrador, construiría ligeramente sobre Retool o un dashboard personalizado de Next.js dependiendo del presupuesto. Retool es genuinamente rápido de implementar y maneja el 80% de las tareas administrativas de subastas: aprobar listados, gestionar usuarios, anular ofertas, sin escribir mucho código. Para cualquier cosa orientada al cliente construiría correctamente en Next.js, porque Retool incrustado en un iframe no es una buena experiencia de usuario.
Notificaciones por email, alertas de sobrepuja, lote cerrando pronto, invoice lista, todo a través de Resend en 2026. Reemplazó a SendGrid en mi stack hace aproximadamente 18 meses y no he mirado atrás. La experiencia de desarrollador es notablemente mejor y la entrega ha sido sólida.
---
Consideraciones de Seguridad Específicas para Subastas
Las plataformas de subastas atraen intentos de manipulación de pujas. Las pujas fraudulentas (un vendedor aumentando el precio de su propio lote usando cuentas falsas), apropiaciones de cuenta para colocar pujas ganadoras fraudulentas, y fraude de pago son todos reales y desproporcionadamente comunes comparados con el comercio electrónico típico.
Algunas cosas que yo integraría desde el inicio:
- Rate limiting en envío de ofertas, máximo N ofertas por usuario por minuto por lote, reforzado en la capa API. Upstash Redis es bueno para esto; tiene una librería de rate limiting propósito específico.
- Verificación de email antes de que se permita hacer ofertas, suena obvio, detiene una cantidad sorprendentemente grande de abuso
- Puntuación de fraude a través de Stripe Radar, ya incluido en Stripe, simplemente úsalo
- Identificación de IP y huellas digitales de dispositivos para detectar grupos de cuentas sospechosas, FingerprintJS Pro vale la pena si operás a cualquier escala significativa
Honestamente, lo más importante es el registro de eventos. Registra cada intento de puja, cada pago fallido, cada acción de cuenta. Cuando algo falle, y fallará, querés un registro de auditoría completo. El registro integrado de Supabase más una configuración ligera en Axiom lo cubre sin mucho esfuerzo.
---
FAQ
¿Cuál es el stack mínimo viable para un sitio de subastas pequeño y local?
Si estás construyendo para una casa de subastas local con quizás 200 usuarios y ventas semanales, no necesitás Ably o Typesense. WordPress con un plugin como Auctions for WooCommerce te lleva sorprendentemente lejos. He configurado tres de estas para casas de subastas regionales, antigüedades, equipos agrícolas, ese tipo de cosas. En el momento que necesitás pujas competitivas en tiempo real bajo carga, te la superás rápido.
¿Puedo usar Firebase en lugar de Supabase?
Podés. Firestore de Firebase es en realidad un ajuste razonable para el estado de puja en tiempo real. La razón por la que prefiero Supabase en 2026 es SQL, los datos de subastas tienen mucha estructura relacional (los lotes pertenecen a ventas, las pujas pertenecen a lotes y usuarios, las facturas hacen referencia a pujas), y consultar una base de datos de documentos para eso se vuelve complicado. Pero si tu equipo ya conoce Firebase profundamente, no cambies por cambiar.
¿Cómo manejo las zonas horarias para las horas de cierre de la subasta?
Almacena todo en UTC. Siempre. Muestra la zona horaria local del usuario a través del navegador. Esto suena obvio y aún lo veo hecho mal en aproximadamente uno de cada cinco proyectos. La API Intl.DateTimeFormat en navegadores modernos maneja el lado de la visualización sin necesidad de ninguna librería.
¿Necesito una aplicación móvil?
No para un MVP. Una aplicación web progresiva bien construida con notificaciones push (a través de la Web Push API) cubre el 90% de lo que los postores realmente necesitan en móvil. Las aplicaciones nativas vienen después, si el negocio lo justifica. Usaría Expo y React Native cuando llegue ese día, código compartido entre iOS y Android, y el equipo ya conoce React.
---
Ejecutar subastas en línea es un desafío de ingeniería legítimo disfrazado en una interfaz engañosamente simple. La interfaz de pujas son tres botones y un número. Todo debajo, consistencia, imparcialidad, estado en tiempo real, prevención de fraude, es donde vive el trabajo real. Consigue el stack correcto desde el principio y el resto es solo funcionalidades. Consíguelo mal y sos la persona explicándole al vendedor por qué su lote se vendió por £12.
Construye infraestructura aburrida. Construye productos interesantes sobre ella.