We have all seen it.

You order a Billy bookcase on Monday. The eCommerce website confidently tells you that it will arrive by Friday. You don’t think twice about it.

But behind the simple promise lies one of the most complex decision making problems, in retail and supply chain technology.

That delivery date is not picked at random! It isn’t based only on whether the item is in stock. And it certainly isn’t someone in a warehouse manually checking inventory before you click Place Order.

Before you even complete your purchase, the retailer’s Order Promising engine has already answered two critical questions:

• Can we realistically deliver this order by Friday?
• If yes, where should we fulfill it from?

These two decisions are known as Order Promising and Order Allocation.

Although customers rarely notice them, they play a huge role in shaping the shopping experience.

Isn’t inventory enough?

A common assumption is that if an item is available, the retailer can simply promise a delivery date.

If only it were that simple.

Imagine a retailer has the same product available in three locations:

• A warehouse 300 km away
• A nearby store
• Another distribution center that’s already operating at full capacity

Technically, the item is available. But can it still be delivered by Friday? That depends on more than inventory.

The system needs to consider warehouse operating hours, order cut-off times, carrier transit times, holidays, processing capacity and several business rules before it can confidently commit to a delivery date. In other words, the delivery date shown to the customer is a solved outcome — not just an inventory lookup.

This is where Order Promising begins.

What is Order Promising?

At its core, Order Promising answers one simple question:

“What is the earliest date we can confidently promise this order to the customer?”

It’s not about showing the fastest possible date. It’s about showing a date that the business can realistically meet.

To make that decision, an Order Promising engine evaluates multiple operational factors together, such as:

• Inventory availability
• Warehouse calendars
• Order release cut-off times
• Processing capacity
• Carrier transit times
• Delivery service levels
• Business rules and shipping constraints

None of these factors alone determine the answer. Together, they do!

That’s why Order Promising is a decision making process rather than a simple calculation.

Making a promise is only half the decision

Once the system knows when it can deliver the order, another question immediately follows.

Where should the order be fulfilled from?

This is where Order Allocation comes in.

Suppose the product is available in three different fulfilllment locations. Which one should the retailer choose?

The closest location may seem like the obvious answer.

But what if that store has only one unit left, while another customer plans to collect it in person?

What if shipping from that location costs significantly more?

What if another warehouse has plenty of stock and can still meet the same delivery promise?

Order Allocation evaluates these trade-offs to find the best fulfillment location. Factors such as inventory availability , distance, cost and operational considerations influence the decision.

The objective isn’t simply to ship the order. It’s to fulfill the promise in the most efficient and sustainable way!

Why these decisions matter?

From a customer’s perspective, a delivery date is just information.

From a retailer’s perspective, it’s a commitment!

Every promise influences customer expectations, warehouse planning, logistics schedules and operational execution. Once the promise is made, the business is expected to execute its operations around meeting that commitment.

An inaccurate promise can lead to:

• Disappointed customers
• Increased support calls
• Higher shipping costs
• Order cancellations
• Loss of customer trust

Ironically, customers rarely remember when a retailer delivers exactly as promised. But they almost always remember when that promise is broken!

More than just software!

As software engineers, we often think about APIs, databases, integrations and microservices.

Retail technology reminds us that some of the hardest engineering problems are not purely technical. They are business decisions translated into software.

Every delivery date displayed on an eCommerce website represents hundreds of operational rules, constraints and calculations working together in the background.

Thats what makes Order Promising and Order Allocation so fascinating. They are not just Retail supply chain fetaures. They are decision engines that balance customer expectations with operational reality!

Final Thoughts

The next time you see “Delivery by Friday”, remember that it isn’t just a date. Its the result of numerous decisions made in milliseconds.

A good promise isn’t simply optimistic. It’s realistic!

And behind every realistic promise is an Order Promising engine making one of the most important decisions in the retail supply chain.

When you shop online, do you think retailers are becoming better at keeping delivery promises, or do you still experience missed delivery dates? I would love to hear your thoughts!

The hidden decision behind every delivery promise: Understanding Order Promising & Allocation was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

We have a well-working infrastructure in this area, but can this be better and more cost-efficient?

I started an AI-evaluation benchmarking with my team. It was questioned! Why should we do this and what should we get out of it? My answer was that we should know that we have an informed decision for the future:

We divided the work into two phases:

Phase 1. We shared a small Translation Memory in six languages and sent complete files for translation from the TMS via a built proprietary orchestration for AI-text generation to the API of the provider.

Phase 2. We shared style guides, an extraction of terminology, and sent the domain information in the API-call.

The evaluating evaluation provider assessed the quality of each segment by Accuracy, Grammar, Readability, Style and Adherence. The assessments were made by linguists and AI. The ranking of the four dimensions where equally weighed and the linguist assessment was favored in relation to the AI assessment.

It was loads of work both from a communication and technical perspective, as we had numerous providers involved.

These were the lessons identified:

- The result was good already in Phase 1, most providers delivered translations with good readability and minor errors.

- The providers scored close together, with a narrow overall range.

- Different providers were good in different languages.

- There was quite a great deal of differences in how to access services by API which consumed time in engineering and communication.

- The selection of languages showed that language coverage varies between providers.

- What concerned me the most was the small improvements from Phase 1 to Phase 2. I had expected a more significant increase. The providers and we invested quite a lot of time.

- TMS forces sentence-level segmentation across the process, which does not support full text translations, i.e., not taking full advantage of the LLMs.

- It is a challenge that TMSs don’t provide any information beyond the segments to be translated.

- We have developed a proprietary orchestration enabling us to select different providers, engines or models of AI-generated texts.

This is where I should come up with a conclusion, but I won’t. I have more questions:

- Is the way we are used to training engines value adding? What if there are enterprise engines or open-source models out of the box that provide sufficient quality.

- What is the quality needed of the text generation for our co-workers and customers?

- If we add more data, how far will we push the needle and get better quality? Where is there a trade-off/break-even?

- Is one provider enough to cover all languages?

I have an old friend who said: “Most of the lessons learned are not learnt, they are just identified. It is not until you do the same thing again and you apply the lessons identified that they get lessons learned”.

We will pursue our path of digging the Language Lake and finding the right solution for the Language Generator with these lessons identified to make them learned.

