Professional Digital Skills — Batch 10

Theory / Why: Each page needs one primary user task.

Practical: List Home, Services, Pricing, About and Contact; assign one distinct search intent to each.

Expected output: Five-row page-to-intent map

Common error / caution: Avoid using the same target phrase on every page.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Search bots must be allowed to request public pages.

Practical: Review robots.txt and response status; note any accidental Disallow rules.

Expected output: Crawl access checklist

Common error / caution: Robots.txt is not a security mechanism.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: A page can be crawlable but marked noindex.

Practical: Inspect meta robots, X-Robots-Tag and canonical URL for each sample page.

Expected output: Indexability table

Common error / caution: A noindex directive overrides your publishing intent.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Titles should describe the actual page purpose.

Practical: Write unique concise titles for all five pages; include service and distinguishing context naturally.

Expected output: Five title drafts

Common error / caution: Do not stuff repetitive keywords.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Semantic headings improve readability and document organization.

Practical: Ensure one meaningful h1 per page and ordered h2 sections for questions, proof and actions.

Expected output: Heading outline

Common error / caution: Visual font size does not determine heading semantics.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Link text should explain the destination.

Practical: Replace three generic “click here” labels with descriptive service or contact links.

Expected output: Updated link map

Common error / caution: Avoid links pointing to # when no target exists.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Large assets can slow first render.

Practical: Resize one hero image to display dimensions, use modern encoding and meaningful alt text.

Expected output: Before/after size log

Common error / caution: Do not add alt text that repeats surrounding prose.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Performance is experienced by users on real devices.

Practical: Run Lighthouse on a locally served page and record LCP, CLS and accessibility findings.

Expected output: Baseline audit

Common error / caution: Local and production results can differ.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: A sitemap lists preferred discoverable URLs.

Practical: Create sitemap.xml with five canonical absolute URLs for the example site.

Expected output: Validated XML sitemap

Common error / caution: Do not include noindex or staging URLs.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Ownership verification enables reports, not ranking guarantees.

Practical: Document domain/property verification steps; in a real owned site submit sitemap and inspect coverage.

Expected output: Verification checklist

Common error / caution: Never request access to another owner’s property.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Structured data must reflect visible factual content.

Practical: Draft Organization JSON-LD with accurate name and URL; validate with a structured-data checker.

Expected output: Validated JSON-LD draft

Common error / caution: Schema markup does not guarantee rich results.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: SEO requires recurring validation after deployment.

Practical: Record baseline impressions, clicks, CTR, page status and next review date in a tracker.

Expected output: SEO maintenance sheet

Common error / caution: Allow for reporting delays and avoid claiming instant results.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Measurement starts with decisions, not tags.

Practical: Write three questions: which channel brings visitors, which page helps, how many enquiries finish.

Expected output: Measurement brief

Common error / caution: Avoid collecting unnecessary identifiers.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Events need consistent names and parameters.

Practical: Define page_view, service_view and generate_lead with non-sensitive parameters.

Expected output: Event specification

Common error / caution: Do not send names, email addresses or phone numbers as event parameters.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Production and testing traffic should be separated.

Practical: Use a test GA4 property or documented mock; record measurement ID format without publishing secrets.

Expected output: Test environment checklist

Common error / caution: Do not confuse measurement IDs with private API credentials.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Duplicate tracking inflates counts.

Practical: Choose one installation method: direct gtag or Tag Manager, and document it.

Expected output: Single-source installation plan

Common error / caution: Do not deploy both without deduplication.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Single-page apps may need explicit route tracking.

Practical: Navigate three demo routes and inspect Tag Assistant or DebugView events.

Expected output: Route event log

Common error / caution: Check for double page_view on route changes.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: A click is not the same as a qualified enquiry.

Practical: Add a named click event to the demo contact CTA and verify once per interaction.

Expected output: CTA test result

Common error / caution: Avoid calling every click a conversion.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Conversions should occur after validation and success.

Practical: Fire generate_lead only after the demo form shows a successful confirmation.

Expected output: Lead event evidence

Common error / caution: Never trigger on failed submissions.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Analytics storage depends on local legal and policy requirements.

Practical: Document consent categories and test analytics disabled before consent where required.

