A writer at Livingetc recently made a confession I found weirdly relatable: she doesn’t DIY her IKEA furniture anymore. She lets other brands do it for her. There’s a whole cottage industry of companies that sell the fronts, legs, and handles designed to bolt onto IKEA carcasses, and she’d rather buy the finished result than spend a Saturday with a hex key and a tube of wood glue.
My first reaction was mild judgment. My second reaction was recognizing myself in it, because I do the exact same thing with bots. I don’t hand-roll a retry queue anymore. I don’t write my own vector index. I buy the front panel and bolt it on.
The IKEA hack scene is having a moment. Apartment Therapy just rounded up ten places to shop for parts. Man of Many published sixteen of the best hacks. The Spruce collected eighteen ways to turn a glass display cabinet into a houseplant greenhouse. Dengarden has a DIYer walking through four tricks to make cheap furniture read as expensive. That’s a lot of energy pointed at furniture nobody designed to be modified.
And the reason it works is the same reason good bot architecture works. It’s not the quality of the materials. It’s the interfaces.
Standard holes are the whole trick
IKEA’s real product isn’t particleboard. It’s a dimensional system. Predictable widths, predictable hole spacing, predictable cam locks. Once thousands of people know the spacing, a third party can manufacture a door that fits without ever talking to IKEA. The hack economy exists because the interface is stable and boring.
Most bot projects fail this test. People build a system where the retrieval layer knows the shape of the prompt template, the prompt template knows which model provider it’s hitting, and the logging assumes a specific response schema. It’s a bespoke cabinet, joined with glue. It looks fine until you want to swap one model for another and discover you’re rebuilding the whole thing.
The fix is unglamorous. Define the seams before you build:
- One shape for a message in and a message out, regardless of which provider answers
- One shape for a retrieved document, so you can swap the store without touching the prompt
- One shape for tool calls, so adding a tool is a registration, not a refactor
- One place where secrets and model names live, so config changes don’t become code changes
None of that is clever. It’s hole spacing. But it’s what makes everything downstream hackable.
The greenhouse cabinet principle
My favorite item on that list is the greenhouse cabinet. Somebody looked at a glass display case meant for showing off ceramics, sealed it up, added light and humidity, and grew tropical plants in a cold apartment. IKEA didn’t design for that. The cabinet just happened to have the properties that mattered: transparent, enclosed, cheap enough to risk.
That’s how most of my useful bots got built. Not from a spec, but from noticing that a component I already had did something adjacent to what I needed. A cron job plus a scraper plus a summarizer isn’t an agent framework, but it monitors a competitor’s changelog just fine. A Discord bot’s message handler is a perfectly good request queue if your traffic is low. The trick is looking at what a component actually does rather than what its documentation says it’s for.
The failure mode is the opposite instinct, which is reaching for the heavy framework first because the demo looked impressive. That’s buying a whole new cabinet when you needed to seal the one you had.
Make it look expensive
The Dengarden piece is about four tricks to make budget furniture read as premium. Better handles. Painted edges. Legs. Filling the visible seams. Structurally nothing changed. Perceptually, everything did.
Bots have the same surface layer, and builders skip it constantly. A working bot with no streaming, no typing indicator, no graceful error message, and no memory of the last three turns feels broken even when it isn’t. Add streaming and the same latency feels fast. Add a real error message instead of a stack trace and users trust it. Add a light state so it remembers context, and it feels like software instead of a demo.
These are handles and legs. They’re cheap to add and they change how the whole thing reads.
Know when to buy the door
Which brings me back to the Livingetc confession. Buying a pre-made front instead of building one isn’t a failure of craft. It’s a decision about where your Saturday goes.
My rule is that I’ll build the part that makes my bot different and buy everything else. The orchestration logic that encodes how I want a task decomposed, that’s mine. Auth, queueing, vector search, observability, rate limit handling: those are doors. Somebody else already made them fit standard holes.
The people posting IKEA hacks aren’t furniture makers. They’re editors of a system somebody else standardized, and the good ones know exactly which pieces are worth their own labor. That’s the skill worth stealing.
🕒 Published: