A privacy toggle is not a privacy boundary

A visibility toggle is easy to build. A privacy boundary is not.

Miyo is designed for two people who want to share parts of their financial life without making every account visible. Each account can be private, shared, or hidden. The interface explains those choices, but the interface is not allowed to enforce them.

The boundary

The rule is simple: if a partner cannot see an account, the server must never return it to that partner.

That decision reaches further than hiding a row. Account queries, transaction lists, dashboard totals, exports, and mutations all have to start from the same verified user and household context. Otherwise one forgotten endpoint can quietly undo the promise made by the privacy control.

Why I kept it out of the component layer

Putting privacy logic inside React would make the screen look correct while leaving the data available to anyone who called the underlying endpoint. Instead, the account state belongs to the domain boundary. Components receive only the data that the current person is allowed to use.

This also makes the behavior testable without a browser. Given two household members and an account state, the expected result is either a permitted account or no account at all.

What the interface still has to do

Server enforcement does not remove the design problem. People still need to understand who can see an account before they change it. The UI has to name the three states plainly, show the consequence of each choice, and avoid making a sensitive change feel casual.

The useful lesson was not “add a privacy setting.” It was to decide where the promise becomes enforceable, then design every surface around that boundary.