Expected output: Consent test matrix

Common error / caution: Do not bypass consent choices.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Only meaningful outcomes belong in conversion reporting.

Practical: Mark the verified generate_lead event as a key event in a test setup.

Expected output: Key event definition

Common error / caution: UI terminology can change; check current docs.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Channels should be compared using consistent metrics.

Practical: Create a table for source/medium, sessions and key events using sample values.

Expected output: Channel comparison

Common error / caution: Small samples can mislead.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Missing and duplicate events invalidate conclusions.

Practical: Test three sessions: page only, CTA only, completed enquiry; reconcile expected events.

Expected output: QA matrix

Common error / caution: DebugView and reports may update at different speeds.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Analytics should lead to a practical next experiment.

Practical: Recommend one landing-page improvement and one measurable hypothesis.

Expected output: One-page insights memo

Common error / caution: Correlation does not prove causation.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Automation should solve a real customer need.

Practical: Select appointment enquiries; define office hours and expected reply time.

Expected output: Use-case statement

Common error / caution: Do not promise 24/7 human support.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Marketing messages require appropriate opt-in.

Practical: Write an opt-in checkbox text and record consent source and time.

Expected output: Consent record schema

Common error / caution: Do not import purchased contact lists.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Clear identity builds trust.

Practical: Draft business description, website, hours and contact method for a sample profile.

Expected output: Profile checklist

Common error / caution: Do not invent verified badges.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Labels help staff triage conversations.

Practical: Define New, Qualified, Awaiting Info, Scheduled and Closed.

Expected output: Five-label workflow

Common error / caution: Avoid overlapping status meanings.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Reusable responses should still feel relevant.

Practical: Draft greeting, requirements request and closing reply with placeholders.

Expected output: Three quick-reply templates

Common error / caution: Never send sensitive data in public groups.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Bots cannot resolve every issue.

Practical: Specify triggers for human handoff: payment issue, complaint, ambiguity.

Expected output: Escalation decision tree

Common error / caution: Make handoff visible to customers.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: App features and API capabilities differ.

Practical: Document manual app workflows versus official Business Platform integration.

Expected output: Capability comparison

Common error / caution: Unofficial bulk-sending tools risk account restrictions.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Incoming messages need authentication and idempotency.

Practical: Sketch verify → receive → validate → deduplicate → route → respond.

Expected output: Webhook diagram

Common error / caution: Do not expose access tokens in frontend JavaScript.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Business-initiated messages may need approved templates.

Practical: Draft one appointment reminder and note required opt-in and template review.

Expected output: Template draft

Common error / caution: Do not assume every message can be sent outside the service window.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Chat data may contain personal information.

Practical: Set minimal retention, role access and deletion request workflow.

Expected output: Privacy checklist

Common error / caution: Avoid copying entire chats into shared spreadsheets.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Testing should not contact real customers unexpectedly.

Practical: Run three scripted cases: normal enquiry, opt-out, escalation.

Expected output: Three-case QA report

Common error / caution: Verify STOP/opt-out handling.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Response quality matters more than message volume.

Practical: Track median first response, resolution and opt-out rates.

Expected output: Service dashboard plan

Common error / caution: Never use spam volume as success metric.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: AI output depends on explicit acceptance criteria.

Practical: Specify users, fields, success states, privacy rules and offline behavior.

Expected output: Requirements document

Common error / caution: Do not start with “build me an app” alone.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Technology should match hosting and skill constraints.

Practical: Compare static site + backend, Flutter + Firebase and PWA for this use case.

Expected output: Decision matrix

Common error / caution: Do not assume free tiers are unlimited.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Consistent UI starts with layout rules.

Practical: Write a prompt describing mobile-first navigation, accessibility and existing brand colors.

Expected output: UI design brief

Common error / caution: Do not replace existing Astra design in production.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Semantic structure improves accessibility.

Practical: Ask AI for accessible HTML form with labels, errors and confirmation area.

Expected output: HTML draft

Common error / caution: Inspect generated markup manually.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Mobile widths need intentional constraints.

Practical: Request CSS Grid/Flexbox layout and test at 360, 768 and 1280px.

Expected output: Responsive screenshots

