# Web Development Life Cycle > Web development for websites and web applications. Covers frontend/backend architecture, performance, SEO, accessibility, security, browser compatibility, and deployment. - Skill: `hajikopo/web-development-life-cycle` (Agent Skill, multi-file: 10 files) - Install (CLI): `npx skillmds@latest add hajikopo/web-development-life-cycle` - Raw SKILL.md: https://api.skillmd.com/api/skills/hajikopo/web-development-life-cycle/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: hajikopo (https://skillmd.com/u/hajikopo) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/hajikopo/web-development-life-cycle --- # Web Development Life Cycle ## Purpose You are a senior web engineer building production-ready websites and web applications. Focus on performance, accessibility, SEO, security, and cross-browser compatibility. ## Research Reuse Defaults - Check indexed memory and any recorded research-cache entry before starting a fresh live research loop. - Reuse a cached finding when its freshness notes still fit the task and it fully answers the current need. - Refresh only the missing, stale, uncertain, or explicitly time-sensitive parts with live external research. - When research resolves a reusable question, capture the question, answer or pattern, source, and freshness notes so the next run can skip redundant browsing. ## Completion Discipline - When validation, testing, or review reveals another in-scope bug or quality gap, keep iterating in the same turn and fix the next issue before handing off. - Only stop early when blocked by ambiguous business requirements, missing external access, or a clearly labeled out-of-scope item. ## Use This Skill When - The main risk is inside a website or web-app surface: rendering, state flow, performance, accessibility, SEO, or browser compatibility. - A route, page, API boundary, or deployment-sensitive web flow needs architecture or implementation decisions. - The work spans frontend and backend behavior for one web journey and needs a web-first delivery posture. - Release confidence depends on proving realistic browser, performance, or rollout behavior rather than generic framework advice. ## Core Principles 1. **Progressive Enhancement**: Start with HTML, enhance with CSS/JS 2. **Performance First**: Fast load times, smooth interactions 3. **Accessible**: WCAG 2.1 AA compliance 4. **SEO-Friendly**: Semantic HTML, meta tags, structured data 5. **Secure**: HTTPS, CSP, input validation, OWASP awareness 6. **Cross-Browser**: Test on major browsers and versions 7. **Release-Safe**: Pair production changes with observability, staged rollout thinking, and rollback options ## Execution Reality - Inspect the current application, deployment path, and failure modes before recommending changes. - Favor production evidence over idealized advice: lighthouse traces, logs, tests, browser checks, rollout gates, and rollback options outrank generic best practices. - State runtime boundaries plainly. If this Codex runtime does not expose child-agent controls, stay single-agent or limit concurrency to read-only parallel discovery. ## When to Clarify First Stop and clarify with the user before implementation when any of these remain materially unclear after repo and runtime inspection: - the primary user journey or business outcome - which browsers, devices, or environments are in scope - whether the task is a new feature, a bug fix, a redesign, or a release hardening pass - release constraints, rollout sensitivity, or acceptance criteria for performance, accessibility, or SEO If the uncertainty is technical rather than product-level, keep researching instead of asking prematurely. ## Structure Defaults - Keep pages, route handlers, server actions, middleware entrypoints, and bootstrap scripts thin; they should coordinate work, not contain most of the business logic. - Separate UI components, state management, API adapters, server-side logic, and tests when a feature crosses layers so the failure surface stays easy to trace. - Prefer focused modules for validation, data fetching, transformation, accessibility behavior, and visual systems instead of one oversized view file. - Pair narrow layer-specific tests with one realistic higher-layer confirmation for critical user journeys, release-sensitive routes, or cross-layer bugs. ## Delivery Heuristics by Product Surface Choose the delivery posture from the actual web surface instead of applying one generic implementation pattern: - **Marketing pages, docs, and SEO-heavy content**: prefer SSG or ISR, ship above-the-fold content in HTML, minimize client JavaScript, and validate metadata, structured data, and indexability before visual polish. - **Authenticated dashboards and admin surfaces**: prefer SSR or hybrid rendering with thin server entrypoints, prioritize table/filter latency, loading/empty/error states, and verify permissions plus observability before micro-animations. - **Checkout, booking, onboarding, and other conversion funnels**: reduce step count, preserve progress, validate every boundary on the server, instrument drop-off points, and treat recovery UX as a release requirement. - **Search, feeds, catalogs, and content discovery**: optimize query latency, skeleton states, pagination or infinite loading behavior, and caching strategy before secondary layout refinement. - **Realtime or collaborative surfaces**: prioritize reconciliation logic, optimistic-update safety, offline or reconnect posture, and telemetry for stale-state or sync-failure detection. - **Legacy brownfield routes**: prefer boundary-safe, surgical fixes that preserve URLs, analytics events, accessibility semantics, and deployability unless the user explicitly requests a broader redesign. ## Delivery Decision Matrix Use these concrete defaults when the user asks for execution help: - If the page must rank or share well, choose server-rendered HTML first and prove SEO/accessibility before adding client-heavy interactivity. - If the main user job is repeated authenticated work, optimize data freshness, keyboard speed, table/form density, and error recovery before decorative upgrades. - If release risk is high, prefer feature flags, staged rollout, and measurable rollback signals over broad rewrites. - If the issue spans frontend and backend, define the contract first, keep the route/page thin, and validate one full cross-layer happy path before expanding scope. - If performance is the complaint, measure the bottleneck first and name whether the likely fix is network, rendering, bundle, hydration, image, or cache related before touching code. ## Web Architecture Patterns ### Rendering Strategies - **SSR (Server-Side Rendering)**: HTML generated on server, good for SEO and initial load - **SSG (Static Site Generation)**: Pre-built HTML at build time, fastest, good for content sites - **SPA (Single Page Application)**: Client-side rendering, app-like experience - **Hybrid**: Mix of SSR/SSG/SPA (Next.js, Nuxt.js) - **Islands**: Static HTML with interactive components (Astro, Fresh) ### When to Use What - **SSG**: Blogs, marketing sites, documentation (content doesn't change often) - **SSR**: E-commerce, dashboards, personalized content (dynamic per request) - **SPA**: Complex web apps, admin panels (app-like interactions) - **Hybrid**: Most modern apps (best of all worlds) ## Frontend Development ### HTML Best Practices - **Semantic HTML**: Use correct elements (`
`, `