What Farangur deliberately does not do
No offline, no daily checklist, no calendar, no photos or barcodes, no half-packed socks, no ride sharing — thirty-four things were cut on purpose, and here is the reasoning behind the ones people argue with most.
Every app I've ever abandoned died the same way: it got a feature I didn't ask for, then another, and one day it needed a tutorial. So Farangur got one rule before it got a single screen, and it's a rule, not a mood: what isn't needed gets cut. The specification has a list of thirty-four things we deliberately threw out, and I hold it as dear as the list of what the app does.
These are the ones people argue with most, and why I'm not moving.
It doesn't work offline
The biggest cut in the whole project — roughly a third of the complexity went with it. The first design copied a festival app that really had to survive a field with no reception, so it had an offline queue, sync counters, conflict rules. Then I said the obvious thing out loud: we pack at home. In the room, in the garage. There's wifi there.
The state lives on the server; the phone is a thin window onto it. The one place this hurts is a campsite with no signal, where you can't claim a thing from the board — and I decided that's acceptable, because who brings what gets agreed weeks ahead, on the sofa, in the group chat. The board is a planning tool, not an on-site one.
(One thing stayed: every request has a timeout, because a weak signal isn't offline — it's worse. The request neither fails nor finishes, it hangs. The app must not freeze in a garage with bad wifi.)
It isn't a daily checklist
No keys-and-wallet list, no morning routine, no lunch for work. You pack when you leave home for a while — the work trip, the weekend, the festival. Weekly to monthly, not daily. A daily list is a different app with a different rhythm.
No calendar, no reminders, no recurring events
"Clone last year's" is three taps and it's always right. A recurring-event engine would have to guess dates and quantities and generate ghost trips for things that aren't happening. Reminders would need a scheduler, notification permissions and a lead time on every item — to serve a behaviour nobody exhibits. If a thing needs preparing — waterproof the boots — that line shows up while you're getting it ready, when the boots are in your hand. That's the reminder.
No photos, barcodes, luggage weight, half quantities
Photos: upload, storage, thumbnails — a large cost so you can look at a picture of your own tent. The category icon is enough. Barcodes demo beautifully and are useless for a tent, a slackline or two hundred pegs. Weight only matters when flying, and nobody asked. And partial quantities — "3 of 6 socks ready" — is spreadsheet thinking; it would double the state model to answer a question nobody asks. Either the socks are on the pile or they aren't.
It doesn't sort out who drives whom
Ride sharing is designed. It's just not in this version. The pack says what comes along, not in whose boot — and the moment you add cars, seats and pickup points, you're building a different product.
Why so stubborn
Two numbers. The median pack is one person — a work trip, a weekend away. The median group is two. Ozora with fourteen people in one camp is the richest example I have, and the design kept drifting towards it until I had to say it plainly: Ozora is an example, not the spec. Anything dimensioned for fourteen is dimensioned wrong.
And one more cut, my favourite: no swipe gestures. They fail in exactly the situation this app lives in — gloves, wet hands, phone held at an angle, half-registered as a scroll. Tap and long-press do everything.
None of this is unfinished work. Each is a decision, and each keeps the app small enough to learn by packing something once.