A frontend estimate is often wrong before anyone writes code: the team counts screens, while the expensive work sits in shared state, loading behavior, and contracts with other systems. My position is that a product manager should fund a route-by-route risk audit before approving a “modernization” backlog. Otherwise, a tidy list of best practices can conceal the dependencies that determine the schedule.
Counting screens understates the work because routes share hidden dependencies
A screen count treats each page as a separate unit of work, but frontend changes rarely stay within one page. A navigation component may appear on every route; an authentication check may run before any page renders; a change to currency formatting may affect tables, forms, exports, and confirmation messages. If a team estimates a redesign as “twelve screens at two days each,” ask what the number excludes. The answer often includes the work most likely to delay release.
Start with a route inventory rather than a component inventory. For each route, record who can access it, where its data comes from, which states it can enter, and which other routes share its components. Include loading, empty, error, expired-session, and permission-denied states, because those are distinct user experiences even when they occupy the same URL. In a planning exercise, 12 routes is a useful sample size to tune: it is small enough to inspect together, but large enough to reveal repeated patterns. It is not a productivity benchmark.
Then trace the dependencies behind one representative action. A “Save” button might validate in React 19, send a request described by OpenAPI 3.1, handle an HTTP 409 conflict, update a cached list, and announce the result to a screen reader. Calling that one button a small frontend task ignores the decisions required when the server rejects stale data. The cost of missing that path is usually rework: the team discovers late that its success-state design has no answer for a legitimate failure.
Read Frontend Development Best Practices for Modern Web Apps before accepting a platform rewrite, because a checklist cannot prove that the rewrite pays for itself. I would not schedule a wholesale component-library replacement merely because the current UI is inconsistent; the replacement also forces regression testing across every route that uses those components. I would first price the inconsistencies users encounter and the components causing them, then replace the smallest shared layer that addresses those problems.
Ask the team to bring two estimates to the scoping meeting: one for the visible feature and one for its shared dependencies. If the second estimate is missing, the work has not been decomposed enough to commit to a date. This is a product decision as much as an engineering one, because shared work competes with the next feature for budget.
Choosing a rendering strategy too early buys complexity without proving value
Teams sometimes propose server-side rendering as a default answer to slow pages. That reverses the decision. First identify which pages need useful content before JavaScript finishes, which pages must be indexed, and which pages are available only after login. Rendering is a response to those requirements; it is not a quality badge. The cost of getting the order wrong appears in deployment, caching, and authentication work that may do nothing for the affected users.
Client-rendered React with Vite 6 wins for a signed-in tool when search indexing is irrelevant and an existing static deployment is simple to operate. Its cost is that the initial HTML may contain little useful content, so users can wait on JavaScript and data requests before seeing the page they need. Server-rendered Next.js 15 wins when public routes need crawlable content or faster useful HTML under the team’s actual network conditions. Its cost is a server runtime, more cache decisions, and another place where authenticated data can be exposed if boundaries are wrong. Neither option wins merely because its demo loads quickly on a developer’s laptop.
Put numbers against the decision using production traffic. Google publishes a 2.5-second Largest Contentful Paint threshold and assesses it at the 75th percentile of visits; that field measure matters more than a single fast local run because it includes the devices and networks customers use. Segment the data by route and device before selecting work, since an aggregate can hide one slow but commercially important journey. Use Chrome UX Report where coverage exists, or instrument the app with the web-vitals library when route-level evidence is missing.
A rendering change also needs a data plan. If a server-rendered page fetches personalized data, specify its cache policy and how the response varies by session. If a client-rendered page uses an API response with an ETag, test whether an HTTP 304 actually avoids transferring unchanged data; a cache header that never produces a cache hit has no user benefit. These checks belong in scope because the page can render sooner yet still wait just as long for the action the user came to complete.
Do not approve “move to SSR” as a single backlog item. Approve a named set of routes, a before-and-after measurement method, and the operational changes those routes require. That makes the trade-off reviewable if the first migrated route shows little improvement.
A performance budget fails when nobody prices the work required to enforce it
“Keep it fast” is not an acceptance criterion, because a team cannot determine which release should fail. Set budgets for the experiences that matter, distinguish field data from lab tests, and name who will investigate a breach. Otherwise, performance becomes optional whenever it conflicts with a feature deadline.
Google’s published “good” threshold for Interaction to Next Paint is 200 milliseconds at the 75th percentile; that makes it a useful field target for responsiveness, not a promise that every click finishes within that time. Google also publishes a 0.1 threshold for Cumulative Layout Shift, which helps identify unstable layouts that move controls while someone is trying to use them. Neither metric tells a PM how much engineering time remediation will take. A slow interaction may require profiling a third-party script, reducing a large React render, or changing an API-dependent flow—three very different scopes.
A CI check can still catch a severe regression before release. The following Bash snippet runs against a locally served app with Chrome and Node.js available. It uses Lighthouse 12 to fail on a lab LCP above 2,500 milliseconds; that cutoff is a team gate to tune, not a substitute for the field percentile.
set -euo pipefail
URL="${URL:-http://localhost:3000/}"
npx --yes lighthouse@12 "$URL" \
--chrome-flags="--headless --no-sandbox" \
--only-categories=performance \
--output=json --output-path=/tmp/lh.json --quiet
node -e 'const r=require("/tmp/lh.json"); const l=r.audits["largest-contentful-paint"].numericValue; console.log(`Lab LCP: ${Math.round(l)} ms`); if(l>2500) process.exit(1)'
The snippet is deliberately narrow. Lighthouse measures a controlled run, so its result can change with the test machine and cannot establish what real users experience. Pair it with route-level field telemetry and investigate regressions rather than treating the CI number as an SLA. A 20% contingency in a performance-remediation estimate is a planning allowance to adjust after profiling, because the cause of a slow page is often unclear until the team records a trace. Booking that investigation time is more honest than promising that every red score is a quick fix.
Scope enforcement as ongoing work, too. Someone must maintain test fixtures, review bundle changes in tools such as webpack Bundle Analyzer or Vite’s visualizer plugin, and decide whether a third-party script is worth its cost. Without that owner, a budget is a document that the next release can quietly ignore.
Polish work gets expensive when teams defer contracts and accessibility
Teams often leave error handling and accessibility until the feature is “done,” because the happy path is easier to demo. That sequencing increases cost: a late discovery can require changes to the API contract, component structure, copy, and tests at once. A PM should therefore treat these states as part of the feature definition, not as a final pass.
Read Frontend Development Best Practices for Modern Web Apps with the API contract beside you, because generic advice cannot expose inconsistent error states in your product. For each important action, specify what the user sees when a request times out, validation fails, permission changes, or saved data conflicts with another edit. An OpenAPI 3.1 description can document response shapes, but it will not decide whether a user should retry, correct an entry, or contact an administrator. Those choices require product and design time.
Accessibility has the same scoping problem. WCAG 2.2 gives testable criteria, while axe-core can flag many implementation defects; neither replaces checking whether a person can finish a task with a keyboard and screen reader. Schedule that task-level check while the interaction is being designed, because changing a custom dropdown’s keyboard behavior after it is reused across the app can affect every form. Use Playwright to preserve the intended flow in regression tests, but leave time for manual checks where automated assertions cannot judge clarity.
A useful acceptance review follows one complete journey rather than sampling attractive screens. Can a user find the form, understand its labels, recover from an invalid submission, survive an expired session, and confirm that the result was saved? If the team cannot answer those questions for the primary journey, “frontend complete” is a misleading status. The cost is not simply a bug count; it is a release decision made without evidence that the feature works outside its easiest state.
The first approval should be for evidence, not implementation
Commission a short route audit before funding the build: select the primary journey, map its shared dependencies and failure states, and capture baseline field performance for its routes. Ask engineering and design to return with separate estimates for the visible change, contract work, testing, and remediation. Then approve the smallest release that can prove the chosen approach works under real conditions.