How far can we push the needle of quality in AI-generated translations? was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s rapidly evolving AI landscape, many discussions tend to be either overly technical or too abstract to be practical. However, understanding a few fundamental concepts can make a significant difference in how effectively AI is understood and applied whether in technology, business, education, or everyday curiosity about the future.

This document highlights five essential concepts; tokens, context window, temperature, hallucination, and retrieval-augmented generation (RAG). Together, these provide a solid foundation for navigating and leveraging AI with greater confidence and clarity.

1. Tokens

The first concept to grasp is that AI models do not read words or letters; they read tokens.

What is a Token?

Think of tokens as chunks of text. A token can be a complete word, part of a word, or even punctuation. For instance, the sentence “I love pizza” can be broken down into three tokens: “I,” “love,” and “pizza.”

Why Tokens Matter

Every AI product, such as ChatGPT or Claude, processes tokens behind the scenes. The more tokens you send, the more the model has to process, which can increase operational costs. The model’s context window — the number of tokens it can hold in memory at once — also plays a crucial role. Older models might handle 4,000 tokens, while newer ones can manage over a million. This limitation explains why AI sometimes forgets earlier parts of a long conversation; once the context window fills up, the oldest tokens are discarded.

Understanding tokens is essential for crafting effective prompts and managing the AI’s memory limitations during interactions.

2. Context Window

The context window is akin to a person’s memory during a conversation. It defines how much text, measured in tokens, an AI model can consider at one time.

The Whiteboard Analogy

Imagine a whiteboard where you can write anything you want. However, once it’s full, you must erase something old to make space for new information. A small context window (e.g., 4,000 tokens) limits the AI to a few pages of text, while a large context window (e.g., 200,000 tokens) allows for entire books.

Practical Implications

When working on tasks like summarizing long documents or analyzing data, be aware that your AI might forget earlier parts of the conversation. This limitation is not a bug; it’s simply a function of the context window.

3. Temperature

Temperature is a setting that influences the randomness or predictability of an AI’s output.

Low vs. High Temperature

• Low Temperature (closer to 0): The AI opts for the most likely, expected words, resulting in consistent but somewhat dull outputs.
• High Temperature (closer to 1 or beyond): The AI takes risks, producing surprising and creative responses, though not always useful for factual tasks.

When to Adjust Temperature

For factual tasks like summarizing or coding, a low temperature is preferable for precision. Conversely, for creative tasks such as writing fiction or brainstorming, a higher temperature can yield more interesting results. While many consumer apps set this dial to a middle ground, understanding how to adjust it can enhance your AI interactions.

4. Hallucination

Hallucination refers to instances when an AI confidently provides incorrect answers, presenting them as facts.

Why Hallucination Occurs

AI language models do not function as databases; they predict the next most likely token based on learned patterns. When they lack information, they generate plausible-sounding but incorrect answers. The danger lies in the AI’s confidence, which can mislead users.

Practical Takeaway

Always verify facts, statistics, or advice obtained from AI, especially in critical areas like health or law. Understanding hallucination allows you to use AI more intelligently, treating it as a starting point rather than a definitive source.

5. Retrieval-Augmented Generation (RAG)

RAG is a concept that many misunderstand but is crucial for effective AI applications.

What is RAG?

RAG combines retrieval and generation. Traditional AI models are limited to the data they were trained on, which may not include recent or specific information. RAG solves this by breaking documents into chunks and storing them in a vector database that understands meaning.

How RAG Works

When you ask a question, the system retrieves the most relevant chunks from the database and feeds them to the AI along with your query. This process allows the AI to generate answers based on up-to-date and contextually relevant information.

Importance of RAG

RAG is foundational for many AI products, enabling them to provide accurate and context-aware responses. Understanding this concept helps you appreciate how AI tools work and what limitations they may have.

Conclusion

As AI continues to permeate various sectors, understanding these five key concepts; tokens, context window, temperature, hallucination, and RAG, will set you apart from those who merely skim the surface. You don’t need to be an engineer or a coder; a basic understanding of these terms will enhance your ability to use AI effectively.

By mastering these concepts, you position yourself in the top 10% of individuals who can navigate the complexities of AI with confidence. Welcome to a deeper understanding of the technology shaping our future.

Usefull links

Generative AI Leader Certification

What’s Next

I will sum up few more topics which I found interesting to look at. Let’s get learning🍀!

🙏 Thank you for reading to the end! Comment below or email me at dbpr.sinha@gmail.com if you have any questions. For more articles please stay tuned.

Connect with me

• Medium
• LinkedIn
• Instagram
• Facebook

Understanding AI: Five Key Concepts to Get Ahead was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Long-Tail Problem

Our product catalogue is vast and wonderfully diverse — thousands of items across every room, style, and budget. Yet when we looked at what our recommender was actually surfacing to customers, the picture was stark: a small cluster of popular items was dominating the recommendations, while the majority of the catalogue barely got a look-in.

This is the long-tail phenomenon, and it’s endemic to recommendation systems. The mathematics behind it follow a power-law distribution — a tiny head of popular items captures most of the attention, while a long tail of equally worthy products languishes in obscurity.

This isn’t just a missed business opportunity. It’s a missed customer opportunity. Discovery is one of the most delightful parts of shopping. When a recommender only echoes back what’s already popular, it narrows the world rather than expanding it.

How Our Recommender Works (The Short Version)

Our existing system is a three-stage pipeline:

1. Product embeddings — We use a Word2Vec-style algorithm, but instead of learning from sequences of words, it learns from sequences of products that customers view. Each product ends up as a point in a rich, high-dimensional space where similar products cluster together.
2. Session modelling with an LSTM — A neural network tracks your browsing session across devices and visits, predicting which product you’re most likely to add to your cart next. It’s trained to minimise the distance (in embedding space) between its prediction and the product you actually chose.
3. Nearest neighbour search — Once the model has a predicted embedding, it finds the real products closest to that point in the catalogue and serves them as recommendations.

The system works well for relevance. The problem is that “closest in embedding space” tends to gravitate towards popular items, because popular items are better represented in the training data. The rich get richer.

Enter Contrastive Learning

Our insight was to change how the model learns, not just what it recommends.

The key idea is contrastive learning with negative sampling. Instead of only training the model to move towards the right answer (the product a customer added to cart), we also train it to move away from carefully chosen wrong answers — the negative samples.

