I once spent three weeks building a custom CSS framework.
It had exactly the features I wanted. Perfect naming conventions. Elegant utility classes. Beautiful documentation.
I showed it to my team. They said, “Why not just use Tailwind?”
My response? “Because mine is better.”
Was it actually better? No. Objectively, Tailwind had:
- More features
- Better documentation
- Larger community
- More battle-testing
- Active maintenance
But I couldn’t see that. All I could see was MY framework, MY design decisions, MY time invested.
I overvalued it simply because I built it.
This is the Ikea Effect: we place disproportionately high value on things we’ve partially created, assembled, or customized ourselves.
And it’s costing you more than you think.
What is the Ikea Effect?
The Ikea Effect was formally identified in a 2011 study by Michael Norton, Daniel Mochon, and Dan Ariely.
The experiment:
Participants were divided into two groups:
Group 1: Builders
- Given Ikea furniture
- Assembled it themselves
- Asked to value it
Group 2: Non-builders
- Shown pre-assembled identical furniture
- Asked to value it
Results:
Builders valued their self-assembled furniture 63% higher than non-builders valued the identical pre-assembled furniture.
The builders literally thought their furniture was worth more because they built it.
The Follow-Up Studies
The researchers ran more experiments:
Experiment 2: Origami
- Participants folded origami
- Asked to value their creation
- Other participants valued the same origami
Result: Builders valued their ugly origami nearly as much as expert-made origami. Non-builders correctly saw it as ugly and worthless.
Experiment 3: Ikea Boxes
- Some participants completed the Ikea box
- Some participants had to stop halfway (incomplete)
- Asked to value their work
Result: Only completed boxes showed the Ikea Effect. Incomplete work wasn’t overvalued.
Key insight: The effect requires a sense of completion. You have to finish to become irrationally attached.
Why the Ikea Effect Happens
Several psychological mechanisms drive this:
1. Effort Justification
The psychology:
Your brain justifies effort by inflating the value of the outcome.
“I spent three weeks on this. Therefore, it must be valuable.”
The logic error:
Time spent ≠ value created
But our brains struggle to accept that effort can be wasted.
2. The Endowment Effect
The principle:
Once you own something, you value it more highly than before you owned it.
In the Ikea Effect:
You “own” something even more intensely when you’ve invested effort in creating it.
Example:
A chair you bought: valued moderately
A chair you assembled: valued higher
A chair you built from scratch: valued irrationally high
3. Competence and Mastery
The psychology:
Creating something successfully makes you feel competent.
That good feeling gets associated with the object itself.
Result: You overvalue it because it represents your competence.
4. Identity Investment
The mechanism:
What you build becomes part of your identity.
Criticizing your creation feels like criticizing you.
Example:
“This code is hard to read”
Your brain hears: “You’re not a good developer.”
So you defend the code, even when it’s objectively bad.
5. Sunk Cost Fallacy’s Cousin
The connection:
The Ikea Effect and sunk cost fallacy are related.
Both involve overvaluing things because you’ve invested in them.
Sunk cost: “I’ve already invested X, so I can’t quit.”
Ikea Effect: “I’ve already invested X, so this must be valuable.”
The Ikea Effect in Software Development
Let me show you where this shows up:
Example 1: The NIH Syndrome (Not Invented Here)
The pattern:
You need a solution to a problem. Open source libraries exist.
The Ikea Effect kicks in:
“I could just build my own. It’ll be better because I’ll make it exactly how I want.”
What actually happens:
You spend weeks building something that already exists.
Your version has:
- Fewer features
- More bugs
- No community support
- No maintenance
- Only you understand it
But you overvalue it because YOU built it.
Real example:
I built a custom logging library instead of using Winston.
My reasoning: “Winston is bloated. Mine is simpler.”
Reality: Winston has 100+ contributors, handles edge cases I never considered, and is actively maintained.
My logger? Broke in production when I needed structured logging. Spent a week adding features Winston already had.
The Ikea Effect blinded me to the obvious: just use the battle-tested library.
Example 2: The Hand-Rolled Authentication
The scenario:
You need authentication for your app.
Options:
- Use Auth0, Clerk, or NextAuth (tried, tested, secure)
- Build your own (exciting, customizable, “I’ll learn from it”)
The Ikea Effect:
“I’ll build my own. How hard can auth be?”
What actually happens:
- Week 1: Basic auth working! Feels great!
- Week 2: Add password reset
- Week 3: Add OAuth
- Week 4: Security audit reveals 5 vulnerabilities
- Week 5: Add 2FA
- Week 6: Still missing features that Auth0 has out of the box
But you can’t admit this is a bad idea because you’ve invested six weeks.
You defend your custom auth:
“But it’s exactly tailored to our needs!”
Reality: Your needs are the same as everyone else’s needs, and Auth0 handles them better.
Example 3: The Precious Codebase
The pattern:
You wrote the original codebase two years ago.
Now other developers want to refactor it.
Your reaction:
Defensive. Protective. Resistant.
Why?
It’s YOUR code. You built it. The Ikea Effect makes you overvalue it.
What you say:
“The current architecture is fine. We don’t need to change it.”
What you mean:
“This is MY architecture. Changing it feels like admitting I made mistakes.”
The cost:
Technical debt accumulates because you can’t objectively evaluate your own work.
Example 4: The Custom Tool
The scenario:
You build a CLI tool to automate your workflow.
What it does:
Saves you ~10 minutes per day.
Time invested:
40 hours to build, 5 hours/month to maintain.
ROI:
10 min/day × 20 workdays = 200 min/month saved = 3.3 hours/month
Cost: 5 hours/month maintenance
Net: -1.7 hours/month. You’re losing time.
But the Ikea Effect says:
“This tool is amazing! I built it! It’s perfect for my workflow!”
Reality:
A generic tool (Make, Gulp, npm scripts) would’ve taken 2 hours to set up and 0 hours to maintain.
Example 5: The Side Project You Won’t Kill
The scenario:
You built a SaaS product. It has 10 users. No revenue. No growth for 6 months.
The rational decision:
Shut it down. Build something else.
The Ikea Effect:
“But I built this! It’s good! The market just doesn’t understand it yet!”
What you’re really saying:
“I can’t admit that my creation isn’t valuable.”
The cost:
You keep maintaining it, paying hosting costs, thinking about it, instead of moving on to something better.
The Cost of the Ikea Effect
This isn’t just ego. It has real consequences:
Cost 1: Wasted Time
Building things that already exist:
Every hour spent rebuilding a library is an hour not spent on unique value.
Maintaining things that should be killed:
Every hour maintaining your custom framework is an hour not spent on your product.
Cost 2: Lower Quality
Why:
Your custom solution has:
- One developer (you)
- Less testing
- Fewer edge cases considered
- No community finding bugs
Pre-existing solutions have:
- Hundreds of contributors
- Years of testing
- Production-hardened
- Active community
But the Ikea Effect makes you think yours is better.
Cost 3: Team Friction
The pattern:
You defend your code against all criticism.
Your team can’t improve the codebase because you’re too attached.
Result: Team avoids giving you feedback, code quality degrades, velocity slows.
Cost 4: Missed Opportunities
While you’re:
- Building your custom auth
- Maintaining your custom logging
- Defending your precious architecture
You’re NOT:
- Building features users want
- Talking to customers
- Shipping faster
Opportunity cost is real.
Cost 5: Bad Product Decisions
The trap:
You build a feature because YOU think it’s cool.
Users don’t care.
But you can’t kill it because you built it (Ikea Effect).
Result: Bloated product with features nobody uses.
How to Combat the Ikea Effect
You can’t eliminate the bias, but you can defend against it:
Defense 1: Separate Builder from Evaluator
The problem:
If you built it, you can’t objectively evaluate it.
The solution:
Have someone else evaluate it who didn’t build it.
Practical implementation:
For code: Mandatory code review by someone who didn’t write it.
For features: User testing by people who didn’t design it.
For products: Customer interviews by someone not emotionally invested.
For architecture decisions: Bring in an outside consultant or experienced developer.
Why this works:
They don’t have the Ikea Effect. They can see clearly.
Defense 2: Define Success Criteria Upfront
The problem:
After building, you move the goalposts to justify the effort.
The solution:
Define success before you build.
Example:
Before building custom auth:
“I’ll build custom auth IF:
- It takes less than 20 hours
- It has feature parity with Auth0
- It’s more secure than off-the-shelf
- It saves money at our scale”
After building:
Check the criteria honestly.
If you didn’t meet them: Kill it. Use Auth0.
No exceptions. The criteria were set before the Ikea Effect kicked in.
Defense 3: Track Time and Value
The practice:
Track time spent building AND value delivered.
Example:
Custom logging library:
- Time spent building: 30 hours
- Time saved vs. using Winston: 0 hours
- Bugs introduced: 3
- Features missing: structured logging, log levels, transports
Value: Negative.
Winston:
- Time to integrate: 2 hours
- Time saved: 28 hours
- Bugs: 0 (it’s battle-tested)
- Features: All of them
Value: Positive.
When you see it in numbers, the Ikea Effect loses power.
Defense 4: The “Would I Buy This?” Test
The question:
“If someone else built this, would I pay for it?”
For code:
“If this were a library on npm, would I use it over existing alternatives?”
For products:
“If this weren’t my product, would I pay the asking price?”
For features:
“If I were a user, would I actually use this feature?”
If the answer is no, you’re overvaluing it because of the Ikea Effect.
Defense 5: Forced Justification to a Skeptic
The exercise:
Explain to a smart, skeptical person why your solution is better than the alternative.
Rules:
- They’re allowed to challenge you
- You must provide objective evidence
- “I built it” is not evidence
- “I spent time on it” is not evidence
What usually happens:
You realize you can’t actually justify it objectively.
That’s the Ikea Effect being exposed.
Defense 6: The “Start from Scratch” Thought Experiment
The question:
“If I were starting this project today, with zero code written, what would I choose?”
Example:
Current state: You have a custom CSS framework with 10,000 lines.
Start from scratch: Would you build a custom framework, or use Tailwind?
If you’d choose differently starting fresh, the Ikea Effect is clouding your judgment.
Defense 7: Kill Your Darlings
The practice:
Regularly delete things you built.
Why:
Proves to yourself that you CAN let go.
Reduces attachment to your creations.
Implementation:
Monthly code cleanup:
- Delete unused functions
- Remove features with <5% usage
- Archive old projects
- Refactor code you wrote years ago
The goal: Practice non-attachment.
Using the Ikea Effect Positively
The effect isn’t all bad. You can leverage it:
Positive Use 1: Increase User Investment
The principle:
Users who customize your product will overvalue it (Ikea Effect) and be more likely to stay.
Examples:
Notion: Users build their own workspace → Ikea Effect → Hard to leave
VS Code: Users customize extensions, keybindings, themes → Ikea Effect → Loyal users
Slack: Users set up channels, integrations, workflows → Ikea Effect → Sticky product
The design principle:
Let users “build” part of your product. They’ll value it more.
Positive Use 2: Increase Learning Retention
The principle:
Learning by doing (building) creates deeper retention than passive learning.
Why:
Partly because the Ikea Effect makes you value what you built, which increases motivation to remember it.
Example:
Passive: Read documentation about React hooks
Active: Build a small app using React hooks
Result: The app you built (Ikea Effect) makes you remember the concepts better.
Positive Use 3: Team Buy-In
The principle:
If your team helps design the solution, they’ll be more invested in its success (Ikea Effect).
Example:
Top-down: “We’re using this architecture. Here’s the spec.”
Result: Team resistance, half-hearted implementation.
Collaborative: “Let’s design the architecture together.”
Result: Team has ownership (Ikea Effect), better implementation.
Positive Use 4: Motivation for Learning
The principle:
Building something makes you value the learning process more.
Example:
Learning React:
Passive: Read 5 tutorials
Result: Bored, low retention
Active: Build a small project while learning
Result: Ikea Effect makes you value the project → Increased motivation → Better learning
When the Ikea Effect Is Justified
Sometimes building IS the right choice:
Justified Case 1: Unique Requirements
When building makes sense:
Your requirements are genuinely unique and no existing solution fits.
Example:
Netflix building their own CDN (no existing CDN could handle their scale and specific needs).
How to verify:
Can you list 3 specific requirements that NO existing solution meets?
If yes: maybe build.
If no: Ikea Effect is lying to you.
Justified Case 2: Learning Goals
When building makes sense:
Your goal is to learn, not to ship quickly.
Example:
Building your own mini-React to understand how React works.
The key: Be honest that this is for learning, not production.
Justified Case 3: Core Differentiator
When building makes sense:
The thing you’re building is your core competitive advantage.
Example:
Google building their own search algorithm (that’s literally their business).
How to verify:
Is this the thing that makes your product unique?
If yes: build it.
If no: use existing solutions and focus on what actually differentiates you.
Justified Case 4: Economics
When building makes sense:
The ROI is genuinely positive.
Example:
Large company building internal tools because off-the-shelf costs $1M/year and custom costs $200k one-time.
How to verify:
Do the actual math. Include maintenance costs.
If the numbers work: build.
If you’re fuzzy on the numbers: probably Ikea Effect.
Real-World Ikea Effect Examples
Positive Example: Lego
Why Lego is so successful:
Users BUILD their creations → Ikea Effect → Overvalue their Lego builds → Keep buying more Lego.
The genius:
The product IS the Ikea Effect. That’s the entire business model.
Negative Example: Quibi
What happened:
Jeffrey Katzenberg spent $1.75 billion building Quibi.
It failed spectacularly.
Why he couldn’t see it:
Ikea Effect. He built it. He was too close to it.
Everyone else could see it was doomed.
The lesson:
Even smart, experienced people fall for the Ikea Effect.
Negative Example: Microsoft Zune
What happened:
Microsoft saw the iPod’s success.
Built their own MP3 player.
Poured resources into it.
It failed.
Why they kept going:
Ikea Effect + sunk cost fallacy.
They built it, so it must be good, so let’s keep investing.
The lesson:
Sometimes the right move is to admit defeat and stop building.
Final Thoughts: Build Less, Ship More
Here’s what I’ve learned after years of falling for the Ikea Effect:
The best developers aren’t the ones who build everything from scratch.
They’re the ones who know when to build and when to use existing solutions.
Rules I follow now:
-
Default to existing solutions. Only build if I can objectively justify it.
-
Set success criteria before building. Check them honestly after.
-
Get external feedback early. Before the Ikea Effect makes me too attached.
-
Track time and value. Numbers don’t lie.
-
Kill things regularly. Practice letting go.
-
Separate identity from creations. My code isn’t me.
The Ikea Effect wants you to believe everything you build is valuable.
The market decides what’s valuable. Not you.
I learned this the hard way with:
- Custom frameworks nobody used
- Features nobody wanted
- Tools that saved negative time
- Projects that should’ve been killed months earlier
Each time, the Ikea Effect told me: “But you built this! It must be good!”
Each time, the market said: “We don’t care who built it. It’s not valuable.”
The market was right. The Ikea Effect was wrong.
So now when I catch myself saying:
“But I built this…” “But I spent weeks on this…” “But this is better because I made it…”
I stop.
I ask: “Would I use this if someone else built it?”
If the answer is no, I delete it and move on.
Because the goal isn’t to build things.
The goal is to build things people actually value.
And the Ikea Effect is terrible at distinguishing between the two.
What are you overvaluing because you built it? What would you do differently if you were starting from scratch today? Let me know—I’d love to hear your Ikea Effect stories.