A polished front-end prototype is easier to produce than it was two years ago. That has made the first demo a worse basis for a delivery estimate: the screens appear finished before anyone has proved the data, interactions, or performance. Product managers should scope a tested user journey first and treat framework selection as a decision within that scope, not the milestone that defines it.
A one-day demo no longer proves a one-week build
From late 2024 to 2026, faster scaffolding, component libraries, and AI-assisted code generation have shortened the path to a convincing interface. That change matters to planning because a generated screen can look complete while its loading, error, permission, and keyboard states remain unspecified. The old advice to estimate the remaining work by counting unfinished screens is therefore less reliable: one screen connected to real data can contain more work than several static ones.
I would revise the framework checklist (Vet Framework Claims Before You Scope the Build) to demand a tested user journey rather than a recommendation. Framework claims still deserve scrutiny, but they are rarely the largest uncertainty once a team can assemble a credible demo quickly. The harder question is whether a particular user can finish a particular task against the actual API, including what happens when the request is slow, rejected, or repeated.
For the first estimate, choose one journey that crosses the boundaries likely to cause rework. A “change account details” journey might include an authenticated read, an editable form, validation, a saved response, an authorization failure, and a second browser tab showing the updated value. Record which states exist in Figma, which responses exist in the API contract, and which remain assumptions. OpenAPI can make request and response shapes reviewable, but it cannot establish whether the product behavior is acceptable when a user loses connectivity halfway through a save.
Price the journey as three deliverables: a working implementation, acceptance checks, and time to resolve findings. A planning allowance of 20% of the journey estimate for findings is a value to tune after the first slice; it is not a universal rework rate. If the first slice exposes substantial API changes, update the estimate for later slices rather than quietly spending the allowance. That gives a product manager an observable reason to change scope before a launch date becomes a promise.
I would not approve a broad UI build from a clickable prototype and a framework recommendation, because neither demonstrates how the product handles real responses or failed interactions. A small vertical slice may feel slower than approving every screen at once, but it buys an estimate based on completed work rather than on the speed of producing pictures.
“Fast UI” advice is outdated when it stops at the build
A quick Vite 7 development server and a fast production interaction answer different questions. Vite can shorten the edit-and-preview loop, which is valuable to the team, but that result does not tell a product manager how the shipped page behaves on a constrained phone. I would use the speed checklist (Modern Front-End Development Tips for Faster UI) only after naming the page, device class, and user action whose speed matters.
The measurement vocabulary has also changed. First Input Delay is outdated as a primary Core Web Vital because Interaction to Next Paint (INP) replaced it in 2024 and accounts for interaction responsiveness more broadly. Google’s published “good” boundary for INP is 200 milliseconds; that figure is a user-experience reference, not a promise that every development build will meet it. Google’s corresponding Largest Contentful Paint (LCP) boundary is 2.5 seconds, but an LCP improvement will not fix a form that freezes after the user presses Save.
Use Chrome DevTools and Lighthouse to diagnose a reproducible page, then check Chrome UX Report (CrUX) field data where the site has enough traffic. Lighthouse is useful for finding a heavy script or a delayed image, but a single lab run should not become the release estimate because it cannot represent every device, network, and interaction. CrUX reports the experience of actual Chrome users, yet a new route may have insufficient data; in that case, collect your own browser measurements and say plainly that they are provisional.
A performance task should identify its likely cause and the proof needed to close it. “Improve dashboard performance” is hard to price. “Keep the filter interaction responsive while a large result set updates” can be investigated with the DevTools Performance panel, tested on a specified device, and separated from any API latency work. As an initial target to adjust with user data, test at the 75th percentile of recorded sessions rather than celebrating only the fastest run. State the sample size alongside the result, because a handful of internal sessions does not establish production performance.
This distinction changes scope. If the delay comes from rendering thousands of rows, front-end work such as virtualization may be appropriate. If it comes from a slow endpoint, rewriting components is unlikely to help because the browser is waiting for data. Estimate those investigations separately before assigning a single “speed optimization” ticket to the UI team.
Standards now remove some build work, but they do not remove verification
Some front-end advice still assumes a JavaScript solution for every layout and state change. That can inflate scope when browser capabilities already cover the requirement. CSS container queries, for example, let a component respond to the space available to it rather than to the viewport width. For a card reused in a sidebar and a full-width panel, an @container rule may be simpler to maintain than JavaScript measuring each instance with ResizeObserver.
The choice is not automatic. CSS container queries win when the requirement is visual adaptation to a component’s available space; they cost layout testing across the containers in which that component appears. ResizeObserver wins when JavaScript needs an element’s dimensions to drive behavior, such as calculating a chart’s drawing area; it costs observer lifecycle code and protection against unnecessary updates. Choosing the JavaScript option merely because a demo already uses it can create work that a CSS rule would avoid.
Likewise, React 19 form Actions can reduce custom pending-state code for a straightforward submission, while TanStack Query v5 may earn its place when several screens share server state and need explicit cache invalidation. React Actions win for a contained form whose submission lifecycle is the main problem; their cost is still designing validation and failure behavior. TanStack Query wins when coordinating fetched data is the main problem; its cost is cache policy, query keys, and tests for stale or invalidated results. Treating either library as a blanket requirement adds setup without first establishing which problem exists.
WCAG 2.2 should also be part of the acceptance criteria, not a repair ticket after the visual build, because keyboard and focus requirements can affect component structure. For the account-details journey, specify where focus goes after a failed save and how the error is announced. Playwright can exercise that path in a browser, while manual keyboard and screen-reader checks remain necessary because an automated pass cannot establish that the interaction makes sense. The estimate should include both kinds of verification rather than assume accessibility is a final styling pass.
Before accepting a proposal to replace custom code with a browser feature, check the project’s supported browsers against Baseline availability data and test the specific behavior. Standards can reduce implementation effort; they do not make a compatibility decision on the product manager’s behalf.
A scoped acceptance test is more useful than a tooling promise
Turn the first journey into a release agreement that another person can check. Specify the account, starting data, action, expected response, visible confirmation, keyboard path, and failure state. Mark unresolved API or design decisions as dependencies with owners. This is more useful than a statement that the team will “use TypeScript and tests,” because TypeScript can check declared types while a perfectly typed interface still saves the wrong value.
Keep automated checks close to the risks they address. Use Playwright for the browser journey, an API contract check for the agreed OpenAPI responses, and GitHub Actions to run both on a pull request. A simple Node.js 20 probe can also give a team a repeatable staging check before it invests in detailed performance analysis:
node --input-type=module <<'JS'
import { performance } from 'node:perf_hooks';
const url = process.env.STAGING_URL ?? 'http://localhost:3000/';
const start = performance.now();
const response = await fetch(url);
const headersAt = performance.now();
const html = await response.text();
console.log({ status: response.status, responseHeaderMs: Math.round(headersAt - start), bytes: Buffer.byteLength(html) });
if (!response.ok || !html.includes('<main')) process.exitCode = 1;
JS
Run it against a reachable staging page by setting STAGING_URL. Its response-header time is a diagnostic from that machine, not an LCP or INP measurement; the distinction prevents a convenient script from being mistaken for user evidence. Its immediate value is narrower: it catches an unavailable page or missing main content and records a comparable response for that environment.
Set an adjustable two-week ceiling for the first vertical slice if the team can deliver and review it within that period; split the slice if it cannot. The ceiling is a planning constraint, not an industry benchmark. At review, ask which assumptions were confirmed, which failed, and which acceptance checks still cannot run. A failure to get representative credentials, data, or API access is a scope risk that should be visible on the plan, not hidden inside a front-end estimate.
The next estimate should start with one contested journey
At the next planning session, pick the user journey the team disagrees about most and write its success, failure, and keyboard acceptance checks before discussing a delivery date. Ask engineering to build that slice against representative data and report what changed in the estimate. If the disagreement survives a working, tested journey, it is worth a planning conversation; if it does not, you have avoided scheduling work around a polished but incomplete demo.