This is analogous to how we teach children to distinguish between concepts. You don’t just show a child pictures of cats; you also show them dogs and say “not this.” The contrast sharpens understanding.

We explored two approaches to selecting these negative samples:

In-batch negative sampling treats other products in the same training batch as negatives. If you’re training on a session where someone bought a BILLY bookcase, other items being processed at the same time — a POÄNG chair, a KALLAX shelf — become the “not this” examples. We introduced a configurable cap on how many negatives to use, balancing learning signal against computational cost.

Adaptive top-k negative sampling goes a step further. Rather than using all available negatives, it dynamically selects the hardest ones — the products whose embeddings are most similar to the model’s current prediction. These are the confusable items, the ones where the model is most likely to go wrong. Training on these hard negatives forces the model to develop finer-grained discrimination.

Rethinking the Loss Function

Our existing system uses cosine similarity loss — it trains the model to maximise the similarity between its prediction and the true item. Simple, effective, but blind to diversity.

We extended this with two contrastive variants:

Weighted loss adds a penalty term. For each negative sample, the model is penalised if its prediction is too similar to that negative. The strength of the penalty is controlled by hyperparameters α and β, letting us tune the trade-off between accuracy and diversity.

Cross-entropy loss reframes the problem as classification: given the true item and N negative candidates, can the model identify the correct one? This formulation, inspired by SimCLR [1] and SimCSE [2] from the computer vision and NLP worlds, proved particularly powerful in our setting.

What the Results Showed

We evaluated our methods on two datasets: our own proprietary IKEA Netherlands data, and the publicly available RetailRocket benchmark. We measured both accuracy (NDCG@10 — how well the true item ranks in our recommendations) and diversity metrics (catalogue coverage and Gini Coefficient).

On the IKEA dataset, our best offline configuration — cross-entropy loss with 100 in-batch negatives — delivered:

• +26.4% improvement in catalogue coverage
• +6.5% improvement in Gini Coefficient (a measure of how equitably recommendations are spread across the catalogue)
• +6.4% improvement in NDCG@10

Critically, we weren’t trading accuracy for diversity. The model got better at recommending the right products and surfaced a much wider slice of the catalogue.

We then ran an online A/B test on the IKEA Netherlands website using the weighted loss with 100 in-batch negatives. The live results confirmed what offline evaluation suggested: +2.53% improvement in catalogue coverage and a +9.59% improvement in diversity over the baseline.

Why This Matters

A recommender that only amplifies what’s already popular is, in a subtle way, a recommender that’s stopped doing its job. The whole point of personalisation is to connect each customer with the right product for them — and that product might be sitting quietly in the long tail, waiting to be discovered.

For IKEA, this has real stakes. A broader recommendation distribution means:

• Customers discover products they wouldn’t have found through search alone
• Newer or niche items get a fair chance to find their audience
• The shopping experience feels more alive — more like browsing a well-curated store than being handed a bestseller list

The Gini Coefficient gives us a useful target to aim for. We want it in the range of [0.4,0.7]— a “softened” power-law where popular products remain visible (as they should; popularity is a signal of quality) but the tail is meaningfully surfaced. Not perfect equality, but genuine diversity.

What’s Next

This work opens several directions we’re excited to explore. Our next focus is on smarter negative sampling — not just selecting the hardest negatives for model performance, but identifying the most informative ones for learning efficiency. Training on the right negatives could let us achieve the same diversity gains with less computation, making the approach more scalable.

We’re also thinking about how to incorporate richer signals — product attributes, room contexts, style families — into the embedding space itself, so that the notion of “similar” and “different” better reflects what customers actually care about.

A Note on the Research

This work is a collaboration between IKEA Retail (Ingka Group) and the University of Amsterdam’s Information Retrieval Lab, as a part of IKEA’s internship program. It reflects the kind of industry-academia partnership that produces the most grounded, rigorous applied AI research.

The full paper is available on arXiv.

References

[1] Chen, Ting, Simon Kornblith, Mohammad Norouzi, and Geoffrey Hinton. “A simple framework for contrastive learning of visual representations.” In International conference on machine learning, pp. 1597–1607. PmLR, 2020.

[2] Gao, Tianyu, Xingcheng Yao, and Danqi Chen. “Simcse: Simple contrastive learning of sentence embeddings.” In Proceedings of the 2021 conference on empirical methods in natural language processing, pp. 6894–6910. 2021.

Beyond the Bestsellers: How We’re Teaching IKEA’s Recommender to Think Differently was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Regardless of whether we choose to just support the latest evergreen browsers or to go back many versions, if we want to expose this to code the process is typically the same: we define a browserslist (and / or esbuild) compatibility list. This allows us to specify in code the spread of browsers and versions we want to support, and expose it to various build systems. Feeding the browserslist configuration into something like Babel or autoprefixer will let it calculate whether it needs to add browser-specific workarounds for older systems you’re still targeting. The same goes for esbuild: it’s easily configured for specific target version numbers.

IKEA’s design system — Skapa — does just this. Looking at our browser statistics, we see mostly fairly modern browsers that are quickly updated; the outlier is older versions of Safari on IKEA.com. So we currently have this browserslist configuration for our design system build tooling:

last 5 major versions and last 5 years,
Firefox ESR,
not Safari < 15.4,
not iOS < 15.4,
not op_mini all,
not dead

Let’s deconstruct that. We start by requesting the intersection of the last five major versions and the last five years. For evergreen browsers (those that update quickly and regularly) that gives us around five to seven months worth of support: more than enough time for most systems to automatically upgrade. We also make sure we include the enterprise release of Firefox which has longer support. Then for Safari, we go back to 15.4: that version added a set of features like masking and focus-visible that we want to have native support for. Finally, we disable support for very old browsers that would cost too much to support.

Shipping this data

Having this browser support matrix stored as code is a big benefit for Skapa, as changes to it can now be tracked over time, and it’s stored in one place. But if it’s a big benefit for Skapa, why shouldn’t it also be a big benefit for consuming teams? They are, after all, using Skapa patterns and components to build their own systems, so they might as well standardise on the same browser support if reasonable.

