Settings That Stick: Settings Pages and Preference Persistence in Vibe-Coded Projects

Users rarely get angriest about a missing feature. They get angry when something they set up yesterday is gone today. The font size snapped back to the default, notifications started buzzing again, the workspace language flipped back to English, and even the list sorting reset itself. Users will not say "your persistence layer has a problem." They will say one sentence: this product does not remember me. A settings page is a product's memory, and losing that memory once takes ten good experiences to repair. This guide is about building a settings page that works like a reliable memory machine: things can be found where they belong, changes survive until the next visit, and they follow the user across devices.

A note on the examples in this guide: the product "Everpine Notes" and the user "Lin Wan" are fictional, invented only to make the ideas concrete. They are not a real product or a real person. The method itself is general and can be applied directly to any vibe-coded project.

The core idea: a settings page is not a junk drawer, it is memory

Many vibe-coded projects grow their settings page the same way: one toggle gets stuffed in today, one more option tomorrow, and three months later you have a wall of switches. Finding "change password" takes three screens, and finding "export data" requires guessing which group it belongs to. The problem is not that there are too many switches. It is that nobody ever gave the settings page a structure. Its first principle is simple: users arrive with a task. They want to change one specific thing, confirm that it took effect, and leave. Every design decision should serve that flow, not show off how many features you built.

So before building, do a subtraction exercise. List every setting, then ask three questions. First, how often will a user touch this in a month? Something touched less than once a year belongs deeper in the page, or should be removed outright. Second, can changing this setting hurt someone? If yes, it needs confirmation and a recovery path, not just a bare toggle. Third, does this setting have a default that works well for most people? If so, that default should be right out of the box, instead of forcing users to learn configuration before they can use the product. Most settings-page bloat comes from treating "a developer thought someone might want this" as "users actually need this."

There is also a common misjudgment: treating the settings page as a display cabinet for advanced features. A good settings page is the opposite — the quieter, the better. The three to five most-used items are visible at a glance, infrequent items live inside groups, and dangerous items are isolated on their own. Users do not need to feel the product's full power inside settings. They only need to get one change right, the first time, when they want it.

The three-layer preference model: decide where things live before you save them

Half of all lost-preference bugs are not coding errors at all. They happen because nobody decided, from the start, who a setting actually belongs to. My advice is to sort every preference into three layers and assign each item to a layer before writing any code.

The first layer is device preferences, which belong only to one device. Examples include interface font size, whether the sidebar is collapsed, and whether the theme follows the system. These should not follow the user to a new device, because every device has a different screen and different usage habits. They are best stored locally, in local storage: fast to read and write, usable offline, and free of server cost. Forcing them to sync to an account creates surprises instead — a font size tuned for a large monitor looks absurd when it lands on a phone.

The second layer is account preferences, which follow the person, not the device. Language, time zone, whether a weekly digest is sent, and the default workspace all belong here. They must live on the server, attached to the account. An account preference stored only locally is the most common source of "my settings disappeared" incidents: the user clears browser data or logs in from another browser, the preferences vanish, and the user concludes the product deleted their stuff.

The third layer is workspace preferences, which belong to a team or a project, not to an individual. A board's default view, a project's notification rules, or a shared folder's sort order all live here. They must be stored with a workspace identifier, and changing them must respect permissions — not every member should be able to change workspace-level settings. Mistaking a workspace preference for a personal one means two people looking at the same board see different things and argue about it. Mistaking a personal preference for a workspace one means one person changing their font size changes the interface for the whole team.

A simple decision table settles most assignments: should this setting follow the user to a new device? If yes, it is an account or workspace setting; if no, it is a device setting. Will changing it affect other people? If yes, it is a workspace setting. Answering those two questions places about ninety percent of settings. For the remaining ten percent, such as theme, where both answers are defensible, set one team rule and apply it consistently instead of letting each page invent its own behavior.

Running the fictional Everpine Notes through this table gives a very clean result. Lin Wan's font size and sidebar state are device-level, stored locally only. Her language, time zone, and weekly digest are account-level, stored on the server, so they survive a phone change. The default view and notification rules of the shared board she manages are workspace-level, and changing them first requires checking whether she has management permission. The easiest item to misplace is "the template for new notes": it looks like a personal habit, but if the template belongs to a shared workspace, changing it affects colleagues, so it belongs at the workspace level. Items that spark arguments in a layering meeting are usually exactly these boundary items, and settling them once benefits every page afterwards. One supplementary rule is worth adding: the same preference may look different on different devices, but it may have only one home — language, for instance, cannot live locally on the phone and on the server on the computer, or the two copies will eventually fight.

