Swipe to Trade — Case Study

Crypto-trading app built on the Binance API that started as a Tinder-style swipe prototype and evolved into a social network for retail traders. Built for tothemoon.com; subsequently wound down by the client.

Summary

Swipe to Trade is a consumer crypto app that turns token discovery into a swipe mechanic — users swipe through tokens on Binance to decide what to add to their portfolio. topsweteam built the product from the first working prototype, and over several iterations broadened the scope from pure trading into a social layer: feeds, trader profiles, portfolio sharing, and the beginnings of copy-trading. A team of three fullstack engineers delivered the work. The product reached closed beta; the client subsequently wound it down.

• Client: tothemoon.com (same client as CosmicFOMO)
• Industry: Fintech / Crypto
• Engagement: Full build-out from prototype
• Timeline: Multi-phase build through closed beta
• Team: 3 fullstack engineers
• Status: Delivered; subsequently wound down by the client

Challenge

Retail crypto apps are an over-crowded category, and we agreed with the founders up-front that the differentiator had to be the interaction — a trading app that felt unlike any other. The working hypothesis was that the decision fatigue of "which of these 500 tokens do I care about" was the real pain point, not execution. That meant the first milestone wasn't a tradeable product at all; it was a discovery surface that had to feel good enough to use for twenty minutes a day.

Approach

We worked in short iterations: a prototype, a reaction, a pivot, another prototype. The swipe mechanic survived every round. What changed around it was the frame — at first a pure portfolio-builder, then an investment journal, and finally a social product where the swipe became how you browsed what other people were buying.

• GraphQL + TypeORM for the API. The data model changed often during the early iterations; GraphQL made client/server coordination cheap, and TypeORM kept the migration story sane.
• React Native for the mobile app. Shared TypeScript stack with backend paid off; we could move an engineer between layers during prototype rounds.
• AdminJS for internal tools. Binance integration, beta-cohort management, and feature flagging live in AdminJS rather than a bespoke admin.
• Three fullstack engineers, no specialization split. With the data model evolving every week, fullstack engineers could close end-to-end features without coordination overhead. A FE/BE split would have stalled iteration.

Solution

The app integrates with Binance for market data and trading, layers a social graph on top (follow traders, see their portfolios, swipe through tokens they hold), and has a reputation system in the background for surfacing trusted voices. Backend is a NestJS service with a GraphQL surface and a Postgres store; the mobile client is React Native. A small AdminJS back-office handles beta access and operational levers.

Key features shipped

• Swipe-to-discover token feed on top of Binance market data
• Portfolio tracking and trade history
• Social graph: follow, feed, profile
• Closed-beta cohort management

Outcome

The app reached closed beta with the swipe mechanic intact across every iteration — itself the outcome that matters most, since most "differentiating" UX ideas get cut the first time the metrics go flat. The client subsequently wound the product down for non-engineering reasons.

• Prototype → social app evolution across multiple iterations
• Reached closed beta with a stable cohort
• Core swipe mechanic retained across all product pivots
• Three-engineer team delivered end-to-end

Tech stack

Infrastructure: PostgreSQL, Docker Backend: Node.js, NestJS, TypeORM, GraphQL, AdminJS Mobile: React Native, React Integrations: Binance API

What we learned

• Iterating the frame, not the mechanic. The swipe feature survived every pivot precisely because we didn't treat every round's disappointing metric as a signal to rebuild the whole app.
• GraphQL was the right call for a product still finding its data model; we'd pick it again for an early-stage consumer app.
• Three fullstack engineers with TypeScript end-to-end lets a small team close end-to-end features without the FE/BE coordination tax — the right shape for a product still searching for product-market fit.
• A wind-down isn't a failure of engineering. Products in volatile categories get cut for market reasons; the engineering signal is whether what we shipped held up against what we agreed to build.