PATRIXEX
P2P exchange and info portal
Second Patrixex stage after the wallet: web P2P exchange. Start - worked MVP design in Figma (desktop + mobile), then product build: exchange, deals, loyalty, support.

- 01 · Client
Patrixex is two related projects for one client.
- 02 · Challenge
First fix the exchange UX in Figma: the path from rate to deal.
- 03 · Solution
Design stage: first full MVP prototype in Figma - exchange, loyalty, support screens and mobile views.
- 04 · Result
First - worked MVP design in Figma (desktop + mobile, exchange, loyalty, support).
Patrixex P2P exchange | JimmyNeuron case
About the client
Patrixex is two related projects for one client. After the Telegram wallet they went to web: a P2P exchange.
First step was a full design prototype in Figma - not a napkin sketch, but a worked MVP: exchange landing, Give/Get widget, how it works, deal locations, loyalty, support, policy, iPhone adaptive. Then we built the product on that frame.
The challenge we started with
- First fix the exchange UX in Figma: the path from rate to deal
- P2P/exchange: statuses, trust, locations, without chaos in chats
- Loyalty, support, and legal pages in the MVP from the start, not "later"
- Desktop and mobile in one prototype before development
1. MVP design prototype in Figma
We built the first fully worked prototype: a dark UI with a mint accent, a hero "exchange cash RUB for Tether," an exchange widget, "how it works" steps, a trust block, a deal map and locations, an FAQ, and reviews. Separately: a loyalty program (cashback, invite a friend, review, partner), support with a form, and a privacy policy. At the bottom of the canvas are mobile iPhone screens of the same scenarios. This was the MVP skeleton before code.
2. Exchange scenario
The prototype builds in the user journey from the start: choose the Give/Get pair, understand the deal steps, see where the exchange takes place, and ask a question via FAQ or support. Not a landing page "beautifully about crypto," but the UX of an exchange.
3. Retention and trust
The MVP design already included loyalty, a partner block ("open your own exchange point"), reviews, and legal text. This let the client see the whole product: acquisition → deal → return → support.
4. Next: the web product
After Figma, we built the web P2P/exchange layer as a fintech MVP (the second stage after the Telegram wallet). A demo video of the product is in the "Video" block on this page.
Video
Gallery

How it works
User scenario
- Checks the rate and fills in the exchange widget (Give / Get)
- Goes through the deal steps and the exchange location
- Contacts support or reads the FAQ if needed
- Returns through loyalty or referrals
Team / admin scenario
- Approves the Figma MVP: screens and scenarios
- Manages deals and statuses on the web
- Handles support and disputed operations
Technology
- Design
- Figma · first MVP prototype
- Product
- P2P / exchange · web
- Stage
- After the Patrixex TG wallet
Timeline: Stage 2 of the Patrixex ecosystem
Result and business effect
First - worked MVP design in Figma (desktop + mobile, exchange, loyalty, support). Then - web build of the fintech MVP. First prototype screenshot in the gallery, product demo in video. No public storefront link.
A fit if you need
- You need a P2P exchange as a web MVP - CRM and ERP
- You already have a wallet or mini app and it is time for an exchange layer - Web applications
- Fintech without a "pretty landing page instead of a product" - CRM and ERP
Frequently asked questions
Questions about this type of project, the same ones clients ask before a similar build.
Why not build it on a no-code platform?
For testing a hypothesis over a couple of months, a builder is fine. Custom code pays off once you hit limits on permissions, integrations, speed or plan quotas. A common path: prototype on a builder, then an MVP on your own code with the data migrated.
How much does it cost and how do I pay?
We price per task, with an estimate in 1–2 days after the brief. It depends on the roles, screens and integrations in the release. You pay per iteration — prototype, MVP, next stage — on acceptance, not the whole budget upfront.
Who owns the code?
You do. The code and infrastructure stay with your company, so you can switch teams without rewriting the product.
What if the requirements change along the way?
Before coding we agree what goes into v1 and what goes to the backlog. New ideas do not break the current stage: we estimate them separately and plan them for the next one. Every finished task goes to staging, so you see the product instead of waiting for the end.
Need a P2P exchange?
Describe pairs, party roles, and compliance constraints - we’ll estimate an exchange MVP.


