Problem statement
Home Assistant has a panel called Developer tools. It lives under Settings. The contents are a mix of debugging utilities and learning aids: a place to inspect or override the state of any entity, fire and inspect events, call any action by hand, work through a template against live data, and reload parts of YAML without restarting.
The name is a problem. The word "Developer" tells a non-technical user that this panel is not for them, before they have even opened it. We hear it back, in those words, from people we are trying to bring into Home Assistant: they assume the section is for plugin authors and core contributors and skip it. Even community write-ups about the panel have to lead with "Don't let the name put you off." (howtogeek.com).
The framing also fights against the actual contents. A user trying to learn templates by trial and error is not developing anything. A user calling light.turn_on to confirm an entity behaves the way they expect before they wire it into an automation is debugging their setup, not contributing code. A scared user does not click a panel labelled Developer.
- The name implies a skill threshold that is not real. Nothing inside the panel requires writing code. It requires curiosity and the willingness to click around. Labelling the panel Developer tools tells a large group of users they are not invited.
- The name is the opposite of where the rest of the product is going. We are removing the Advanced mode toggle (roadmap #54) and the Advanced and Expert terminology in general (roadmap #56) for the same reason: skill-gating language works against approachability. Developer tools is the same problem under a different word.
- The current name discourages exploration at exactly the moment we want to encourage it. The first time a user thinks "I wonder what state this thing is in" or "what does this template return", we want them to find their way to the right place. A name that signals "not for you" trains the wrong instinct.
This is intentionally a perception change, not a redesign. The contents stay where they are. The information architecture stays where it is. We rename the panel in the frontend, give it fresh my.home-assistant.io URLs that match the new name, and update the user-facing documentation to use them.
This maps to the Make Home Assistant More Approachable goal. The first days and weeks of using Home Assistant are when users decide whether the product is for them. A panel labelled Developer tools, found in Settings, hands them an easy reason to conclude it is not.
Community signals
The naming has been raised by users and members of the team across multiple years. Suggestions cluster around a small set of alternatives: Tools, Toolbox, System tools, Testing tools.
The canonical naming thread
- Frontend #6316: "FR: Rename Developer Tools to System Tools" (July 2020, 16 comments, 10 reactions, locked January 2022). Opened by
@Tediore after a Discord discussion concluded the name is misleading. @SeanPM5 (frontend team member) argues for plain "Tools" because System still reads as "nerd stuff" to non-technical users (8 reactions on that comment). @Villhellm makes the case that these features are a necessity for anyone automating, not a developer-only set. @matthiasdebaat (member) returns in 2021 to second "Tools" as the most neutral option. @bramkragten (frontend team) takes the opposing view that the tools are advanced and the goal should be to make them unnecessary, not to rename them. The thread is the longest-running internal debate on this naming and shows the disagreement we need to resolve as part of this opportunity.
Community forum
Third-party coverage
The threads cluster around one shape: the contents are useful for everyone, the name implies otherwise, and a less specialized word would help. The disagreement inside the team on the alternative ("Tools" vs. "System tools" vs. "Toolbox") is the part that has not been resolved, and is part of what this opportunity exists to settle.
Scope & Boundaries
In scope
- Picking the new name. A short shaping phase that resolves the naming. Candidates raised so far include Tools, Toolbox, Playground, System tools, and Testing tools. The decision is part of this bet, not a prerequisite.
- Renaming the panel in the frontend. The panel header, the sidebar entry (when surfaced), the breadcrumb, and the page title. The URL path follows the new name as well, so a user landing on the page from a bookmark or an external link sees the new name in the address bar.
- Update my.home-assistant.io URLs that match the new name. When users share a my-link in the forum, in a blog post, or in a how-to, the URL itself should not contain "developer". We add new my.home-assistant.io entries with new slugs aligned to the new name. The existing
developer_* entries continue to resolve as aliases so links already shared in the wild do not break.
- Updating end-user documentation. The page at home-assistant.io/docs/tools/dev-tools/ and any other user-facing references on home-assistant.io. First-party docs that link to my.home-assistant.io get rewritten to use the new my-link URLs from the previous bullet.
Not in scope
- Reworking what is inside the panel. The contents and the sub-tabs stay as they are. Improving any of the individual tools is separate work and out of scope here.
- Information architecture changes. Moving the panel out of Settings, into the sidebar, or merging anything is out of scope. We rename what exists; we do not relocate or restructure it.
- The Advanced mode toggle and the broader skill-gating terminology audit. Covered by roadmap #54 and roadmap #56 respectively. This opportunity is the same shape but scoped tightly to one panel.
- Renaming the developer documentation site at developers.home-assistant.io. That site is genuinely for developers and the name is correct.
- Removing the existing
developer_* my.home-assistant.io entries. They stay in place as aliases so links already shared in forum answers, blog posts, and integration documentation continue to resolve. Internally how the redirect resolves is not user-facing.
Foreseen solution
Phase 1: Resolve the naming. A short shaping step. Pick one of the candidate names (Tools, Toolbox, Playground, System tools, Testing tools, or a new proposal) and document the decision. The output is a one-line decision and the rationale. The bet should not start work on Phase 2 until Phase 1 is settled. Translation feasibility for the chosen word is a sanity check here, not a deep audit.
Phase 2: Rename in the frontend, and add fresh my-links. Update the panel label, the URL path so it matches the new name, and any in-product copy that refers to "Developer tools" by name. Update the translation strings for every language we ship; the change is small per string but touches many files. In parallel, add new my.home-assistant.io entries with slugs that match the new name. The existing developer_* entries stay in place as aliases, resolving to the same panel, so links already in the wild keep working.
Phase 3: Update documentation to use the new my-links. Sweep home-assistant.io for first-party references that link to my.home-assistant.io for any of these tools, and replace them with the new URLs from Phase 2. Update the user-facing docs page at home-assistant.io/docs/tools/dev-tools/ at the same time. The aim is that anything we ship from here on out shares a clean URL.
Phase 3 depends on Phase 2 because the new my-links must exist before our docs can point to them. Phase 3 can lag Phase 2 by a release or more without harm; the old developer_* URLs continue to resolve until each doc gets to its turn.
Risks & open questions
- The name itself is the open question. The team has disagreed on the alternative for years (frontend #6316). "Tools" is the simplest. "System tools" is the most descriptive but, per
@SeanPM5 in the canonical thread, may carry the same baggage as Developer for non-technical users. "Toolbox" is friendlier but breaks the one-word convention of the rest of the sidebar (Overview, Logbook, History). "Playground" leans into the learning-by-experimenting framing of templates and actions but reads awkwardly for the more diagnostic parts of the panel. The bet does not start until this is settled.
- Internal disagreement on the premise.
@bramkragten argued in 2020 that these tools should not be needed by typical users at all, and renaming them legitimizes their visibility. The counter-argument, which this opportunity sides with, is that the tools are useful for learning and debugging by users who are not developing anything, and the name is what is making them feel out of bounds. The contents stay; we are not endorsing wider use, we are removing a misleading label.
- Translation reach. One panel label and a small handful of in-product copy strings across every supported language. Each string is small, but the translation community has to do the round trip. The chosen word should translate cleanly; this is a soft constraint on Phase 1.
- Continuity for documentation, blog posts, and YouTube content. Years of community-authored guides, forum answers, and videos refer to "Developer tools". Changing the name does not invalidate them, but it does add a small friction layer. A short note in the release blog post and a redirect on the docs page covers most of this.
- Existing my-link compatibility. Years of forum answers, blog posts, integration documentation, and YouTube descriptions contain
developer_* my-links. Those URLs must keep resolving after the rename so we are not invalidating the community's writing in the process of cleaning up the name. The plan is parallel slugs (new ones for new content, old ones as aliases), but we should be deliberate about not deprecating the old ones until and unless we have a reason to.
- Avoiding a follow-up rename. Whatever we pick in Phase 1, we should pick once. A second renaming a year later is worse than the current name. The bet's success depends on Phase 1 producing a name we are willing to live with.
Appetite
Small. Roughly one cycle, primarily in frontend with a small slice of work on my.home-assistant.io and home-assistant.io. Phase 1 (naming) is a shaping conversation, not engineering work. Phase 2 (frontend rename plus new my-link entries) is the bulk of the engineering work and can land in a single coordinated set of PRs plus translations. Phase 3 (sweeping docs to use the new my-links) is additive and can ship alongside or shortly after Phase 2.
Execution issues
To be populated once a bet is approved.
Decision log
| Date |
Decision |
Outcome |
| 2026-05-07 |
Created opportunity for betting table consideration. Sibling to roadmap #54 and roadmap #56, scoped tightly to the Developer tools panel. |
Initial version |
Problem statement
Home Assistant has a panel called Developer tools. It lives under Settings. The contents are a mix of debugging utilities and learning aids: a place to inspect or override the state of any entity, fire and inspect events, call any action by hand, work through a template against live data, and reload parts of YAML without restarting.
The name is a problem. The word "Developer" tells a non-technical user that this panel is not for them, before they have even opened it. We hear it back, in those words, from people we are trying to bring into Home Assistant: they assume the section is for plugin authors and core contributors and skip it. Even community write-ups about the panel have to lead with "Don't let the name put you off." (howtogeek.com).
The framing also fights against the actual contents. A user trying to learn templates by trial and error is not developing anything. A user calling
light.turn_onto confirm an entity behaves the way they expect before they wire it into an automation is debugging their setup, not contributing code. A scared user does not click a panel labelled Developer.This is intentionally a perception change, not a redesign. The contents stay where they are. The information architecture stays where it is. We rename the panel in the frontend, give it fresh my.home-assistant.io URLs that match the new name, and update the user-facing documentation to use them.
This maps to the Make Home Assistant More Approachable goal. The first days and weeks of using Home Assistant are when users decide whether the product is for them. A panel labelled Developer tools, found in Settings, hands them an easy reason to conclude it is not.
Community signals
The naming has been raised by users and members of the team across multiple years. Suggestions cluster around a small set of alternatives: Tools, Toolbox, System tools, Testing tools.
The canonical naming thread
@Tedioreafter a Discord discussion concluded the name is misleading.@SeanPM5(frontend team member) argues for plain "Tools" because System still reads as "nerd stuff" to non-technical users (8 reactions on that comment).@Villhellmmakes the case that these features are a necessity for anyone automating, not a developer-only set.@matthiasdebaat(member) returns in 2021 to second "Tools" as the most neutral option.@bramkragten(frontend team) takes the opposing view that the tools are advanced and the goal should be to make them unnecessary, not to rename them. The thread is the longest-running internal debate on this naming and shows the disagreement we need to resolve as part of this opportunity.Community forum
Third-party coverage
The threads cluster around one shape: the contents are useful for everyone, the name implies otherwise, and a less specialized word would help. The disagreement inside the team on the alternative ("Tools" vs. "System tools" vs. "Toolbox") is the part that has not been resolved, and is part of what this opportunity exists to settle.
Scope & Boundaries
In scope
developer_*entries continue to resolve as aliases so links already shared in the wild do not break.Not in scope
developer_*my.home-assistant.io entries. They stay in place as aliases so links already shared in forum answers, blog posts, and integration documentation continue to resolve. Internally how the redirect resolves is not user-facing.Foreseen solution
Phase 1: Resolve the naming. A short shaping step. Pick one of the candidate names (Tools, Toolbox, Playground, System tools, Testing tools, or a new proposal) and document the decision. The output is a one-line decision and the rationale. The bet should not start work on Phase 2 until Phase 1 is settled. Translation feasibility for the chosen word is a sanity check here, not a deep audit.
Phase 2: Rename in the frontend, and add fresh my-links. Update the panel label, the URL path so it matches the new name, and any in-product copy that refers to "Developer tools" by name. Update the translation strings for every language we ship; the change is small per string but touches many files. In parallel, add new my.home-assistant.io entries with slugs that match the new name. The existing
developer_*entries stay in place as aliases, resolving to the same panel, so links already in the wild keep working.Phase 3: Update documentation to use the new my-links. Sweep home-assistant.io for first-party references that link to my.home-assistant.io for any of these tools, and replace them with the new URLs from Phase 2. Update the user-facing docs page at home-assistant.io/docs/tools/dev-tools/ at the same time. The aim is that anything we ship from here on out shares a clean URL.
Phase 3 depends on Phase 2 because the new my-links must exist before our docs can point to them. Phase 3 can lag Phase 2 by a release or more without harm; the old
developer_*URLs continue to resolve until each doc gets to its turn.Risks & open questions
@SeanPM5in the canonical thread, may carry the same baggage as Developer for non-technical users. "Toolbox" is friendlier but breaks the one-word convention of the rest of the sidebar (Overview, Logbook, History). "Playground" leans into the learning-by-experimenting framing of templates and actions but reads awkwardly for the more diagnostic parts of the panel. The bet does not start until this is settled.@bramkragtenargued in 2020 that these tools should not be needed by typical users at all, and renaming them legitimizes their visibility. The counter-argument, which this opportunity sides with, is that the tools are useful for learning and debugging by users who are not developing anything, and the name is what is making them feel out of bounds. The contents stay; we are not endorsing wider use, we are removing a misleading label.developer_*my-links. Those URLs must keep resolving after the rename so we are not invalidating the community's writing in the process of cleaning up the name. The plan is parallel slugs (new ones for new content, old ones as aliases), but we should be deliberate about not deprecating the old ones until and unless we have a reason to.Appetite
Small. Roughly one cycle, primarily in frontend with a small slice of work on my.home-assistant.io and home-assistant.io. Phase 1 (naming) is a shaping conversation, not engineering work. Phase 2 (frontend rename plus new my-link entries) is the bulk of the engineering work and can land in a single coordinated set of PRs plus translations. Phase 3 (sweeping docs to use the new my-links) is additive and can ship alongside or shortly after Phase 2.
Execution issues
To be populated once a bet is approved.
Decision log