Por qué creamos TradeVault (y por qué el QR fue lo primero que diseñamos)

Todo marketplace de intercambio entre particulares tiene el mismo problema de fondo: dos desconocidos tienen que confiar el uno en el otro sin que nadie de por medio se lo garantice. En cartas coleccionables ese problema se nota más, porque el pago no lo gestiona la plataforma y la entrega casi siempre es en persona.

Empezamos por la pregunta más incómoda

Antes de diseñar el catálogo, el buscador o el chat, nos hicimos la pregunta que de verdad sostiene una plataforma de este tipo: ¿cómo sabe el servidor que un intercambio ha ocurrido de verdad, y no solo que dos personas dicen que ha ocurrido?

Si esa pregunta no tiene una respuesta sólida, nada más importa: da igual lo bonito que sea el catálogo si al final alguien puede reclamar una venta que nunca entregó, o negar una que sí completó.

Por eso el QR no es un extra, es la base

El QR temporal y de un solo uso que ves en cada operación no se añadió al final como una función más. Es la pieza que hace que todo el sistema de reservas, estados y valoraciones tenga sentido: sin una confirmación verificable del encuentro, "reservado" y "completado" serían solo palabras.

Diseñarlo primero también fijó una regla que se mantiene en todo TradeVault: el backend es quien decide si algo ha pasado, nunca el cliente. Ni una oferta se acepta, ni una carta se reserva, ni una operación se completa porque la aplicación lo diga sin que el servidor lo compruebe.

Lo que viene después

Con esa base resuelta, el resto (inventario, anuncios, ofertas, chat, valoraciones) se construye encima con la misma idea: la app hace más cómodo el intercambio, pero nunca decide por sí sola qué es verdad.

Seguimos ampliando el catálogo y las funciones, pero esa prioridad no cambia: primero la confianza en lo que ocurre, después la comodidad de cómo se hace.