Definition of Done for Web Apps: The Battle-Tested Template for Modern Teams

16 Mar, 2026 Web Development 0 Comments

Tired of the “Friday Afternoon Fever”? You know the one: Developers say a feature is “done.” QA finds a CSS ghost in staging. Stakeholders push to prod anyway. By 6:00 PM, you’re firefighting an XSS vulnerability or a broken checkout flow on mobile Safari.

A vague Definition of Done (DoD) is the root cause of engineering burnout. This guide provides a high-performance template specifically for web applications—covering code quality, Core Web Vitals, accessibility, and security.Whether you’re shipping a React/Next.js SaaS, a Vue dashboard, or an enterprise-grade portal, this checklist scales to your risk profile. Copy, customise, and ship with actual confidence.

Why “Generic” DoDs Fail Web Teams

Vague checklists like “Code written and tested” are a recipe for technical debt. In the modern web ecosystem, “Done” isn’t a feeling; it’s a verifiable state across seven critical layers:

The Performance Trap: “It works on my machine” → Lighthouse scores tank to 40 in production.
The Mobile Blindspot: “QA approved” → The layout breaks on the latest Galaxy or iPhone aspect ratios.
The Security Gap: “Auth verified” → A PII leak via console.log hits your logs (and your GDPR compliance).

The Complete Web App DoD Template

Integrate this into your Jira, Linear, or GitHub PR templates. Use these as your “Quality Firewall.”

Level 1: Code Quality & Engineering Standards

Standards Enforced: Code passes ESLint/Prettier with no “temporary” overrides.
Meaningful Testing: Unit tests pass with 80%+ coverage (focusing on business logic, not just getters/setters).
Peer Reviewed: At least one senior approval with zero unresolved “nitpicks.”
No Dependency Debt: Snyk or Dependabot shows zero high/critical vulnerabilities in new packages.
Docs or it Didn’t Happen: README, API schemas (OpenAPI/Swagger), and Storybook components updated.
Clean History: Commits follow Conventional Commits.

Level 2: Functional & Cross-Platform Verification

AC Met: 100% of Acceptance Criteria verified in a staging environment.
The “Big Four” Browsers: Verified on the latest 2 versions of Chrome, Firefox, Safari, and Edge.
Real-Device Mobile: Verified on actual devices via BrowserStack or physical hardware—not just DevTools emulators.
E2E Stability: Playwright or Cypress smoke tests pass for critical user journeys.
Resilience: Error states (404, 500, Offline mode) tested and gracefully handled.

Level 3: The “Modern Web” (Perf & A11y)

Core Web Vitals (CWV):
- LCP (Largest Contentful Paint) ≤ 2.5s
- INP (Interaction to Next Paint) ≤ 200ms
- CLS (Cumulative Layout Shift) ≤ 0.1
Accessibility (A11y): axe DevTools scan is “Clean” (zero critical issues) according to WCAG 2.1 AA standards.
Keyboard Navigation: Full feature flow accessible without a mouse.
Lighthouse Scores: Desktop ≥ 90, Mobile ≥ 85.

Level 4: Security & Compliance

Auth Flow Rigour: Login/Logout, Session Expiry, and RBAC verified in a prod-like config.
Data Privacy: No PII (names, emails, tokens) leaked in console.log.
Protection: OWASP Top 10 mitigations active (CSRF/XSS headers); API rate limiting verified.

Level 5: Deployment Readiness

Rollback Plan: A documented “Big Red Button” strategy is tested.
Feature Flags: LaunchDarkly or custom toggles configured.
Observability: Sentry/Datadog alerts live; “Heartbeat” monitors active.
Stakeholder Sign-off: The Product Owner provides the final “Vibe Check” in staging.

4 Weeks to a Frictionless Process

Week 1
Analyse your last three “Post-Mortems.”

Week 2
Automate. We help teams architect delivery pipelines that scale.

Week 3
Apply the DoD to one high-impact feature.

Week 4
Measure your Defect Escape Rate.

A great Definition of Done is a “Quality Firewall.” It stops issues before they become expensive production incidents, reduces “on-call” anxiety, and lets your engineers move faster because they aren’t constantly looking over their shoulders.

Is your release process a source of stress?

At Xtensible, we don’t just write code; we architect delivery pipelines that scale. We audit your current process, build stack-specific DoDs, and implement the automation needed to keep your Lighthouse scores high and your “Friday Fires” low.

Contact Xtensible today for a release process your team—and your stakeholders—can actually trust.

FAQs

What is the difference between Acceptance Criteria and DoD?

Acceptance Criteria (AC) are unique to a specific feature (e.g., “The user can pay via UPI”). The Definition of Done (DoD) is a global standard applied to every story (e.g., “Code is linted, tested, and accessible”). Think of AC as the ‘what’ and DoD as the ‘how well’.

Should a small startup use the full 7-layer DoD?

No. Startups should focus on a “Minimum Viable DoD”: Peer reviews, unit tests for critical paths, and staging verification. As your team grows and the cost of failure increases, you scale up to include automated performance and security scans.

How does a strict DoD affect development velocity?

Initially, velocity might appear to dip as the team adjusts. However, long-term velocity increases because you spend 80% less time on bug fixes, hotfixes, and “Friday afternoon” fires. You trade chaotic speed for predictable delivery.

Is accessibility (A11y) really mandatory for “Done”?

Yes. Beyond legal compliance, Google now uses Core Web Vitals and accessibility signals for search rankings. If your app isn’t keyboard-navigable or screen-reader friendly, it is technically and commercially “unfinished.”

How often should we update our Definition of Done?

Review your DoD quarterly or after a major tech stack change (e.g., migrating from Webpack to Vite). If you find the same type of bug escaping to production repeatedly, add a specific check to your DoD to catch it next time.