Information architecture: groups, search, and the danger zone

Layering answers "where is it stored." Information architecture answers "can it be found." I recommend grouping by task, not by technology. Users think "I want to change the appearance," "I want to manage notifications," or "I want to deal with my account." They do not think "which backend module does this toggle map to." So group names should use the user's language — Appearance, Notifications, Account and Security, Data, Workspace — not developer language like Configuration, System Parameters, or Advanced Options.

Keep the number of groups between five and seven. When a group grows beyond ten items, split it again or tuck low-frequency items under a "More" section. The first item in each group should be the one most often changed in that group, because the user's first glance at a group is when they judge whether they walked into the right place. Groups must not overlap in jurisdiction: if the same setting appears in two groups, and the user changes one copy while the other stays unchanged, they will reasonably doubt which one is real.

Once settings grow numerous, the settings page needs search. Search is not a nice-to-have for a mature settings page; it is a necessity. It should match setting names, aliases, and group names — searching "alerts" should find "notifications," and searching "password" should find "change password." When a search returns nothing, do not show only "no results." Offer the three closest group entries and a line telling users where they can request a missing setting. An empty result is itself an answer, and a good one keeps users from feeling they searched in the wrong place.

Dangerous operations must be isolated, at the bottom of the page, in a visually distinct area — for example, behind a divider with a red-tinted "Danger Zone" heading. Deleting a workspace, transferring ownership, or wiping data must never sit mixed in with ordinary toggles. Mixing them is not an aesthetic issue; it is a mis-tap probability issue. A user who only wanted to turn off a notification should never slide a finger into a deletion flow. Every item in the danger zone needs its own confirmation step; confirmation design has its own dedicated guide in this series, but the rule here stands alone: the further dangerous operations sit from everyday operations, the better.

Four persistence mechanisms: no silver bullet, only a combination

Making a preference truly "stick" depends on combining storage mechanisms, not on any single technology. Four common mechanisms each have their place, and putting a preference in the wrong place plants the seed of a future incident.

Local storage suits device preferences. Its strengths are speed, offline availability, and zero server cost; its weaknesses are that clearing browser data wipes it, switching devices loses it, and capacity is limited. When writing local preferences, remember two things: wrap reads and writes in error handling so that one corrupted value falls back to the default instead of breaking the whole page, and never put sensitive information in local storage. Tokens and secrets are not preferences, and they should never be tucked in there for convenience.

Server storage suits account and workspace preferences. Its strengths are that it follows the user, survives device changes, and supports permission control; its weaknesses are network dependence and concurrent-write handling. A common trap is the "fake success" save button: the interface shows success the moment the user clicks, while the request is still in flight, and if it fails nobody tells the user. The correct behavior is to show success only after the server confirms, and on failure to say exactly which item failed to save while keeping the user's edits in place, so they can retry with one click instead of re-entering everything.

URL parameters suit preferences that are "worth sharing," such as the current view, filter conditions, or sort order. Their advantage is that a link sent to someone else opens in exactly the same view; their disadvantage is that URLs should not carry too much, and must never carry private content. The test is simple: would the user want to send this state to someone else? If yes, it belongs in the URL; if no, keep it out.

Cookies suit the small number of preferences the server needs before rendering, such as language and theme, so the page does not flash the default theme before switching. But cookies have size limits and are unsuited to complex structures. Treat them as an "opening hint," not the main warehouse. The combination rule is easy to remember: device preferences go local, account preferences go to the server, shareable state goes in the URL, and first-paint essentials go in cookies. Every preference has exactly one source of truth; other places may hold caches, but caches must be correctable by the source of truth, never left to disagree with it.

Multi-device sync and write conflicts: the last save is not always right

Once preferences live on the server, multi-device sync problems arrive immediately. A user changes language on their phone and time zone on their computer, and if the server handles this as "the later request overwrites the entire record," the phone's language change can wipe out the computer's time zone change. This is the classic "changed one thing, lost another" incident. The root cause is not the network; it is save granularity that is too coarse — whole-record overwrite instead of per-field merge.