Common error / caution: Avoid fixed-width elements causing horizontal scroll.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Client validation helps UX but does not secure a backend.

Practical: Implement required-field checks and length limits; define server validation separately.

Expected output: Validation test cases

Common error / caution: Never trust browser validation alone.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Access control must be enforced server-side.

Practical: Describe least-privilege read/write rules for submitted enquiries.

Expected output: Security rule specification

Common error / caution: Never use allow read, write: if true in production.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Generated code may contain errors or insecure patterns.

Practical: Run lint and dependency checks; inspect auth, logging and secret handling.

Expected output: Code review checklist

Common error / caution: Do not paste real credentials into AI prompts.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Tests should target expected user outcomes.

Practical: Create tests for valid submit, missing field, duplicate submit and unauthorized read.

Expected output: Four-case test plan

Common error / caution: A passing mock test is not a production security audit.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Version history enables safe changes.

Practical: Use a feature branch, meaningful commits and peer-review checklist.

Expected output: Pull request draft

Common error / caution: Do not commit .env secrets.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Staging allows realistic checks before public release.

Practical: Deploy to a non-production URL; test mobile and network failure states.

Expected output: Staging QA report

Common error / caution: Do not expose real user data in staging.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: A prototype is not complete without operating instructions.

Practical: Write setup, environment variables, known limits and rollback steps.

Expected output: Handover README

Common error / caution: Label untested functions explicitly.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Security prioritizes what matters.

Practical: List accounts, credentials, customer records, source code and build keys.

Expected output: Asset register

Common error / caution: Do not store production keys in shared documents.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Data crosses browser, app, API and database boundaries.

Practical: Draw user → frontend → API → database and mark auth checks.

Expected output: Trust-boundary diagram

Common error / caution: Frontend hiding is not authorization.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Threat modeling focuses effort on likely misuse.

Practical: Write misuse cases for stolen session, public database and leaked token.

Expected output: Threat list

Common error / caution: Use authorized test environments only.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Login identity and permission are different.

Practical: Define MFA for admins, password reset and session expiry requirements.

Expected output: Authentication policy

Common error / caution: Do not log passwords or OTPs.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Server-side rules prevent horizontal access.

Practical: Specify that user A cannot read user B records; create negative test cases.

Expected output: Access-control matrix

Common error / caution: Avoid trusting userId sent by client without validation.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Secrets must not be embedded in public bundles.

Practical: Search sample repository for keys; move sensitive values to secure server configuration.

Expected output: Secret scan report

Common error / caution: Rotate any accidentally exposed credentials.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Untrusted input can trigger injection and unsafe rendering.

Practical: Use parameterized SQL and safe DOM text insertion in a demo.

Expected output: Input handling example

Common error / caution: Do not concatenate user input into SQL.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Old libraries may contain known vulnerabilities.

Practical: Review dependency lockfile and advisories; plan safe updates.

Expected output: Dependency audit

Common error / caution: Test upgrades before deployment.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Transport security protects data in transit.

Practical: Inspect TLS status, mixed content and secure cookie flags on owned test site.

Expected output: HTTPS checklist

Common error / caution: HTTPS does not replace authorization.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Logs should aid diagnosis without exposing private data.

Practical: Redact tokens, passwords and sensitive form fields in sample logs.

Expected output: Sanitized log sample

Common error / caution: Never upload real customer logs publicly.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Recovery steps should be decided before an incident.

Practical: Document revoke credentials, isolate issue, notify owner and restore backups.

Expected output: Incident playbook

Common error / caution: Do not claim breach resolution without evidence.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Security checks should block unsafe releases.

Practical: Create checklist for auth tests, secret scan, dependency audit and backup restore.

Expected output: Release sign-off sheet

Common error / caution: A checklist does not replace professional penetration testing.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Hosting choice depends on traffic, data and runtime.

Practical: Write expected users, file size, backend need and budget limits.

Expected output: Hosting requirements

Common error / caution: Avoid claiming a free tier is permanent.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Static and server workloads need different services.

Practical: Compare static hosting, managed functions and VPS operational duties.

Expected output: Platform matrix

Common error / caution: Check current limits before selecting.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Reproducible builds require clean source structure.

