Care Is a Constraint, Not a Feature

I have read the phrase “we care about your privacy” on the same screen where a company was asking me to hand over my contacts to keep using a product I had already paid for. Care, stated, costs nothing. Care, practiced, costs something specific — and you can usually name the thing.

The framework did not start in software

It started in rooms with young Black brothers, where care could not be a sentiment because sentiment does not survive contact with a hard week. In those rooms care meant a set of obligations you accepted in advance: you show up whether or not it is convenient. You hold high expectations, because lowering them is the most common disguise that low regard wears. You make the room safe enough that a young man can be wrong out loud, because the alternative is that he stays quiet and you never find out what he actually thinks.

None of that is a warm feeling. All of it is a restriction on what the adult in the room is permitted to do.

When we started building software for families, the question was not whether to bring that framework along. It was whether we were willing to let it bind us the same way — to let it rule things out that we might, on a hard quarter, want very badly to do.

Six things care forbids

These are not aspirations. They are constraints we wrote down so that a future version of us, under pressure, would have to argue with them out loud.

1. Care forbids holding the archive hostage

If a family cannot take their recipes, their photographs, their recorded voices and walk out the door with all of it in a form they can actually open, then we do not have their trust. We have their hostages. Export is a day-one obligation, not a retention-team concession granted at the moment of cancellation.

2. Care forbids consent by upload

When someone uploads a photograph of their grandmother, the person clicking the button is not the only person with a stake in it. A family archive is dense with other people’s faces, voices, names, and histories. Treating the uploader as the sole authority is the easy architecture and the wrong one. Consent has to be granular, it has to be revocable, and it has to reach the people who are in the memory and not only the person holding the phone.

3. Care forbids private-by-request

Private has to be the state a family wakes up in, not a setting they earn by reading a help article. Any product that ships open and offers privacy as a preference has already decided whose convenience matters. Defaults are the loudest statement a product makes, because most people never change them — and the people least likely to change them are often the ones with the most to lose.

4. Care forbids designing for the wrong hands

The people holding the memory are frequently the people least served by contemporary interface fashion. If an elder cannot find the button, the story does not get recorded, and the story was the entire point. Type size, contrast, tap targets, and the number of steps between intention and result are not accessibility line items to be swept later. In a product about inheritance, they are the product.

5. Care forbids the infinite product

This is the one that costs us the most, so I want to be plain about it. The dominant metric in consumer software is engagement, and engagement is structurally hostile to care, because it treats a person’s continued need as success. But a reunion ends. A cookbook gets finished. A family completes the work of gathering what it did not want to lose, and then it should be allowed to go live its life.

We build things that can be finished. That means our best outcome is sometimes a family that stops opening the app because the work is done — and it means we cannot report that outcome as a win in the language the industry uses to keep score.

6. Care forbids friction at the exit

Leaving should cost exactly what joining cost. No retention maze, no three-email cooling-off, no cancellation flow that requires a phone call during business hours. A door that only opens inward is not a home.

What this costs

I would rather state the tax than pretend there isn’t one. Every constraint above is a growth constraint.

• Frictionless export makes it easier for a competitor to take our users. That is the intended effect.
• Granular consent means slower onboarding and more screens between a family and the thing they came to do.
• Private-by-default kills the viral loop. Nothing spreads if nothing is public.
• Designing for elders means we ship fewer of the interaction patterns that make a product look current.
• Finishable products cap lifetime value by construction.
• A clean exit raises churn on a dashboard where churn is the number everyone watches.

A founder optimizing for the next raise should not adopt this list. It will read, to the room, as a series of unforced errors.

Why we pay it

Because the unit we are building for is not the user. It is the village.

I am because we are. That sentence is usually quoted as a warm thought about interdependence. It is actually a statement about obligation. If my existence is constituted by the people around me, then I owe them something structural — not goodwill, but conduct. A product built by a village, for a village, is a member of that village. Members have duties that vendors do not.

A vendor asks what it can extract before the relationship ends. A member asks what it owes for having been let in. Those two questions produce different software. You can see the difference in the export button, in the consent screen, in the default, in the cancellation flow — in every place where the easy path and the right one diverge and somebody has to choose.

So the next time you meet a company that says it cares, do not argue with the sentence. Ask what it forbids. Ask what the company has given up, specifically and recently, on account of caring. If the answer is nothing, the sentence was decoration.

We wrote ours down so you can hold us to it.