What We Learned from Building Marketplaces for 3 Completely Different Industries in One Year

Taras Oliinyk

CEO/Founder of U1CORE
4 min read

Summarize with AI

What We Learned from Building Marketplaces for 3 Completely Different Industries in One Year

In the past year we built three marketplace platforms in three completely different industries.

A global charity processing $720M+ in donations. A car auction platform with full bidding and escrow flow. A B2B procurement marketplace for restaurants and professional kitchens.

Different users. Different transactions. Different trust thresholds. And yet the same patterns showed up every time.

The three builds

Islamic Help — a humanitarian fundraising platform across 40+ countries. Six ways to give, one engine underneath. Full product strategy, UX architecture, UI design system, donation flow logic, and brand identity.

CarCapitol — an automotive marketplace app with vehicle discovery, bidding, and buyer-seller communication. Full mobile design and custom software development — 100+ screens.

Frandex — a B2B e-commerce web platform for HoReCa. Catalog architecture, product cards, and search — built for professional buyers who know what they need.

What was the same every time

Trust had to be designed before the first transaction. Islamic Help donors needed to see where money goes. CarCapitol buyers needed verified identity and escrow before spending thousands. Frandex procurement managers needed supplier credentials and return policies. Three industries — same pattern. If trust isn’t visible on screen, it doesn’t exist for the user.

The payment layer needed architecture from day one. Islamic Help needed split donations across causes with automatic distribution at peak Ramadan load. CarCapitol needed escrow until vehicle delivery. Frandex needed B2B flows — purchase orders, invoicing, net terms. Three different custom software architectures. All designed before the first transaction.

Both sides needed to feel the platform was built for them. Donors and campaign managers. Buyers and sellers. Procurement teams and suppliers. The moment you design for one side and assume the other will figure it out — that side churns.

What was completely different

Transaction speed. A £5 Islamic Help donation happens in 3 seconds — emotional, impulse-driven. A $15,000 CarCapitol car purchase takes days — research-driven, rational. A Frandex B2B order takes minutes but involves spec comparison and approval chains. Same marketplace UX design principles. Completely different tempo.

What “empty” looks like. On Islamic Help an empty campaign means fully funded — a celebration. On CarCapitol it means no matching cars — needs a redirect. On Frandex it means a procurement dead end — needs alternative suppliers. Same problem. Three different web design solutions.

What trust signals look like. Islamic Help: charity registration and impact reports. CarCapitol: vehicle inspection and escrow confirmation. Frandex: supplier certifications and completed order count. Same concept. Three different expressions in the product design.

The one lesson that applies to every marketplace

The specific solution is always different. The underlying problems are always the same.

Trust before transaction. Payment architecture before launch. Both sides designed for equally. Empty states treated as a first impression, not a temporary bug.

Every marketplace design and development project we take on starts with these four foundations. The surface changes depending on your industry. The architecture underneath doesn’t.

Whether you’re processing donations, selling cars, or managing procurement — the decisions that determine success are made before anyone opens Figma.

Your vertical determines what the product looks like. But the product architecture underneath — trust, payments, dual-sided experience, empty states — is universal. Get those right and the web design, mobile design, and visual layer follows naturally.