How I Audited a SaaS Application and Found 16 Dead UI Elements
SaaS products grow feature by feature. Over time the UI accumulates buttons, menus, and settings that no longer connect to working backend logic. Users still see them. Clicking them does nothing useful — or worse, opens half-broken flows.
During a recent SaaS audit I found 16 dead UI elements still visible in production. This post explains the method I used so you can run the same audit on your own app.
What Counts as a Dead UI Element?
I treated an element as dead if any of these were true:
- Click handler missing, empty, or only logging to console
- Route or modal opened, but API always returned 404 / 403 / stub data
- Feature flag permanently off with no plan to ship
- Menu item pointed at a page removed months ago
- Button visible for roles that never had permission to use it
Step 1: Inventory Every Interactive Control
I started from the rendered UI, not the design file. For each authenticated role I walked the main navigation, settings, dashboards, and entity detail pages. I logged every button, link, dropdown item, and icon action into a spreadsheet with columns for:
- Screen / route
- Label or icon
- Role that can see it
- Expected behavior
- Actual behavior
- Code location (component + handler)
Step 2: Trace Click Paths in the Codebase
For each control I searched the component tree for the click handler, then followed calls into hooks, services, and API routes. Patterns that kept showing up:
// Looks interactive, does nothing useful
<Button onClick={() => console.log('TODO: export')}>Export</Button>
// Handler exists, API route deleted
onClick={() => api.post('/v1/reports/legacy-export')}
// Feature gated forever
{featureFlags.oldBilling && <MenuItem>Legacy invoices</MenuItem>}Step 3: Cross-Check Network Traffic
Browser DevTools Network tab caught several “working” buttons that only hit analytics events or returned empty 200 responses with stub JSON. If the UI celebrated success while the database never changed, I marked it dead.
What the 16 Dead Elements Looked Like
- Export / download actions with no server endpoint
- Settings toggles that never persisted
- Admin menus for retired modules
- Upgrade CTAs that opened a removed pricing modal
- Context-menu items for deleted entity types
- “Coming soon” buttons left for over a year
How I Fixed Them Without Breaking Live Flows
- Hide or remove UI first when the backend is gone for good.
- If the feature is planned, replace the dead control with clear copy (“Coming in Q4”) — never a fake button.
- Add integration tests that click critical menus and assert a real API call or navigation.
- Document retired routes in a changelog so support stops pointing users at them.
A Lightweight Audit Checklist
[ ] Walk UI as every paid role
[ ] Log every interactive control
[ ] Trace handler → API → DB side effect
[ ] Confirm Network tab shows real work
[ ] Search repo for TODO / FIXME / coming soon
[ ] Remove or relabel dead controls
[ ] Add regression tests for survivorsFinal Thoughts
Dead UI is a trust problem, not just clutter. Users assume every button works. A short quarterly UI audit — inventory, trace, network check, remove — keeps a SaaS product honest as the codebase ages.
Written by A.M. Rinas · Published September 7, 2026