It turns out that this isn’t particularly difficult to do. A typical way to include browserslist is as a field in a project’s package.json file, and this has a hidden super power: instead of directly listing the chosen browser configuration in package.json you can tell browserslist to import it from an NPM package. This means that as well as our components Skapa can ship a package that just exports the browserslist config. The package output then looks a little like this:

module.exports = [
 'last 5 major versions and last 5 years',
 'Firefox ESR',
 'not Safari < 15.4',
 'not iOS < 15.4', 
 'not op_mini all', 
 'not dead',
 ];

Once this package has been imported as a dependency, then the compatibility data can be configured in as a key-value pair in package.json, like this:

"browserslist": ["extends @ingka/browserslist-config"]

Given the simplicity of this approach, it was an obvious thing to ship out to Skapa’s consumers. They would then get the benefit of having their system’s browser support automatically updated to match the level the components they’re consuming have.

Compatibility with esbuild

While browserslist is supported by a wide range of different technologies, there’s a major exception: esbuild. Given its widespread and growing popularity — due to the performance benefits it can bring to the table — we need to make sure that our browser compatibility choices are made available to it.

Luckily for us, this is a solved problem: there are a few libraries that will translate a browserslist configuration to something that esbuild can consume. We can keep our browserslist configuration as the source of truth, and expose the automatic translation for esbuild consumers. We chose to do this with a new export called esbuild that’s included the same browserslist-config package.

For an example of how this is used, let’s look at Vite: a commonly used consumer of esbuild. In the standard vite.config.js configuration file, we can consume the browser support data by importing the package’s new export, and attaching it into Vite’s build.target configuration option:

import target from "@ingka/browserslist-config/esbuild";

export default defineConfig({
  build: { target }
});

This works in exactly the same way as the previous package.json method, and indeed both can be consumed if you have a mix of esbuild and browserslist tooling (Vite and SASS for example).

Overall benefits

We have already talked about how this process helps product teams align their own browser compatibility with that of the design system’s. There’s another positive side-effect though: the browserslist-config package becomes something that is gradually updated over time, meaning that consuming teams automatically follow the company-wide browser compatibility standard. Historically we’ve found many projects with es2015 or es6 set as the configuration: that’s a static level which leads to steadily increasing bundle sizes as more and more compatibility layers are automatically and silently added into the build. Tracking the design system’s baseline configuration helps to keep bundle sizes small and performance high.

To give specific data for that last point, a piece of JavaScript code that is shipped to the majority of IKEA.com users saw a drop in gzipped file size from 78KB to 34KB — a fall of over 55% — simply by configuring the build system to use the browserslist-config package instead of the previous single target of 'ie': 11.

Another benefit is that this configuration can be shipped as part of an app scaffolding system, meaning that teams starting new projects will automatically have access to the current and future browser support standards without having to lift a finger.

Of course, there’s nothing stopping a team that wants to own their own browser compatibility configuration from managing that themselves. Teams that know they will only be targeting the latest and greatest technologies, or teams that are consuming only simple components and want a longer support schedule, are welcome to configure this themselves. But starting with the default configuration and opting-out later when a need has been discovered is an easy choice.

Hopefully this has inspired you to investigate sharing your browser support matrix in your own design system. It’s a simple technique that leads to compatibility and performance benefits. I’d also love to hear if you’re doing anything similar or if there are ways you see that this could be improved.

Design systems and shareable browser support was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, I encounter similar questions in my organisation, albeit with a new twist: “Why do we need translation solutions when it’s all done ‘out of the box’?” or “Why pay for human review when an LLM can simply do it?” These moments transport me back to my 2018 self, unaware of the intricate complexity behind translation. I hadn’t grasped the advanced technology involved, the critical importance of localized texts crafted by linguists and supported by AI, nor the importance of the skills of our linguistic experts.

This journey has been transformative, introducing me to many co-workers and contacts who have illuminated the worlds of localisation, translation, and AI-driven text generation for me. It’s this learning journey that has led to the development of our “Liberation Playbook.”

Our foundational steps began in 2020 when my team Global Language Services implemented a traditional Translation Management System (TMS) at IKEA. This system was designed to combine artificial and human intelligence, offering essential capabilities like workflow management, text reuse, UI for review, and efficient file submission to translation agencies.

While some may question the decision today, I firmly believe it was the right first step. Centralizing assets, harmonizing workflows, and establishing robust processes are non-negotiable prerequisites for any scalable language strategy. This TMS provided the crucial infrastructure upon which we would build.

Following this, in spring 2022, we introduced a terminology solution and brought in a specialist to lead our efforts. The goal was clear: to provide linguists with precise keywords, ensuring the unmistakable IKEA tone of voice was consistent across all IKEA content. This initiative unveiled a new, vital area of learning for us.

We faced a significant challenge — our texts were locked within third-party solutions. This was fragmenting our content value chain and preventing us from leveraging valuable linguistic assets outside these systems.

Meanwhile, the landscape of machine translation at IKEA shifted dramatically between 2022 and 2023, largely thanks to the pioneering work of my Senior Software Engineer. She meticulously built IKEA MT, leveraging 24 Marian models from Hugging Face. During our tests, IKEA MT outperformed commercial alternatives for IKEA-specific content. Additionally, Her deep dive into our translation memories revealed a critical insight: despite style guide directives, the tone of voice in some of our translations was not always consistent.

Then, November 2022 brought the ChatGPT revolution, sending ripples of both excitement and apprehension through the entire localization community. We responded by conducting tests with Automated Post Editing (APE) in April 2023. While the results weren’t groundbreaking, they were undeniably interesting.

The fact that our language assets were locked inside the TMS and the new Terminology solution, preventing us from using these for quality enhancement purposes outside these systems, was making me uneasy. This prompted me to accept an invitation from a friend to submit a proposal to present in Leipzig in 2023 on “Language Technology Requirements to Serve Global Enterprise Business Needs.”

The evening before the conference, I was introduced by chance to the concept of “triples” — subject, predicate, and object — and their role in structured data. The conference keynotes further reinforced this, highlighting how knowledge graphs could significantly reduce hallucinations in Large Language Models (LLMs).

Inspired, I returned and tasked our data engineer, with diving into graph technology and building our Language Lake and its data pipelines. This was a new frontier for him, and his journey will be shared in a future article.

