Web Development Services Glossary of Terms
The terminology used across web development service engagements spans technical standards, contractual frameworks, and delivery methodologies — often applied inconsistently across vendors, clients, and regulatory contexts. This glossary defines the core terms encountered when scoping, procuring, or evaluating web development services types, covering both technical vocabulary and project management language. Precise definitions reduce scope disputes, support accurate RFP construction, and align expectations between technical and non-technical stakeholders.
Definition and scope
A web development services glossary functions as a controlled vocabulary: a reference set of terms with defined meanings, classification boundaries, and usage contexts specific to the professional delivery of web-based software and digital experiences.
The scope of this glossary covers five primary domains:
- Delivery model terms — language describing how services are structured and delivered (e.g., agile sprint, waterfall phase, retainer, fixed-bid)
- Technical architecture terms — vocabulary describing system structure and technology choices (e.g., monolith, microservices, headless, API-first)
- Compliance and standards terms — regulatory and standards-body language (e.g., WCAG, ADA, HTTPS, GDPR-adjacent obligations)
- Contract and procurement terms — legal and commercial language used in engagement documents (e.g., SLA, SOW, NDA, IP assignment)
- Performance and measurement terms — metrics and testing vocabulary (e.g., Core Web Vitals, LCP, CLS, uptime SLA)
The World Wide Web Consortium (W3C) publishes the foundational technical specifications — including HTML, CSS, and accessibility standards — that underpin much of this vocabulary. Definitions grounded in W3C specifications carry normative authority over vendor-specific usage.
How it works
Glossary terms in web development contexts operate at three levels: normative (defined by a standards body or statute), semi-normative (widely adopted industry convention), and colloquial (vendor-specific or informal). Distinguishing these levels prevents contractual ambiguity.
Key defined terms:
- Front-end development — The implementation of user interface components rendered in a browser, typically using HTML, CSS, and JavaScript. See front-end development services for service-level detail.
- Back-end development — Server-side logic, database management, and API construction that supports the application layer invisible to the end user. See back-end development services.
- Full-stack development — A delivery model in which a single practitioner or team handles both front-end and back-end responsibilities. Full-stack development services are frequently offered at a blended hourly rate.
- CMS (Content Management System) — A software platform enabling non-technical users to create, manage, and publish web content without direct code modification. WordPress, Drupal, and Contentful represent distinct CMS architecture categories.
- Headless CMS — A CMS architecture that decouples the content repository (back end) from the presentation layer (front end), delivering content via API to any rendering environment. Detailed at headless CMS development.
- Progressive Web App (PWA) — A web application that uses service workers, HTTPS, and a web app manifest to deliver app-like capabilities — including offline access and push notifications — through a standard browser. The W3C Service Workers specification defines the underlying standard.
- API (Application Programming Interface) — A defined contract for communication between software components, specifying request format, authentication, and response structure. REST and GraphQL represent the two dominant API architectural styles in web development.
- WCAG (Web Content Accessibility Guidelines) — Normative guidelines published by the W3C Web Accessibility Initiative (WAI) specifying how web content must be made perceivable, operable, understandable, and robust. WCAG 2.1 Level AA is the threshold referenced by the U.S. Department of Justice in ADA-related web accessibility guidance.
- Core Web Vitals — A set of 3 user experience metrics defined by Google's web.dev documentation: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), used as ranking signals in Google Search.
- SLA (Service Level Agreement) — A contractual commitment specifying minimum performance thresholds (e.g., 99.9% uptime = approximately 8.7 hours of allowable downtime per year) and remediation obligations.
- SOW (Statement of Work) — A binding project document defining deliverables, timelines, acceptance criteria, and payment milestones for a discrete engagement.
- Discovery phase — A pre-development engagement phase focused on requirements gathering, technical scoping, and stakeholder alignment before build work begins. See web development project discovery phase.
- Technical debt — Accumulated development shortcuts or outdated architectural decisions that increase the cost and risk of future changes. The Software Engineering Institute at Carnegie Mellon has characterized technical debt as a measurable cost driver in long-lived software systems.
Common scenarios
Glossary misalignment generates identifiable failure modes across engagement types:
- A client issuing an RFP requests a "responsive website" without specifying WCAG 2.1 AA compliance. The vendor delivers a mobile-adaptive layout that fails automated accessibility testing, generating post-launch remediation costs. Accurate use of web accessibility compliance services terminology in the RFP would have specified the normative standard.
- An enterprise buyer contracts for "API integration" without defining whether the scope includes authentication, error handling, and rate-limit management. The resulting SOW omits those components. The API development and integration service category encompasses all three.
- A startup selects a headless CMS vendor based on marketing language describing "omnichannel delivery" without understanding that headless architecture requires separate front-end development effort — often 40–60% of total project cost on a decoupled build.
Decision boundaries
Normative vs. colloquial terms: When a term appears in a W3C specification, an RFC (Request for Comments published by the Internet Engineering Task Force), or a statute, that definition governs over vendor usage. "Secure" in a contract clause, for example, carries no enforceable standard unless tied to a named framework such as NIST SP 800-53 or OWASP Top 10.
Fixed-bid vs. time-and-materials: These are distinct contractual structures with different risk allocation. Fixed-bid concentrates scope-change risk on the vendor; time-and-materials shifts it to the client. Neither is superior — the appropriate choice depends on requirements certainty at contract signing. See web development pricing models for a structured comparison.
Agile vs. waterfall delivery: Agile (iterative sprints, typically 2-week cycles) suits projects with evolving requirements. Waterfall (sequential phases with defined gates) suits projects with stable, fully specified requirements. Hybrid models exist but require explicit definition in the SOW to avoid delivery disputes.
PWA vs. native mobile app: A PWA operates within browser sandboxing constraints and cannot access all device hardware APIs. A native app compiled for iOS or Android has full hardware access but requires separate codebases and App Store distribution. The distinction is architectural, not cosmetic, and affects both budget and maintenance obligations.
References
- W3C — World Wide Web Consortium
- W3C Web Accessibility Initiative (WAI) — WCAG 2.1
- W3C Service Workers Specification
- Internet Engineering Task Force (IETF) — RFC Index
- Google web.dev — Core Web Vitals
- NIST SP 800-53, Rev 5 — Security and Privacy Controls
- OWASP Top 10
- U.S. Department of Justice — Web Accessibility Guidance