IKEA

IKEA Portland partnered with Jifiti, which engaged moblers to help build a digital gift-registry experience. The confirmed moblers scope covered an Android application and companion web access for creating, managing, sharing, and using gift lists in-store.

This is a historical project record, not a claim that the original application remains available or powers IKEA’s current registry.

Confirmed delivery

• Android application for registry owners and guests.
• Web access to view and interact with registries across devices.
• Personalized lists for weddings, housewarmings, and other events.
• In-store barcode scanning to identify the intended IKEA product.
• Synchronized purchase status intended to reduce duplicate gifting.
• A two-year moblers collaboration through Jifiti.

The archived Jifiti/IKEA Portland case-study summary describes the broader solution as a branded, multichannel SaaS registry spanning desktop, mobile web, mobile apps, and in-store touchpoints. It reports that this solution went live within 90 days. That launch window is not the same as the full two-year moblers engagement.

Current availability

No current public Apple App Store or Google Play listing for the historical Jifiti/IKEA Portland registry application has been verified.

IKEA’s current U.S. Gift Registry FAQ explicitly states that Gift Registry is not available in the IKEA app and is available through the website. The current public registry is:

• IKEA U.S. Gift Registry

IKEA currently requires an IKEA Family account to create a registry, while guests can purchase without one. Its documented in-store web flow requires a smartphone with an internet connection, camera permission, and barcode scanning; manual article-number entry is the fallback. These are current IKEA service requirements and must not be attributed to the historical moblers implementation.

No historical demo credentials, archived registry URL, store-release link, public prototype, or confirmed deployment-region list is available.

Technical stack and architecture

Confirmed architecture boundary

The confirmed client surfaces are an Android application and a web platform. The Jifiti archive characterizes the broader registry product as SaaS and multichannel. Historical project copy describes synchronized purchase status and a barcode-assisted store flow.

The following production choices are not publicly disclosed:

• Android language or framework (Kotlin, Java, Flutter, React Native, or other).
• Web framework, libraries, versions, and build tooling.
• Backend language, runtime, API style, gateway, databases, and storage.
• Cloud or hosting provider and deployment model.
• Monolith, microservices, serverless, queueing, or event-driven patterns.
• Real-time sync mechanism such as WebSockets, push, polling, or server events.
• Authentication and authorization for registry owners and guests.
• CI/CD, testing, logging, monitoring, analytics, and crash reporting.
• Barcode-scanning library or SDK used by the Android application.

Jifiti’s public legal page mentions barcode libraries used across some Jifiti software, but it does not tie them to this Android implementation; they are therefore not presented here as the IKEA project’s stack.

Diagram-ready description

At the highest publishable level: registry owners and guests used Android and web clients; the clients supported list and sharing workflows; in-store barcode input identified products; and a synchronized registry service updated purchase status across participants. The implementation between those logical components is not public.

IKEA inventory and point-of-sale integration

Historical materials confirm barcode scanning tied to the store journey and synchronized purchase tracking. They do not confirm:

• A direct IKEA public or private inventory API.
• POS hooks, checkout callbacks, Jifiti middleware endpoints, or batch feeds.
• Whether barcode resolution occurred on-device, in a backend, or in an IKEA system.
• UPC, EAN, IKEA article number, SKU, or another canonical identifier.
• Real-time versus batch inventory checks or synchronization frequency.
• Offline caching, queued scans, retry behavior, or conflict resolution.
• Whether scanning reserved stock, marked a registry item, or was reconciled after checkout.
• Ownership of registry and purchase records among IKEA, Jifiti, and moblers.
• Tokens, encryption, retention, access controls, or compliance requirements.

Accordingly, the page no longer implies an undocumented direct POS or inventory integration. Technical partners need approval from IKEA or Jifiti before those system boundaries can be published.

Scalability and operational constraints

The project was intended to support a multichannel customer journey and event-season use. The Jifiti archive says the SaaS approach minimized retailer integration and IT effort.

No public source provides concurrent-user targets, daily traffic, registry or transaction volumes, peak-season load tests, autoscaling, load balancers, caching, CDN use, database sharding, retention limits, offline-store capacity, latency targets, uptime, or an availability SLA. “Scalable” on this page is therefore a qualitative design goal, not a numeric capacity claim.

Outcomes and business impact

Confirmed attributable outcome:

• The archived Jifiti case-study summary reports that the broader IKEA Portland multichannel solution went live within 90 days and reduced the integration and IT resources needed for launch.

Confirmed qualitative product outcomes:

• Registry creation and sharing across Android and web surfaces.
• Barcode-assisted product identification in-store.
• Synchronized purchase status designed to reduce duplicate gifts.
• A connected journey between digital lists and physical retail.

Not publicly disclosed: registries created, active users, scans, tracked purchases, retention, conversion, duplicate-gift reduction, checkout-time improvement, revenue influenced, uptime, synchronization latency, partner ROI, customer satisfaction, or an attributable IKEA/Jifiti testimonial. No number should be published without its source, cohort, method, and measurement window.

Timeline and engagement

The moblers project record states a two-year collaboration through Jifiti. Exact start and end months or years, MVP date, app-store launch, feature-rollout milestones, and the division between development, support, and maintenance are not public.

Separately, the Jifiti case-study archive says the wider IKEA Portland multichannel registry went live within 90 days. This is published as a solution launch result, not as a replacement for the missing moblers engagement dates.

Screenshots and demo

The retained project cover image is displayed on this page. No verified public screenshots or video of the historical barcode flow, registry creation, sharing, guest purchase tracking, administrative experience, or mobile application are available in the project materials. The current IKEA website should not be used as a screenshot of the historical implementation without explicit attribution and permission.

Evidence boundary

This page separates facts from moblers’ historical project record, a third-party archive of Jifiti’s IKEA Portland case study, and IKEA’s current help documentation. Current IKEA behavior is not proof that the historical implementation used the same architecture or flows. Named technologies, APIs, app-store links, integrations, capacity figures, KPIs, and dates remain omitted until an authorized source confirms them.