Our exploration continued into autumn 2024, when my Senior Software Engineer, alongside a senior AI-engineer from MLOPS, conducted a Proof of Concept (POC) on LLMs and Retrieval-Augmented Generation (RAG) using data from the Language Lake for Spanish and Korean. The results were satisfactory but didn’t significantly surpass traditional machine translation. My Senior Software Engineer’s keen observation stuck with me: “The challenge for LLMs is they tend to generalize. IKEA’s specific tone of voice and its unique style make it difficult for LLMs to mimic effectively.”

Building a robust knowledge graph presents its own set of challenges, particularly concerning data and metadata management, and how these can be leveraged for quality estimation and correction of translated texts.

In 2025, we initiated a POC focused on this, working with a substantial volume of English-to-Spanish and Spanish-to-English files. Several questions arose: should we index at a file or segment level when preparing content for LLMs? For instance, if content from e-learning solutions relates to “Kitchen,” should it be indexed as “Kitchen” or “e-learning”? This decision profoundly impacts how we generate, assess, and correct texts, and it’s an area we continue to explore.

Despite moments of FOMO when observing other enterprises’ LLM advancements, I’ve remained steadfast in my conviction: without a solid data structure, we will not achieve the desired results. This belief was strongly validated during my Cognitive Project Management for AI Enhanced (CPMAI+E) course, which emphasizes that 80% of any cognitive technology project’s success hinges on its data foundation. You can access the free introduction to this course to learn more.

The language asset liberation playbook

Below is a developed step‑by‑step path, mapped to CPMAI (Cognitive Project Management for AI) phases, to execute consistently, scale and secure success. I hope this can serve as inspiration for other enterprises to start this journey. The playbook is based on CPMAI playbook and coedited with CoPilot.

1. Frame the outcomes (CPMAI: Business Understanding)

• Define the measurable goals: time‑to‑market, cost avoidance, language coverage, quality uplift.
• Prioritize use cases with clear owners: product copy, e-learning, store information, internal comms.
• Establish governance: roles, decision rights, tone‑of‑voice stewardship, market co‑creation.

Deliverables: Business case, success metrics, use‑case backlog, governance charter.

2. Inventory of texts (CPMAI: Data Understanding)

• Map where content lives: TMS, CMS, PIM, design tools, portals, files.
• Assess quality and provenance: who wrote it, who validated it, where is it used, how it performs.
• Find gaps: missing languages, inconsistent tone, outdated glossaries, orphaned assets.

Deliverables: System/content map, asset catalogue, quality & risk assessment.

3. a. Extract and normalize (CPMAI: Data Preparation)

• Extract texts via connectors/pipelines and/or exports; preserve metadata and structure.
• Normalize into an interchangeable format (segmenting, markup, placeholders, variables).
• Enrich with metadata (linguistic, business, technical) and link to the repository/ repositories.
• De‑duplicate, align bilingual corpora, and apply quality labels.

Deliverables: Unified repository/repositories, metadata schema, enrichment pipelines, quality labels.

3. b. Dig the lake and build pipelines (CPMAI: Data Preparation and Solution Architecture)

• Dig the Language Lake(s): storage, indexing, graph layer, access controls.
• Implement RAG retrieval tuned by domain, market, and tone.
• Configure terminology services and style validators as reusable microservices.
• Establish observability (usage, coverage, drift, quality).

Deliverables: Lake architecture, RAG services, terminology & style APIs, monitoring dashboards.

4. a. Model & generate (CPMAI: Modelling)

• Operationalise prompt frameworks that codify tone, values, and constraints.
• Fine‑tune where proper on IKEA corpora; prefer retrieval grounding to reduce hallucinations.
• Support source‑language flexibility and channel‑aware variants (micro copy vs long‑form).
• Integrate human‑in‑the‑loop review flows with linguists/SMEs.

Deliverables: Generation services, prompt library, evaluation harness, reviewer workflows.

5. Evaluate & ensure quality (CPMAI: Model evaluation)

• Define multi‑layer metrics: fluency, adequacy, terminology adherence, brand tone.
• Mix automatic checks (terminology, grammar, style) with linguistic reviews.
• A/B test against legacy baselines; track impact where measurable.
• Create feedback loops from co‑workers, linguists, and customers into the lake.

Deliverables: Quality scorecards, release criteria, feedback pipelines, test results.

6. a. Deploy & scale (CPMAI: Operationalisation)

• Integrate via APIs into CMS/PIM/service tooling; enable self‑service for teams.
• Roll out progressively: Start with one content source to pilot markets expand to more and make it global; keep track of updates of texts.
• Automate bundles per market.
• Harden security & compliance: data residency, PII handling, audit trails.

Deliverables: Production integrations, rollout plan, runbooks, risk & compliance artifacts.

6. b. Operate, govern, and improve (CPMAI: Monitoring & Continuous Improvement)

• Monitor language coverage, quality drift, and asset freshness.
• Expand the lake with new assets, e.g. other CMS, types of content.
• Periodically recalibrate tone and terminology with brand and markets.
• Measure business impact continuously; retire low‑value legacy flows.

Deliverables: Operational dashboards, governance reviews, quarterly improvement roadmap.

We iterate between step one, two and three in the playbook.

Today, we are at in the data phases. One of GLS consumers were concerned that “the lake might freeze before it gets used”. We are moving slowly as we learn together with our partners. The infrastructure under construction is new to us and to others.

Frame the outcomes

- Evaluate the value proposition:

o Enhanced text generation in an optimised IKEA tone of voice in any language with less human interaction.

o How much better will it be than today and will the ROI be sufficient?

- Reduce the dependency of the Translation Management System and/or relations to siloed third party solutions.

- Generate domain information

- Transition from a solution-based value chain to a data driven one.

- Possibilities to do term extraction of source and target texts.

- Generate texts in existing and new locales.

- Any co-worker should be able to get and generate the texts they need in any language using self-service. (We are IKEA, you know. 😉)

Inventory of our texts

- We explore how to understand the data extracted from files from TMS. What does it look like and for what can we use it?

Extract and normalize & Dig the lake, and build pipelines

- Where will the Language lake give us the most benefits?
- What will the APIs look like?
- How do we combine the Language lake with terminology?

I have one data engineer and one AI-engineer. With this we have been able to explore and learn and develop an MVP for few use cases in phase one to three. Think big, start small, and iterate.

