Design Mode: Furniture Aggregator Platform
April 26, 2026
This case study covers the Design Mode engagement for a furniture aggregator platform targeting the GCC/UAE market. The project is notable for the number of architectural iterations — the Architect worked through three major versions of the plan as the business model and feature scope evolved across multiple sessions.
At a glance
| Project | Multi-vendor furniture aggregator (GCC market) |
| Mode | Design Mode — multiple sessions |
| Stack | Next.js, React Native, Node.js, PostgreSQL, Elasticsearch |
| Key features | Bilingual Arabic/English with RTL, visual search, AR preview, vendor portal |
| Architectural iterations | 3 major versions across sessions |
| Output | Final design plan + rationale for each pivot |
The brief
A startup needed a platform to aggregate furniture catalogs from multiple retailers across the UAE and GCC into a single browsing experience. The business model evolved during the design sessions:
Initial model (v1–v2): Affiliate-only. Customers browse and compare products, then are redirected to the retailer’s website to purchase. ROOMLY earns a 5% affiliate commission on referred sales via cookie-based tracking.
Extended model (v3+): Multi-vendor checkout added. Premium customers can complete purchases directly on the platform with automated split payments to vendors. Four revenue streams: per-click fees, sales commission, premium customer subscriptions, vendor advertising placements.
Additional requirements across versions:
- Bilingual Arabic/English with full RTL support.
- iOS and Android mobile app with feature parity to web.
- Visual search (“Snap and Find”) — photo a piece of furniture, find similar products in the catalog.
- AR furniture preview — visualise products in the user’s room via mobile camera.
- Vendor portal — retailers manage their catalog and view performance analytics.
- Admin panel — internal staff manage platform content, vendors and data.
Architectural evolution across versions
v1 — Affiliate-only, web-first
The first plan established the core stack and the affiliate tracking mechanism.
Key decision: Server-side rendering for the customer-facing site.
SSR via Next.js is critical for SEO. A furniture aggregator’s primary acquisition channel is organic search — product pages must be indexable. A pure SPA would be invisible to search engines.
Affiliate tracking: a short-lived cookie set on click-through, with a server-side attribution endpoint that records the referral. Commission reported via retailer API webhooks or periodic reconciliation.
v2 — Mobile app added, visual search scoped
React Native was added for the mobile app with the explicit rationale:
React Native enables a single codebase for iOS and Android, shares component patterns with the Next.js web team, and supports camera access required for visual search. A separate native team for iOS and Android is not justified at this stage.
Visual search scoped as a mobile-only feature in v2 (camera access is the primary
interaction). The backend exposes a /visual-search endpoint that accepts an
image, calls an external visual similarity service, and returns matched product
IDs.
v3 — Multi-vendor checkout, AR, split payments
The most complex version. The addition of direct checkout required:
- Payment provider with marketplace/split-payment support — a standard payment gateway is insufficient. The plan evaluated Stripe Connect and HyperPay (GCC-native, supports local payment methods). HyperPay recommended for GCC market coverage; Stripe Connect as fallback for international vendors.
- AR module — 3D model assets stored in GCS, served to the mobile app’s AR renderer. The plan scoped AR as a progressive enhancement: if a product has a 3D model, AR is available; otherwise the standard image gallery is shown.
- Vendor subscription tiers — free (click-through only) vs. premium (direct checkout + AR + featured placement).
Final architecture (v3)
Customer Web App (Next.js, SSR, bilingual AR/EN RTL)Customer Mobile App (React Native, iOS + Android)Vendor Portal (Next.js)Admin Panel (Next.js) ↓Backend API (Node.js / Fastify)├── Product catalog + search (Elasticsearch)├── Affiliate tracking + click attribution├── Multi-vendor checkout + split payments (HyperPay / Stripe Connect)├── Visual search endpoint (→ external visual similarity service)├── Vendor analytics└── Admin operations
Database: PostgreSQL (products, orders, vendors, clicks, subscriptions)Object Storage: GCS (product images, CSV uploads, 3D model assets for AR)Search: Elasticsearch (product discovery, filtering, faceted search)Technology stack
| Layer | Choice | Rationale |
|---|---|---|
| Web frontend | Next.js | SSR for SEO; built-in i18n for AR/EN; RTL CSS support |
| Mobile | React Native | Single iOS/Android codebase; camera for visual search; AR via react-native-ar |
| Backend API | Node.js (Fastify) | High throughput for catalog queries; TypeScript parity with frontend |
| Database | PostgreSQL | Relational model fits product/vendor/order/commission structure |
| Search | Elasticsearch | Faceted filtering, multilingual tokenisation (Arabic analyser), relevance ranking |
| Payments | HyperPay (primary) / Stripe Connect (fallback) | GCC local payment methods; split payment to vendors |
| Storage | GCS | Product images, CSV bulk uploads, 3D model assets |
| Visual search | External service (evaluated at M1) | Avoid training a custom model; delegate to specialist provider |
Key risks identified
| Risk | Mitigation |
|---|---|
| Retailer API fragmentation | Standardise ingestion via a vendor connector layer; CSV fallback for retailers without APIs |
| Arabic search quality | Elasticsearch Arabic analyser + custom synonym dictionary; test with real GCC product names |
| Split payment reconciliation | Automated reconciliation job + manual override in admin panel; daily settlement reports |
| AR 3D model asset quality | Start with a curated set of high-value products; expand progressively |
| Visual search accuracy | Benchmark at M1; if accuracy < 70% on real catalog, re-evaluate provider |
| Cookie-based affiliate tracking | GDPR/PECR compliance required; consent banner + server-side fallback attribution |
What the iterative design sessions produced
Three versions of the architecture plan across multiple sessions, each incorporating feedback from the client:
- v1 established the core web stack, affiliate model and SEO requirement.
- v2 added mobile and visual search, with explicit rationale for React Native over separate native apps.
- v3 added multi-vendor checkout, AR, split payments and a four-stream revenue model — with the payment provider selection deferred to a benchmark in M1 rather than decided up front.
The plan did not try to lock in every decision early. Where the right choice depended on real-world performance data (visual search accuracy, payment provider GCC coverage), the plan defined a benchmark gate in M1 and deferred the final selection.
Honest limitations
- The AR feature depends on the existence of 3D model assets for products. Sourcing or generating these assets is a significant ongoing operational effort not fully scoped in the plan.
- Multi-vendor split payments are regulated differently across GCC countries. Legal review of the payment model in each target market was flagged as a prerequisite, not handled by the architecture plan.
- Retailer catalog integration is as complex as the retailers themselves. The connector layer abstracts this, but each new retailer requires integration work.
- Visual search quality at launch depends entirely on the chosen external provider. The plan defers this decision correctly, but it introduces a launch dependency.