01 / Product development
Basket
A shared grocery list that keeps a household in sync.
- Status
- In development
- Platform
- Web and Android
- Focus
- Shared lists, offline sync
Basket started from a small, recurring annoyance: two people buy the same thing because neither of them knew the other had already picked it up. A list in a notes app does not solve that. It records what someone remembered to write down, and nothing about who is buying it.
The product is built around a shared list with a sense of ownership. Items can be claimed before a shopping trip and checked off during one. The list stays the same across the browser, Android, and the gaps where the connection drops.
It is in active development. Everything described here is the product direction and the current build, not a finished commercial product.
What it covers
Shared household lists
One list per household, visible to every member, with a shared understanding of what is needed.
Claiming items
A member can claim an item before shopping so nobody else picks up the same thing.
Check-off while shopping
Items move from requested to bought in one tap, with the list updating for everyone.
Real-time synchronization
Changes sync across devices as they happen, so the list in the store matches the list at home.
Offline first
Edits made without a connection are queued locally and replayed when the device comes back online.
Web and Android
Two clients sharing one model, where the Android app behaves like a first-class citizen.
Push notifications
A quiet signal when something changes that another member needs to know about.
Activity and preferences
A simple feed of recent changes, plus per-member preferences that stay out of everyone else's way.
English, French, and Arabic
Full interface localization, including a right-to-left layout for Arabic rather than translated strings alone.
Technical notes
Offline is a design constraint, not an error state
A grocery store is one of the least reliable places to have a network connection, which makes offline behavior part of the core product rather than a fallback. Basket keeps local state as the source of truth for the device and queues mutations while disconnected.
On reconnect, queued changes are replayed in order. The interesting part is not the queue itself; it is deciding what happens when two members edit the same item while offline. The current direction favors simple, explainable rules over automatic merging that users cannot predict.
Three languages, two directions
Adding French is mostly a translation problem. Adding Arabic is a layout problem. Navigation, spacing, icon direction, and the way lists align all change when the interface runs right to left.
Building that into the component layer from the start is far cheaper than retrofitting it later, so the layout uses logical properties and direction-aware styles rather than hard-coded left and right values.
Real-time sync needs a boring server
The server stays authoritative and the clients stay optimistic. A change applies immediately on the device, then reconciles with the server response. When the response conflicts, the client accepts the server state and tells the user what changed.
That is a less impressive design than peer-to-peer sync and a considerably easier one to debug at 9pm in a supermarket.
What comes next
- 01Harden the conflict rules for simultaneous offline edits.
- 02Put the Android build in front of a small number of real households.
- 03Extend the activity feed so changes are easy to scan rather than merely recorded.
Previous
Olive Farm ProjectNext
UtilitGate