Step four to six are more complex, i.e. the Language generator. These are the easiest ones to rush into and to slip on. The question for me is if we should buy or build? The most important is that we own the data/language assets and the access to it. It is the competitive advantage of IKEA. There is a lot of people and organisations that can do the modelling and generation better than my team.

Follow our process on how we envision the transition in the GIF below, from what we do today to tomorrow.

In the next article(s) my Senior Software (data) engineer and a Field engineer from the Graph data base provider will share what they have done and do in step two and three.

Consider this series of articles as a do it yourself guide on what you can do to embrace the future and change from a cost centre to a value generator.

Liberate your language assets! was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

For years, IKEA navigated a complex landscape of legacy translation technologies and manual processes, often leading to inconsistencies, delays, and resource inefficiencies. Today, IKEA is moving towards a future where AI-driven language generation ensures seamless communication in any language.

The challenge: a multilingual maze

• 70% of Ingka co-workers are only fluent in one language — we need to translate needed material to their language

• Translations are made on top of the job of the co-workers

• There is a vast number of producers of content who require content to be translated

• Coordination is missing between the producers of content and countries

• There is a lack of visibility over translations

• Translations are often overlooked in planning and budgeting

The evolution: from manual to machine-assisted

Recognising these challenges, Global Language Services (GLS) by Group Digital in Ingka Group, an internal IKEA service team, embarked on a mission to modernize language capabilities. The journey began with implementing Machine Translation for the IT Service Desk in 2018, supporting 19 languages within nine months. A key learning from this period was the realisation that existing texts were scattered across various solutions, countries, and agencies, highlighting a significant opportunity for improvement. This led to the rollout of a Translation Management System. GLS also took ownership of a Translation Management System for digital product labels and established governance around it. They developed “IKEA real-time translation,” an AI-powered machine translation service designed to maintain IKEA tone of voice.

GLS implemented solutions to support each use case based on a strategy based on self-service. (We are IKEA, you know. 😉):

IKEA Retail (Ingka Group) translates the intranet, Confluence and other co-worker facing solutions by AI. When there is a need of higher accuracy and/or transcreation a combination of human and artificial intelligence is used.

A key to success has been the change process to bring technology to the many co-workers. This has been guided by the principles below.

The impact of these initiatives has been substantial. GLS supports 45 adapted languages for machine translation and has implemented solutions in 42 countries, demonstrating a strong commitment to democratizing language services and reducing reliance on external translation agencies. This strategic shift has resulted in considerable cost avoidance, with millions of Euros saved annually by leveraging GLS solutions.

It has been an amazing journey in cooperation with Localisations specialists in the markets and our language service providers. We have reached a stage where we have a good combination of human and artificial intelligence. The numbers below show the size of our translation operation managed by ten full-time equivalents.

Still, we are not where we want to be.

One issue is the inconsistency of the translation process across different “customer meeting points”.

Another issue is that IKEA do not effectively capture localised versions of texts to use as a base for further generation of texts into other local languages.

Furthermore, GLS solutions lack the flexibility to easily switch source languages. The nature of the copy itself presented difficulties; it was often hard to translate and automate, with some expressions not having equivalents in many languages.

The sheer number of solutions within the customer journey, all requiring translation, meant that customers engaging with multiple phases on their journey might encounter various language experiences.

The vast number of content producers in several channels make it hard to visualise translation efforts.

Many existing solutions and users not utilising GLS mean they miss out on common processes and centralised text assets.

The future: embracing the language generator powered by the language lake

Looking ahead, Global Language Services vision is ambitious: “To enable IKEA customers and co-workers, to communicate in any language, in every market, in every meeting point” by 2030. The cornerstone of this future is “The Language Generator”, a disruptive concept that re-envisions texts as linguistic assets and data. This approach will leverage AI-generated translation, Generative AI, Knowledge Graph capabilities, and Retrieval Augmented Generation to optimise IKEA’s tone of voice in any language, augmenting human capabilities.

The Language Lake aims to combine and integrate all IKEA language assets, moving away from siloed text management. By extracting validated translations from third-party solutions and applying knowledge graphs, IKEA will create a comprehensive multi-lingual text database with metadata. This will allow for the generation and translation of text that is optimised for IKEA’s tone of voice, making any text available in any IKEA language, and offering customers and co-workers the flexibility to select their preferred language in any interaction.

This future-proof and scalable foundation will simplify architecture, streamline localisation processes, and enable a truly multi-language omnichannel experience. IKEA’s journey from harmonising existing processes to disrupting language handling entirely reflects one of our core-values “Different with a meaning”.

We are at the beginning of this new journey. This is the first article we write sharing our steps towards a future enabling a seamless multilingual communication for co-workers and customers.

From flat pack to fluid language: IKEA’s journey to seamless multilingual communication was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you, like me, are new to the AI Agents world, you probably heard about LangChan and LangGraph. The thing is: if you didn’t have time before to learn more about these tools, you may be uncertain about what each one is and when to use it.

LangChain has become the go-to framework for chaining LLM calls with other components like APIs, databases, and document stores. It allows developers to move beyond simple prompts and build sophisticated, data-aware applications.

However, as applications become more complex, the simple, linear nature of LangChain’s “chains” can become a limitation. What if you need your application to loop, make decisions, and operate more like an autonomous agent?

This is where LangGraph comes in. It’s not a replacement for LangChain but a powerful extension built by the same team, designed specifically for creating complex, stateful, and cyclical applications.

Let’s dive into the core differences, see them in action with code, and understand them.

Requirements

If you want to run the code examples on your machine, you’ll need the following dependencies:

• Python 3.8+
• Ollama installed and running

By leveraging Ollama, you can build and test these powerful patterns privately and cost-effectively on your hardware.

I use Visual Studio Code to type code, and its installed extensions already satisfy the needs for working with Python.

If you don’t know how to run the code examples, we have a session for doing it after the code.

The Power of Sequential Chains: LangChain

At its core, LangChain is designed to create Directed Acyclic Graphs (DAGs). Don’t let the term intimidate you. It simply means you are building a sequence of steps that flows in one direction, without loops. Think of it as a factory assembly line: an input goes in one end, passes through a series of stations, and a final output comes out the other end.

