My wife redesigned the app I built her three times. I never wrote a line.
I built my wife a shopping list app in an evening. That's the story I already told. What I didn't tell is what happened in the weeks after, because that's the part that actually taught me something.
She used it for two days and added a column I hadn't thought of: whether we already have it at home. I've written software for over a decade. She'd never written a line of it, and she out-designed me by day two. I told that part already too.
I thought that was the whole lesson. It wasn't even the first one.
When I built the second list, the one for the flat, I gave it the same shape as the first: an item, a checkbox, on or off. She used it for a week and came back with a complaint I hadn't seen coming. Some things on a flat list aren't yes or no. They're "not yet." A new shower curtain isn't a today problem, but it's not off the list either, and she wanted somewhere for it to live that wasn't checked and wasn't deleted. I'd modeled the list as binary because binary was easy to build, not because it matched how she actually held the list in her head.
The third thing was smaller and told me more. She wanted to remove things from a list without deleting them, a soft "not now" instead of a hard "gone." I'd built delete because delete is one function and it felt complete. She wasn't bothered by clutter. She was worried about losing the idea entirely if she turned out to be wrong about not needing it. The cost of "gone" was bigger to her than the cost of one more row she'd scroll past.
None of these were feature requests, exactly. Three separate times, she showed me I'd modeled the software around what was easy to build rather than around how she actually thinks in lists, and I only found out because she was using it, not because I'd sat down and asked her what she wanted.
That's the part most "describe an app and get one" tools don't touch, and the part I actually care about getting right. Not whether you can describe a tool and get a first version. Every builder does that now. Whether you can hand someone that first version, watch what's wrong with it through how they use it instead of what they say about it, and get back to a right one before the annoyance calcifies into "I guess this is just what it does." A tool that costs an evening to build and a sentence to fix is a different relationship with software than one that costs a sprint and a ticket.
It's still a waitlist and unfinished code under all of this, same as always. But the shopping list has a "not yet" column now, and a "not now" instead of a delete button, because both of those cost her a sentence to ask for, not a ticket for me to triage.
If you've built something for someone you live with, what did they change about it that you didn't see coming?
FAQ
Why do shared to-do or checklist apps fail?
Most shared checklist apps model a task as binary — checked or unchecked — which matches how a task is easy to code, not how people actually think about the things on a list. Real items often need a third state: not done, but also not urgent right now. When an app can't hold that middle state, people either check things off they haven't really finished, or abandon the list entirely for something more flexible, like a paper note or a chat message.
What's the difference between soft delete and hard delete in app design?
A hard delete removes something permanently and immediately; a soft delete marks it as removed or set aside while keeping it recoverable. For personal and shared lists specifically, users are often less bothered by a longer list than by the risk of losing an idea they might need again — so a "not now" state that can be brought back tends to feel safer to use than an irreversible delete button, even if it makes the interface slightly busier.
How do you design software for someone you live with, rather than for yourself?
Watch how they actually use a first version rather than asking them what they want in advance. In practice, the person using a tool daily will surface real gaps — states you didn't model, actions you assumed were simple — faster and more accurately through use than through a conversation about requirements. The fastest path to a better second version is handing over an imperfect first one and paying attention to what they correct.
Why do apps default to a simple checkbox instead of more nuanced states?
Because a binary checkbox is the easiest thing to build, not because it's the easiest thing to use. A true/false field takes one column and one interaction to implement; a tri-state or open-ended status takes more design and more edge cases to handle correctly. Software frequently ends up shaped by what was convenient to code rather than by how the person using it actually organizes their thinking.
Made with FOKL — little apps your family keeps.