The modern web dev checklist that actually matters
People keep asking about the modern checklist for web development. The short answer is there isn't one universal document. What exists are a series of mental checklists that every team builds based on what keeps breaking in production. I am going to walk through the one I use, the one my team uses, and the things we learned the hard way. Start with infrastructure and environment. Before any framework is chosen, before any component is written, you need a clear pipeline. CI/CD configured, branch protection rules in place, environment variables managed through a proper secrets vault, and a staging environment that mirrors production as closely as possible. I once skipped the secrets vault step on a project because the client wanted to move fast. Three weeks later we had credentials exposed in a GitHub action log. It took me six hours to rotate every key and audit access. Never skip the vault step. The workflow takes maybe twenty minutes to set up properly and saves you from that kind of mess. Next comes the architecture decision. This is where people get stuck reading comparison articles. The reality is simpler than the articles suggest. Pick the stack your team already knows. If you need SSR or SSG, choose a framework that supports it natively rather than bolting on a separate tool. Hybrid rendering is fine when you need it, but adding a separate node server just for dynamic pages on top of a static site generator usually creates more problems than it solves.
Performance and Core Web Vitals
Core Web Vitals are not optional anymore. Google has been using them for ranking for years, and users will leave your site if it feels slow regardless of what the search algorithm does. The checklist here is straightforward but most people get it wrong. LCP — Largest Contentful Paint. Your hero image or main content block needs to load within 2.5 seconds. Use next-gen image formats like WebP or AVIF, implement lazy loading for images below the fold, and consider using a CDN. I worked on a site where the LCP was dominated by an improperly sized banner image. The file was 3.2 megabytes. We resized it to responsive breakpoints and dropped it to 180 kilobytes. LCP went from 4.1 seconds to 1.3 seconds. That is the kind of change that moves the needle. CLS — Cumulative Layout Shift. This measures visual stability. If elements jump around as the page loads, users get frustrated. The main culprits are images and ads without explicit width and height attributes, web fonts causing text swap, and dynamically injected content. Set explicit dimensions on media elements. Use CSS will-change sparingly. Reserve space for ad slots before they load. I once spent an afternoon tracking down a CLS issue caused by a third-party chat widget that injected itself into the DOM after initial paint. The fix was wrapping it in a container with a minimum height and a background color so the layout had a placeholder ready.
INP — Interaction to Next Paint. This replaced FID in March 2024. It measures how responsive your page is to user interactions. The target is under 200 milliseconds. Heavy JavaScript bundles, long-running main thread tasks, and synchronous operations are the enemies here. Break up long tasks using requestIdleCallback or similar patterns. Code-split your JavaScript. Defer non-critical scripts. Profile your interactions in Chrome DevTools rather than guessing.
Get the Full Details
Accessibility Requirements
Accessibility is not a nice-to-have. It is a legal requirement in many jurisdictions and a practical necessity. Screen reader users, keyboard-only users, and people with motor impairments all depend on proper markup. But beyond compliance, accessible sites tend to be better structured and easier to maintain. Check your heading hierarchy. H1 through H6 should follow a logical order. Do not skip levels. Verify that all interactive elements are focusable and visible. Test with a keyboard alone. Navigate your entire site using only Tab and Enter. If you get stuck or cannot find something, you have a problem. Color contrast must meet WCAG AA at minimum. Tools like axe DevTools or Lighthouse can catch a lot of issues, but they miss context-dependent problems. Have a real person test your site with assistive technology whenever possible. I had a project where the automated tools passed everything, but a screen reader user told us the navigation was impossible because the skip-link had no tabindex and could not be reached on a certain browser and screen reader combination. That would never have shown up in an automated scan.
Security Fundamentals
Security checklists are usually either too generic or too specific to one stack. Here is what applies across the board regardless of whether you are using React, Vue, Django, or Laravel. HTTPS everywhere. No exceptions. Even on internal staging, though that is a separate discussion. Use HSTS headers with a reasonable max-age. Implement Content Security Policy headers, even if you have to start with a report-only mode and gradually tighten it. I remember a project where we shipped a CSP header on day one in restrictive mode without testing. It blocked our own analytics script, our logging endpoint, and a legitimate third-party payment widget. We spent two days in report-only mode mapping every violation before enabling enforcement. Do not skip the report-only phase. Input validation and output encoding. This sounds basic because it is basic, but it is also where most vulnerabilities come from. Validate on the server side regardless of client-side validation. Never trust data from the user. Sanitize outputs to prevent XSS. Use parameterized queries to prevent SQL injection. Keep dependencies updated. Run automated scans in your CI pipeline. I recently audited a project that had a known vulnerable version of a popular logging package. It was listed as a dev dependency but was being pulled into the production bundle because the build tool was misconfigured. A single npm audit run would have caught it, but it was buried under hundreds of other warnings that nobody reviewed. Make security audits part of your regular process, not a one-time event.
Testing Strategy
Testing is where most teams either do too little or do the wrong kind. Unit tests for pure logic. Integration tests for API contracts and data flow. End-to-end tests for critical user paths. That distribution works for most projects. Do not write unit tests for things that change constantly like UI components with complex styling. Those tests break more often than they catch bugs. Do not write end-to-end tests for things that happen once a month. Those tests rot and waste maintenance time. Focus your E2E tests on the three to five paths that actually make money or deliver core value. Login, checkout, search, account creation, password reset. Test those thoroughly. Everything else gets lighter coverage. I learned this the hard way on a project where we had 800 E2E tests covering every possible button state and animation. The suite took forty-seven minutes to run. We merged fixes to unrelated features and broke three critical checkout flows because the test coverage was spread too thin on the paths that mattered. We cut the suite down to sixty-five tests focused on core flows. Run time dropped to six minutes. Bug capture rate improved significantly.
Deployment and Monitoring
Your checklist is not complete until you have a deployment strategy and monitoring in place. Blue-green or canary deployments are standard for good reason. They reduce risk when you push to production. Never do a direct deployment without a rollback plan. I have seen teams deploy at 4 PM on a Friday without a rollback strategy. It was not a good day. Monitoring needs to cover errors, performance, and availability. Set up structured logging. Track error rates and latency percentiles. Configure alerts that actually matter. An alert that fires at 2 AM because a non-critical background job slowed down is worse than no alert. Configure your alerts around user-facing impact. If users can notice it, it deserves an alert. If only your ops team can see it in a dashboard, a dashboard notification is sufficient. Log aggregation is another area where shortcuts cost money later. ELK stack, Datadog, Loggly, whatever you choose, make sure your logs are structured and searchable. Plain text logs with inconsistent formats are a nightmare to query when something breaks at scale. Standardize on JSON logs from the start. It adds maybe ten minutes per endpoint during development and saves hours during an incident.
Documentation and Maintenance
Documentation is the part of the checklist that everyone acknowledges and then ignores until it is too late. README files that describe how to set up the project locally, API documentation that stays in sync with the code, architecture decision records for significant choices, and operational runbooks for common failure scenarios. None of this requires novel-length documents. One or two pages per topic is usually sufficient. The maintenance aspect is equally important. Dependencies need updating regularly. Security patches should be applied on a schedule. Deprecated APIs need migration plans. Browser compatibility requirements change. I track browser support requirements at the start of every project and revisit them quarterly. What was acceptable two years ago may not be acceptable today, and vice versa. There is no final version of this checklist. The web changes constantly. New APIs appear, old ones get deprecated, browser engines diverge and then converge again. The practical approach is to treat your checklist as a living document that gets updated after every project. What broke, what worked, what surprised you. Add those lessons to the list. That is how the checklist stays useful.