This structure is perfect for predictable, sequential tasks. A classic example is a Retrieval-Augmented Generation (RAG) pipeline:

Receive a user’s question. Fetch relevant documents from a database. “Stuff” the context from those documents into a prompt. Send the prompt to an LLM to generate an answer.

If you don’t know what RAG is, you can check this post: Understanding the RAG Pattern with LLMs.

LangChain Code Example: A Simple RAG Chain

This example creates a simple RAG chain that answers questions based on a small piece of provided text, using Ollama to run both the chat model and the embeddings model locally.

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough
from langchain_community.vectorstores import FAISS
from langchain_ollama import ChatOllama, OllamaEmbeddings

# 1. Set up the LLM and Embeddings model using Ollama
# Make sure Ollama is running with the required models:
# ollama pull llama3
# ollama pull nomic-embed-text
llm = ChatOllama(model="llama3")
embeddings = OllamaEmbeddings(model="nomic-embed-text")

# 2. Create a simple text source and Vector Store
text_chunks = [
    "LangGraph is a library for building stateful, multi-actor applications with LLMs.",
    "It extends the LangChain ecosystem and enables creating cyclical graphs.",
    "LangChain is primarily used for creating linear sequences of LLM calls (chains).",
    "You can use LangChain Expression Language (LCEL) to compose these chains."
]
# Create a vector store from the text chunks
# This will index the text chunks and allow for efficient retrieval
vectorstore = FAISS.from_texts(texts=text_chunks, embedding=embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 2})

# 3. Create a Prompt Template
template = """
Answer the question based only on the following context:
{context}
Question: {question}
"""
prompt = ChatPromptTemplate.from_template(template)

# 4. Build the RAG Chain using LCEL
retrieval_chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

# 5. Invoke the chain
question = "What is LangGraph used for?"
response = retrieval_chain.invoke(question)
retrieval_chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

print("Question:", question)
print("Answer:", response)

question_two = "What is the main feature of LangChain?"
response_two = retrieval_chain.invoke(question_two)

print("\nQuestion:", question_two)
print("Answer:", response_two)

You can play with the text_chunks to see how things work.

When Chains Aren’t Enough: LangGraph

Complex tasks require reflection, tool usage, and decision-making. This requires loops and conditional logic, something a simple Directed Acyclic Graph (DAG) cannot handle. LangGraph models the application as a stateful graph, where nodes represent functions and edges define the next step based on the current state.

LangGraph Code Example: A Local Agent with a Tool

This example builds an agent that can decide whether to use a “search” tool or respond directly to the user. The logic is driven entirely by a local llama3 model running in Ollama.

import operator
from typing import Annotated, TypedDict, List
from langchain_core.messages import BaseMessage, HumanMessage, AIMessage
from langchain_ollama import ChatOllama
from langgraph.graph import StateGraph, END

# 1. Define the agent state
class AgentState(TypedDict):
    messages: Annotated[List[BaseMessage], operator.add]

# 2. Define the graph nodes
# 2.1 Main node that calls the LLM
def call_model(state: AgentState):
    """Main node that calls the LLM."""
    print("---CALLING MODEL---")
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

# 2.2 Tool node (mock)
def call_tool(state: AgentState):
    """Simulated tool node."""
    print("---USING TOOL---")
    tool_response = HumanMessage(
        content="The latest report indicates a 15% increase in market share. What should I do next?",
        name="tool_output"
    )
    return {"messages": [tool_response]}

# 3. Conditional logic to decide the next step
def should_continue(state: AgentState) -> str:
    """
    Decides the next step. If the last LLM message includes 'search',
    calls the tool. Otherwise, ends the process.
    """
    print("---ASSESSING NEXT STEP---")
    last_message = state["messages"][-1]
    if isinstance(last_message, AIMessage) and "search" in last_message.content.lower():
        print("DECISION: Use Tool")
        return "tool"
    else:
        print("DECISION: End")
        return END

# 4. Build the state graph
# Make sure Ollama is running with the 'llama3' model pulled.
# ollama pull llama3
llm = ChatOllama(model="llama3", temperature=0)
# Define the workflow using StateGraph
workflow = StateGraph(AgentState)
workflow.add_node("agent", call_model)
workflow.add_node("tool", call_tool)
workflow.set_entry_point("agent")
workflow.add_conditional_edges(
    "agent",
    should_continue,
    {"tool": "tool", END: END},
)
workflow.add_edge("tool", "agent")
app = workflow.compile()

# 5. Run the graph with examples
def print_message_output(output):
    """
    Pretty print the output for the user, showing only the message content in a readable way.
    """
    messages = output.get('messages', [])
    for msg in messages:
        role = msg.__class__.__name__
        print(f"[{role}]\n{msg.content}\n")

## EXAMPLE 1: Agent decides to end immediately
inputs_1 = {"messages": [HumanMessage(content="What is the weather in Madrid?")]}
for output in app.stream(inputs_1, {"recursion_limit": 5}):
    for key, value in output.items():
        print(f"Output from node '{key}':\n---")
        print_message_output(value)
        print("---\n")

## EXAMPLE 2: Agent decides to use a tool
inputs_2 = {"messages": [HumanMessage(content="I need the latest market report. Can you perform a search?")]}
for output in app.stream(inputs_2, {"recursion_limit": 5}):
    for key, value in output.items():
        print(f"Output from node '{key}':\n---")
        print_message_output(value)
        print("---\n")

The function print_message_output is not necessary for running the model. I just added it here to make the output a bit more legible for us.

You can play with the inputs_1 and inputs_2 to check how the application will work.

How to Run the Examples

Step 1: Download the Local Models

Open your terminal and pull the models we’ll be using from Ollama’s registry. The nomic-embed-text model is for generating embeddings (vectorizing text), and llama3 is our chat model.

You can use the Visual Studio Code Terminal to do it.

ollama pull llama3
ollama pull nomic-embed-textcopy

Step 2: Create a Project Folder and Virtual Environment

It’s good practice to isolate your project’s dependencies. Virtual Env will help us isolate it.

On your opened terminal, type the following commands (one by one, please):

mkdir langchain-langgraph-examples
cd langchain-langgraph-examples
python -m venv venv
source venv/bin/activate  # On Windows, use `venv\Scripts\activate`copy