The fix is to save per field and merge per field. Each preference field updates independently, without disturbing the others. Going one step further, add a version number to the preference record: every update carries the version the client read, and if the server sees a mismatch, it knows someone changed the record in between. At that point it should not silently overwrite; it should surface the conflicting fields to the user, or merge them by a rule decided in advance. Versioning sounds heavy, but for workspace-level preferences it is almost mandatory: two people editing the same board's default view at once will otherwise overwrite each other by design.

There is a subtler conflict: offline edits. A user changes settings without a connection, and the changes sync only after reconnecting, by which time the server's preferences may be newer. The guiding principle is to set a priority in advance. An offline edit is an explicitly expressed user intent and generally should not be silently discarded. But when an offline edit and an online edit collide on the same field, show the user both values and let them choose, or at minimum tell them after syncing that "a few settings were updated." The worst handling is to quietly pick one and pretend nothing happened.

Sync status itself should be visible. A small "Synced" or "Syncing" indicator in a corner of the settings page can prevent a large number of support tickets. What users fear most is not waiting; it is not knowing whether their change was saved. When sync fails, the message should name the field: "Language saved; notification settings failed to sync — tap here to retry," not a vague "Sync failed."

Defaults, migration, and rollback: a new version must not erase old users' settings

The most neglected part of a preference system is version change. A new version adds a setting — what should its value be the first time an old user opens it? An old setting is removed — what happens to the value the user already stored? A setting's allowed range changes — what happens to a stored value now outside the range? If you cannot answer all three, launch day will bring complaints that "my settings were reset."

My three rules are as follows. First, every new setting must have a sensible default, chosen from the standpoint of most users — neither the most conservative nor the flashiest option. Second, when an old setting is removed, keep its server-side data for at least one release instead of deleting it physically, leaving room to roll back. Third, when a value range changes, write a migration that maps old values to the nearest new values, and record it in a migration log. Migration code deserves its own tests, especially at the boundaries: if the old value was the maximum and the new range is narrower, where does it map? If the old value was empty and the new version requires a value, what fills it?

Rollback matters just as much. Failed saves, failed syncs, and failed migrations all need a way back. With optimistic updates on the client, keep the old value aside; on failure, restore the interface to the old value and say so. On the server, a failed write must not leave a half-new, half-old record — either everything goes in, or nothing does. Users can accept a clear failure message. What they cannot accept is an interface that says success while the data underneath is already inconsistent.

The "reset to defaults" feature itself deserves the same care. Every group should offer a reset entry, but resetting is not deleting: before executing, list the items that will change and ask for confirmation; after executing, allow undo, at least within the current session, so users can jump back to where they were. A reset without undo is no different from a deletion.

Acceptance checklist: run through it before launch

Everything above condenses into one checklist to tick off before release. First, are layers assigned: can every preference be described as device-level, account-level, or workspace-level? Second, can settings be found: test with five real tasks — change language, turn off notifications, switch themes, export data, delete a workspace — and check whether each completes within three steps. Third, is saving reliable: what happens on offline save, double-clicked save, and simultaneous saves from two devices, and does each case produce clear feedback and a correct final value? Fourth, do preferences follow across devices: after logging in on a new device, are all account preferences present, and did device preferences correctly stay behind? Fifth, can old users upgrade: does importing old-version data into the new version lose or misplace anything? Sixth, is the danger zone isolated: are dangerous operations in a separate area, with confirmation steps and a recovery path?

Add three easily missed tests: after clearing browser local data and logging in again, are account preferences still there? After changing the system language, does the product's language preference get wrongly overridden by the system setting? And when two people change the same workspace preference at the same time, is the final result explainable rather than random? Once this checklist passes, the settings page is genuinely finished, not merely "looking finished."

In the end, a settings page does not compete on feature count; it competes on trustworthiness. Users are willing to invest time tuning a product only if they believe that tuning will not be wasted. Assign layers clearly, store each preference in the right place, explain sync conflicts honestly, and leave a way back for migrations. Do that, and the settings page turns from "the most overlooked page" into "the most reassuring page." And reassurance is exactly why users stay and keep using a product.