Daniel's got a whole thing this week about shopping lists, and I want to start with the detail that stuck with me. He and Hannah are two busy professionals with a young kid, and at any given moment there's a small pile of things they need. Drywall anchors from the hardware store. Cotton swabs from the pharmacy. Groceries, cleaning products, a couple of plywood boards. And he's found that Bring works beautifully for groceries, but the moment he tries to put a plywood board in there, the whole model falls apart.
Because Bring doesn't know what a plywood board is.
Right, and that's the crack. He's also got an IKEA list, and every trip to IKEA is the same story. They spend the whole visit trying to remember the backlog of small parts they needed, and they end up buying things they didn't need and forgetting the things they did. So his actual question is whether there's an app or a system that's purpose-built for this, or something that could be sculpted into it. He's thought about Home Assistant but finds it overly complicated. He's thought about a task manager but suspects the use case is specific enough that something more targeted exists. And his own instinct is that the right answer is a data model. One schema for groceries, another for hardware, a few lists on top. He and Hannah are both on Android with laptops, and they're almost done unboxing the apartment, so time is the scarcest resource.
The unboxing detail matters. This is the worst moment to be designing a system, because the system has to work immediately, with zero learning curve, for two exhausted people.
So today we're asking what actually happens when your shopping list outgrows the grocery store.
And I think the honest first observation is that this is not a list-making problem at all. It's a distributed cognition problem for a household. Two people, each with partial knowledge of what the house needs, and the system has to capture needs at the moment they arise and retrieve them at the moment they're actionable. The retrieval context is the hard part, because the action moment is almost never at home. It's when one of them is out, near a shop, with twenty minutes to spare.
Daniel's phrase for that is worth holding onto. Any trip where either person is out of the house and near shops is a chance to get what the other person needs. That's the crux. It means the list cannot be organized by category. It has to be organized by store, because the trigger is proximity to a store, not proximity to a category.
And that's the thing most list apps get backwards. They're built around what the item is. Milk goes with dairy. Sandpaper goes with, I don't know, abrasives. But the person standing outside the pharmacy doesn't care what category cotton swabs belong to. They care that cotton swabs are the one thing on the pharmacy list.
Daniel's data model instinct is sound, by the way. Separate schemas for groceries versus hardware makes sense because the fields are different. A grocery item has a quantity and maybe a brand preference. A hardware item has a size, a gauge, a thread pitch, a material. An IKEA item has an article number and a warehouse location. These are not the same object.
But the deeper question is whether any existing tool treats store as a first-class organizing principle across all those domains. And I don't think one does. So let's trace the arc. First, why Bring fails in this exact way. Then the landscape and the data model approach. Then whether building your own with an AI is actually viable now. And Hilbert will have a physical-world angle that changes the frame.
Start with what Bring gets right, because that tells us what's missing everywhere else.
Bring's core strength is that adding an item is tapping an icon, not typing a word. The catalog is visual, it's fast, it's almost fun. A MakeUseOf review described it as solving family grocery chaos through shared real-time lists. And the shared part is good. Two people, one list, changes sync in real time. For the narrow job of getting groceries into a shared list and checking them off, Bring is about as good as it gets.
And Daniel's claim that it doesn't flex to other domains needs one correction before we go further, because it changes the diagnosis.
Yes. Bring does support multiple lists. Its own feature page says you can create multiple lists and organize them specifically for each store or event. So the limitation is not the list structure. Daniel could absolutely create a hardware store list and an IKEA list inside Bring. The problem is everything around the list structure.
The icon catalog, the auto-categorization, the loyalty card storage, the entire user experience assumes a grocery context. Type drywall anchors into Bring and you get no icon, no sensible category, no auto-sorting. It sits there as raw text in a sea of cheerful produce icons. The app doesn't know what to do with it.
And that's the tell. The moment the app can't map an item to its grocery taxonomy, the speed advantage collapses. You're back to typing, and if you're typing anyway, a notes app does the same job with less friction.
There's a second layer, and it's the monetization. Bring is free because it's not really a list app. It's a marketing platform. The SmartCart Family comparison from last November put it bluntly. Bring is honest about what it is, a marketing platform disguised as a list app. But its users believe it's a tool for them. It is not.
Nestlé, Unilever, Carrefour. Those are the customers. The user is the inventory. And that structural fact means Bring will never add price tracking or budget features, because those would compete with the ad model. The ads want you to buy specific brands, not the cheapest version of a thing.
So the free app trap isn't just about privacy. It's about which features can never exist.
And there's a concrete failure mode that should worry any two-parent household. An App Store review documented a sync bug where if both partners add the same item to a shared list, the app removes the entry rather than duplicating it. Two people, both notice they're out of milk, both add milk, and the milk vanishes from the list entirely.
That's the kind of bug that doesn't just lose you an item. It loses you trust in the tool. The moment you have to double-check whether the list actually contains what you both added, the cognitive load is worse than not having the app at all.
And the broader landscape doesn't rescue the multi-domain case. Listonic has ten million downloads and does real-time sharing and aisle sorting, but its cookie policy lists nine hundred forty-six partner companies with data access, some retaining data for ten years. Ten years. Your shopping history outlives your phone, your car, probably your relationship with that grocery store.
AnyList is widely considered the technical best, but it's iOS-first and the Android version is clearly inferior. Daniel and Hannah are on Android. It also only supports English and German. OurGroceries is simple and effective, six dollars a year to remove ads, but users have begged for price tracking for three years with no response.
The newer entrants are interesting. LastList spans Walmart, Kroger, Best Buy, Instacart and organizes by aisle. TickLists does store-specific aisle ordering. ShoopList captures barcodes and photos. Nimblist snaps your cupboard and suggests meals. But none of them treat hardware stores or IKEA as first-class domains. Best Buy is the closest thing to non-grocery, and Best Buy is still a consumer electronics store with a clean SKU catalog.
A hardware store is messier. Loose fasteners, cut lumber, paint mixed to order. An IKEA is messier still, because half the store is a showroom and the other half is a warehouse and the two are connected by a deliberately confusing path.
So the diagnosis is clear. Grocery-centric apps fail not because they lack multiple lists, but because their icon catalogs, auto-categorization, and monetization all assume groceries. And no mainstream app treats the physical store as the organizing principle across domains.
So if the existing apps all assume groceries, what are the actual paths forward?
Daniel's data model instinct maps to something real but under-served. Listonic and Bring both auto-assign categories and store assignments internally. They have a schema. But it's their schema. You don't get to edit it. You don't get to say, this item belongs to the hardware store, and when I'm near the hardware store, surface it. The data model exists, but it's locked.
The Home Assistant integration is the exception that proves the point. The official Bring integration landed in version twenty twenty-four point two. Platinum quality, used by one point three percent of active Home Assistant installations. And it exposes exactly the structure Daniel wants. Lists become entities. Items become sensors. You can trigger automations when a list hits a threshold, or auto-add items when an appliance runs low.
The geofencing is the killer feature for Daniel's scenario. Home Assistant knows when your phone is near a store. It can push a notification that says, you're near the pharmacy, here's the pharmacy list. That directly addresses the any trip near shops case. And the integration is solid. Changes from Home Assistant to Bring are instant. Changes from Bring back to Home Assistant poll every ninety seconds.
Ninety seconds is fine for groceries. Nobody's life depends on the list updating in real time.
But Daniel's skepticism about Home Assistant is completely validated. Standing up a full home automation platform purely for shopping lists is like buying a data center to run a spreadsheet. The Bring integration is one of thousands of components. You're installing an operating system for your house to solve a problem that a well-designed list app should solve in minutes.
The spouse acceptance factor is real in home automation. Herman, you've said this before. Every automation you add is a thing your partner has to learn and tolerate.
And with a young kid and an apartment still being unboxed, the tolerance for fiddling with YAML is approximately zero. Home Assistant is the right answer for someone who already runs it and wants to bolt shopping onto the existing setup. It's the wrong answer for someone starting from zero.
The task manager path has the same shape. Todoist or TickTick can technically model this. A project per store, labels for categories, due dates for urgency. But the StepList Show HN thread from a couple of years ago put the problem precisely. Task managers handle one-off tasks but falter with routines. Project management software is overly complex. The gap between them is where household checklists live.
And what task managers lack is exactly what makes Bring fast. Icons. Aisle ordering. Barcode scanning. Store-specific layouts. The affordances that let you add an item in two taps instead of typing a sentence. A task manager makes you type drywall anchors, then assign it a label, then assign it a project, then set a due date. That's four interactions for one item, and Daniel said it himself. Nobody wants to spend a lot of time using or setting up an app like this.
So the general tools are too general, and the specific tools are too grocery. That leaves the path Daniel probably suspects but hasn't fully articulated. Build the thing yourself.
This is where the last six months have changed the calculus. There were multiple Hacker News threads in February about AI killing app subscriptions, and the examples people kept giving were grocery list apps. One commenter said, why would I pay five dollars a month for a list app when I can pay Claude thirty cents one time to make it for me. And then he described doing exactly that. He reverse-engineered his grocery store's API and built a list app that pulls aisle information for each item and sorts by his personal walking route through the store.
His personal walking route. That's the phrase. Not the store's layout, not the category taxonomy. The path he actually walks.
Another commenter in March said this class of app is easily worth the under a dollar in tokens from a Chinese model. You don't need frontier reasoning to build a shopping list. You need a database, a UI, and a sort order. That's a weekend project now, not a startup.
But there's a counterargument from the same threads that's just as sharp. A commenter named markbao pointed out that building such an app means making hundreds of UX decisions. Offline-first architecture, gesture patterns, camera permissions. And then the hard problem. Units and quantities. Units, weight, dollars, bunches, fractional versus decimal weight. Do you buy bananas by the bunch or by the pound? Does a half pound of deli meat round up or down?
Those decisions are trivial individually and exhausting in aggregate. The five dollars a month for a polished app is paying someone else to have already made them. When you build it yourself, you're the product manager, the UX designer, and the QA team. For a busy parent, that's a terrible trade.
Then there's IKEA, which is a structural problem that no app solves. The store's layout is deliberately disorienting. It's designed to maximize dwell time. You walk through the showroom to get to the marketplace, and the marketplace funnels you past lighting and textiles before you reach the warehouse. The IKEA website gives you aisle and bin numbers and printable lists, but no general shopping app natively captures IKEA article numbers and warehouse locations.
Even if you build the perfect multi-domain list app, the IKEA list is still just a list. It doesn't tell you that the bin you need is in aisle twenty-three, location forty-two, and that the fastest path there is through the exit, not the entrance.
Which is where I want to bring in Hilbert, because I think he has a view on this.
Hilbert: You're all talking about apps and data models, but the real problem is that IKEA doesn't want you to find things efficiently. The layout is a maze on purpose. Every time you go back for that one bin you forgot, you walk past the lighting department again. No app fixes that unless it tells you the exact aisle and bin number, and even then the store moves things every few months to keep you searching.
The store moves things on purpose?
Hilbert: Of course it does. I ran a stockroom at an IKEA in the early two thousands. The showroom gets reflowed every quarter. Not the whole store, but enough that your mental map goes stale. The warehouse bins shift too, because the article numbers stay the same but the locations get reassigned when they rebalance inventory. The website updates, so if you check stock before you go, you get the current aisle and bin. But the app ecosystem doesn't pull that data. So you're standing in the warehouse with a list that says BILLY bookcase and no idea that the box is in aisle eighteen, location seven.
The website has the data, but the apps don't use it.
Hilbert: The website gives you aisle and bin numbers on the product page. There's a check stock feature. You can print a list with the locations on it. It's ugly, but it works. I keep a note on my phone with the article numbers and the bin locations for the things I go back for. Took me ten minutes to set up. Every time I go, I check the website before I leave and update the bins if they moved. It's not an app. It's a note. But it solves the actual problem, which is that the store is the enemy of the list.
That's the insight. The store is the enemy of the list. The physical environment is designed to work against your retrieval system, not with it.
That reframes the whole problem. Daniel's been asking which digital tool to use, but the constraint isn't digital. It's physical. The store wants him to wander. The list wants him to be efficient. Those are in direct conflict.
Hilbert: My brother-in-law sells flooring. He's the same way about big box hardware stores. He says the layout changes every season, and the staff don't know where anything is either. He keeps a notebook in the truck with the aisle numbers for the three stores he actually visits. He's not to be trusted about most things, but he's right about that.
The notebook in the truck is the low-tech version of the same insight. The data model lives in his head and on paper, and it works because he controls it.
That's the thing about Daniel's data model instinct. He's right that a schema per domain is the correct abstraction. But the schema has to include the physical location data, and the physical location data changes, and the apps that could track it don't. So the schema ends up living in a notes app with manual updates, because that's the only system flexible enough to hold it.
Hilbert: The note on my phone has three columns. Article number, bin location, last updated. That's the whole schema. It's not elegant. It works because I update it when I check the website. If I don't update it, it goes stale and I'm back to wandering. The app would have to do that update automatically, and none of them do.
That's the gap. Automatic location refresh. The IKEA website has the data. A purpose-built app could scrape it. But nobody's built that app, because the market is too small and the data changes too often.
The AI-build-your-own path could actually solve this specific piece. You could have a Claude-built script that checks the IKEA website for your saved article numbers and updates the bin locations in a note or a spreadsheet. That's not a list app. That's a small automation. But it's the piece that makes the rest of the system work.
It's the piece Daniel would actually use, because it saves him the manual check before every trip.
Hilbert: The thing about IKEA is that the article numbers are the key. Everything else is decoration. If you have the article number, you can find the bin. If you don't, you're reading signs and hoping. Most people walk in with a list that says shelf brackets and they wander. I walk in with a list that says article number six zero two three four five, bin eighteen seven, and I'm out in fifteen minutes.
That's the difference between a list and a retrieval system. The list says what you need. The retrieval system says where it is and how to get there.
Where does that leave Daniel? He's got a grocery app that works but is grocery-bound. A home automation platform that could work but is heavy. A task manager that's flexible but slow. And a build-your-own path that's cheap but demands a hundred UX decisions.
I think the honest answer is that the gap he describes is real and unserved. There is no standalone app that unifies groceries, hardware, pharmacy, and IKEA with a shared data model and store-aware retrieval. The closest things are general list apps that let you create arbitrary named lists, and they all lack the domain-specific affordances that make Bring fast for groceries.
The practical recommendation is a hybrid. Keep Bring for groceries, because it's good at that one job. Accept that it's a marketing platform and don't put anything sensitive in it. For everything else, use a shared notes app with a simple structure. One note per store. Items with the details that matter for that domain. For IKEA, article numbers and bin locations, refreshed from the website before each trip.
If Daniel wants to go one step further, the AI-built automation for the IKEA location refresh is the highest-value project. It's small, it's specific, and it directly attacks the failure pattern he described. Forgetting the backlog of small parts because the retrieval moment is too chaotic.
The deeper question, and I think this is the one that lingers, is whether the answer is a better app, a smarter data model, or accepting that the physical world resists digital optimization. The stores don't want to be legible. They profit from the wandering. So any system that works has to fight the environment, not just organize the list.
As AI-built personal tools get cheaper, the build-your-own path becomes the default for technically inclined users. Daniel is exactly the profile. He ships open source. He builds automations. The thirty-cent grocery app is within his reach. But the UX decisions remain the hard part, and the units and quantities problem doesn't go away just because the code is cheap.
The cutting-room floor detail I keep coming back to is that Listonic data retention number. Ten years. Some of those nine hundred forty-six partner companies can keep your purchase history for a decade. That means a list you made when your kid was a baby is still sitting in some ad-tech database when your kid is in middle school. The free app isn't free. The payment is just deferred and invisible.
That's the thing to weigh against the five-dollar subscription. A paid app with no ads and no data sharing is paying for the absence of a business model you don't want to be part of. For a family, that's worth something.
The open question I'd leave Daniel with is this. Is the goal a better list, or a better relationship with the physical stores? Because the stores are optimized against him. The list is just the tool he brings to the fight.
Thanks to our producer Hilbert Flumingtop for keeping us on schedule, even when the schedule involves wandering through a warehouse looking for bin eighteen seven.
This has been My Weird Prompts. Email us at show at my weird prompts dot com with your own household system failures.
We'll be back soon.