Step 3: Install Required Libraries

Install all the necessary packages. Note that we are installing langchain-ollama instead of the OpenAI-specific library, like we usually find in the documentation and blog post examples.

pip install langchain langchain_core langchain_community langgraph faiss-cpucopy

Step 4: Run the Code

Save each code block into its respective .py file (langchain_ollama_example.py and langgraph_ollama_example.py). Then, run them from your terminal.

Make sure the Ollama application is running first.

# Run the LangChain example
python langchain_ollama_example.py

# Run the LangGraph example
python langgraph_ollama_example.pycopy

You will see the output printed to your console, showing how each framework processes the requests using your local models.

Conclusion: Which One Should You Use?

To be direct:

• Use LangChain for building predictable, sequential workflows. It’s perfect for RAG, summarization, and other tasks that follow a clear, linear path.
• Use LangGraph when you need your application to reason, plan, and loop. It’s the right choice for building complex agents, multi-step conversational models, or any process that requires dynamic, state-driven execution.

References

• LangChain Documentation: https://python.langchain.com/
• LangGraph Documentation: https://langchain-ai.github.io/langgraph/
• Ollama: https://ollama.com/

Originally published at https://woliveiras.github.io on June 27, 2025.

LangChain vs. LangGraph: From Simple Chains to Complex AI Agents was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

At IKEA, we set out to create a Card component that balances accessibility, style, and flexibility. Not just one Card, but several – similar in structure, yet distinct in purpose. Here’s how we approached it.

At first glance, a Card seems straightforward –a layout with a title, a label, a body and maybe an image. Easy, right? Not quite. Not at IKEA.

More than just a box

Because our Card component is used across many teams and contexts, we needed something far more robust. It had to be flexible, highly customisable, and fully accessible. More than just a content container, it needed to be scalable, a component that could adapt to a wide range of use cases – without compromising on design or accessibility.

Research, iteration, and collaboration

From the start, we worked closely with our product teams to iterate, gather feedback, and refine our components.

At IKEA, the design system team values continuous dialogue. Product teams – our end users – bring invaluable insights and data that help us improve and adapt. While we know we can’t meet all teams’ needs, aiming for 80% coverage is a more realistic goal for a new component.

Real-world testing is a cornerstone of our process. We partnered with several product teams to understand their challenges, needs, and expectations for the new Card components.

What even is a Card? 🤔

Our research revealed that the term Card means just about anything. And we do mean anything. We encountered everything from simple surfaces with a centered icon to non-clickable containers – all labelled “Card.” The definition had become so broad that it covered a wide range of interpretations, regardless of structure, interactivity, or content.

Clearly, we needed to bring clarity and consistency.

Our solution 💡

The existing version of our Card was stable and reusable. Teams could simply provide content, and the component handled the rest.

But as more use cases emerged, we realised background colour and more flexible layout options for content was a key factor for adoption. Different scenarios, market requirements and image content required different visual treatments. So, we introduced Card themes to extend the available brand colours that existed in the current Card component – predefined combinations with clear usage guidelines from the IKEA brand team.

To support even more alternatives, we also added an extended colour palette – a curated set of approved colours that maintain brand consistency while allowing teams to adapt to their needs. Since all colours are connected to the design system tokens – all components support dark and light mode automatically.

Media container — adding more interactive content

Teams needed to support video playback, badges, commercial messages, and even shoppable image marker – all within the same space. So, the media container evolved from being a simple image slot into a dynamic, flexible canvas for rich, interactive content – without breaking the design.

Accessibility-first design: Behind the scenes of the new Card development

Working on the new Card component was a truly insightful journey, especially when it came to accessibility. Since there’s no official pattern for Card components, we explored a wide range of community suggestions, best practices, and real-world implementations. This process helped us craft a solution tailored to our needs while staying true to inclusive design principles.

One of the most interesting challenges was achieving the correct keyboard interaction. To do this, we had to restructure the layout in our web implementations – a decision driven entirely by accessibility requirements. This change ensured that users navigating via keyboard could interact with the component in a logical and intuitive way.

The development process was highly collaborative. We prototyped and tested the component with several teams across IKEA, including vision impaired colleagues and members of the Accessibility team. Their feedback was invaluable in shaping a component that is not only functional and beautiful but also truly inclusive.

Compact card: Simpler by design

We also saw the need for a simpler variant – something lightweight for basic content and navigation. That’s how the Compact Card was born: a streamlined component offering a clear entry point to more detailed information but taking less screen estate.

Text overlay card: Designed for expression and saving vertical space

After several requests a trending pattern emerged among product teams – cards with text on top of an image. To ensure consistency across product and services we introduced the Text overlay card — a card version aligned with product team’s needs – fulfilling accessibility requirements for a good text contrast.

With multiple gradient overlay levels that grows with the size of the text, text contrast is no longer a limitation. This version is currently in an experimental phase, and we’re excited to announce a new sub-variant: integration with our video player component.

This addition supports evolving market needs and enhances the storytelling potential of our Cards.

Rollout and adoption

Back in October 2024, our existing card component averaged around 106,000 package downloads per month across React, Vue, and Web Components. With such widespread usage –particularly among heavy users like our global CMS for content creators, internal tools, and product teams — we anticipated that adoption of the new card components would take time.

Previously, our support of the Card component was limited to React, Vue, and Web Components. However, with the latest release, we’ve expanded to include iOS and Android. This marks a significant step towards achieving a cohesive look and feel across all platforms and services, while also simplifying future updates.

As of late August 2025, we’ve reached an adoption rate for web of over 80% for the new card component. At this scale, adoption is a gradual process –and that’s perfectly normal.

We always release an alpha version in both code and Figma (our design tool) to catch bugs early and gather feedback before the official launch. This approach is a key reason why feature releases from the design system team may take a bit longer. It’s a deliberate process, focused on quality and collaboration.

A design system is a living organism – it evolves with its users. And we’re committed to evolving with it. The Card journey is far from over. We’ll continue refining and expanding based on your feedback.

Stay tuned for more updates in our next post!

Written by:
Aleksandar Ilic, Senior Android Engineer
Ivan Sofeski, Senior Software Engineer
Jonatan Grönkvist, Senior Design System Designer
Skapa | IKEA digital design system

IKEA – a house full of cards was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.