Practical: Create src, public, tests and README in a sample project.

Expected output: Repository tree

Common error / caution: Do not include generated secrets.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: DNS points names to services; propagation is not instant.

Practical: Document A, AAAA and CNAME options for example.com without changing live records.

Expected output: DNS plan

Common error / caution: Do not modify production DNS without backup.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Secure origin is required for many PWA features.

Practical: Document HTTPS certificate issuance and renewal checks.

Expected output: TLS checklist

Common error / caution: Do not use self-signed certs for public deployment.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: A web app manifest describes install identity.

Practical: Draft name, short_name, start_url, display and icon paths.

Expected output: manifest.webmanifest

Common error / caution: Icons must exist at referenced paths.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Caching should not preserve sensitive pages indefinitely.

Practical: Define cache-first for static assets and network-first for dynamic content.

Expected output: Cache strategy

Common error / caution: Do not cache authentication responses indiscriminately.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Service workers require secure contexts in production.

Practical: Add a scoped registration and test installability in browser DevTools.

Expected output: Registration test

Common error / caution: file:// does not provide a reliable PWA test environment.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Broken links should fail before deployment.

Practical: Run static link validation and syntax tests in CI.

Expected output: Build checklist

Common error / caution: Static checks cannot prove runtime behavior.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Preview releases reduce production risk.

Practical: Publish a test branch to staging and check paths, icons and 404s.

Expected output: Staging verification

Common error / caution: Avoid exposing unpublished customer data.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Deployment needs observability and error feedback.

Practical: Track uptime, console errors and version in a release log.

Expected output: Release log

Common error / caution: Do not confuse successful upload with working features.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Recovery must be tested before an emergency.

Practical: Document how to restore previous build and purge stale service worker cache.

Expected output: Rollback runbook

Common error / caution: Cache invalidation can delay visible changes.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Clear positioning makes proposals specific.

Practical: Define a five-page responsive website service for a local business.

Expected output: Service definition

Common error / caution: Avoid offering unsupported skills.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Not every enquiry is a fit.

Practical: Ask about audience, pages, content, timeline and decision maker.

Expected output: Discovery questionnaire

Common error / caution: Do not ask for passwords during discovery.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Scope prevents disputes about deliverables.

Practical: Specify five pages, one revision round and excluded integrations.

Expected output: Statement of work

Common error / caution: Avoid vague “unlimited changes” promises.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Pricing should cover work, revisions and risk.

Practical: Estimate design, build, QA, meetings and contingency hours.

Expected output: Effort worksheet

Common error / caution: Do not invent market-rate guarantees.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Proposals should connect client goals to deliverables.

Practical: Write problem, solution, timeline, assumptions and acceptance criteria.

Expected output: Client proposal

Common error / caution: Use fictional client details for practice.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Milestones make approval and payment expectations clear.

Practical: Create discovery, design approval, build and launch checkpoints.

Expected output: Milestone schedule

Common error / caution: Confirm terms before starting paid work.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: A quick visual reduces misunderstanding.

Practical: Sketch home, services and contact sections for mobile and desktop.

Expected output: Wireframe

Common error / caution: Check contrast and navigation labels.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Early preview reveals content gaps.

Practical: Create a static prototype with sample text and working navigation.

Expected output: Prototype URL or local preview

Common error / caution: Label placeholder content clearly.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: A website is not finished when it merely looks attractive.

Practical: Test links, forms, mobile widths, keyboard and 404 pages.

Expected output: QA checklist

Common error / caution: Do not mark untested items as passed.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Accessibility expands usability and reduces errors.

Practical: Check labels, focus visibility, alt text and semantic headings.

Expected output: Accessibility findings

Common error / caution: Automated tools do not catch every issue.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Clients need ownership and maintenance guidance.

Practical: Provide source files, deployment steps, asset rights and backup instructions.

Expected output: Handover package

Common error / caution: Transfer credentials securely, not by public document.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.

Theory / Why: Recurring support needs boundaries.

Practical: Draft monthly update scope, response times and exclusions.

Expected output: Maintenance offer

Common error / caution: Do not promise guaranteed traffic or revenue.

Practice check: Explain the reason for this step in your own words, save the expected artifact, and verify it against the stated goal.