Toggle Side Panel
Close search
Back to Course

Website Development: From Fundamentals to Deployment

0% Complete
0/0 Steps
  1. Lesson 1: Web Foundations (HTML, CSS, JavaScript)
    4 Topics
  2. Lesson 2: Responsive Design and Accessibility
    4 Topics
  3. Lesson 3: Modern Front-end Development (Frameworks and State)
    3 Topics
  4. Lesson 4: Back-end Fundamentals, Data, and Security
    4 Topics
  5. Lesson 5: Quality, Performance, SEO, and Deployment (DevOps Basics)
    5 Topics

Participants 8

Show more
Lesson Progress
0% Complete

This topic focuses on delivering two common real-world website builds to production standard:

  1. A CMS-based website (content managed by non-developers).
  2. A Progressive Web App (PWA) (fast, installable, works offline or on poor connections).

By the end, you should be able to choose the right approach, integrate a content workflow, add PWA features, and deploy a capstone project with confidence.

1) When to Use a CMS (and When Not To)

A Content Management System (CMS) helps teams create and update content without changing code.

Use a CMS when:

  • Content changes often (news, products, events, blogs, notices).
  • Non-technical editors need to update pages.
  • You need workflows (draft → review → publish).
  • You need roles and permissions (e.g., authors vs publishers).
  • You need multi-language content, scheduled publishing, or reusable content blocks.

Avoid (or reconsider) a CMS when:

  • The site is mostly static and changes rarely.
  • The content model is very small (a few pages) and you want maximum simplicity.
  • Performance requirements are extreme and content does not need frequent edits (a static site may be best).

Common CMS options (high level)

  • Traditional CMS (e.g., WordPress): pages served from the CMS, often theme-based.
  • Headless CMS (e.g., Strapi, Contentful, Sanity): CMS stores content, your front-end fetches content via API.

Rule of thumb:
If you want design and front-end freedom while still enabling content editing, headless CMS is often a strong choice.

2) Content Models: Designing Content for Real Work

Before building pages, define your content model: the types of content and fields you need.

Example content types

  • Post/Article
    • title, slug, summary, body, featureImage, category, tags, author, publishDate, SEO fields
  • Product/Service
    • name, description, price (if applicable), images, features, availability
  • Page
    • title, slug, pageSections (repeatable), SEO fields

Good content modelling practices

  • Prefer structured fields (e.g., “publish date”) over messy rich text.
  • Create reusable blocks (e.g., hero section, FAQ, testimonial).
  • Include SEO metadata fields (title, description, social image).
  • Keep a consistent slug strategy (URL-friendly identifiers).

3) Integrating Content Workflows (Draft, Review, Publish)

A production website often needs more than “edit and publish”.

Workflow stages (typical)

  • Draft: writers create content.
  • In review: editors check quality, tone, legal, factual accuracy.
  • Published: visible to the public.
  • Archived: removed from public view but kept for records.

Roles and permissions (typical)

  • Author: can create and edit drafts.
  • Editor/Publisher: can approve and publish.
  • Admin: manages users, settings, and content types.

Practical workflow tips

  • Define a content checklist for every publish:
    • Headings are correct (H1 once, logical order)
    • Links work
    • Images have alt text
    • SEO title/description filled in
    • No placeholder text
  • Use preview environments so editors can review changes before going live.

4) CMS Integration Approaches

A) Traditional CMS site

  • The CMS renders pages directly.
  • Pros: fast to set up, editing built-in.
  • Cons: front-end flexibility can be limited; performance and security depend heavily on plugins and configuration.

B) Headless CMS + front-end app

  • Your website (React/Vue/Angular or even static site generator) fetches content via API.
  • Pros: modern front-end, strong performance options, flexible design.
  • Cons: you must build the front-end and content rendering logic.

Common integration patterns

  • Build-time rendering (static generation): content is fetched during build; very fast site; requires rebuild to update content.
  • Server-side rendering (SSR): content is fetched on request; content updates immediately; needs server runtime.
  • Hybrid: some pages static, others dynamic.

When content changes daily and must be immediate, SSR or a hybrid approach is often better. For marketing sites with periodic updates, static generation is usually excellent.

5) PWA Essentials: What Makes a Web App a PWA?

A Progressive Web App is a website with app-like features such as offline support and installability.

Key PWA capabilities

  • Works on unreliable networks (offline fallback, caching strategies)
  • Installable (Add to Home Screen / install prompt on supported devices)
  • Fast and responsive
  • Secure (served over HTTPS)
  • App-like experience (standalone display mode, icons, splash screen)

Minimum technical requirements

  • A valid Web App Manifest (e.g., manifest.webmanifest)
  • A registered Service Worker
  • Served via HTTPS

6) Implementing Offline Support with Service Workers

A service worker is a background script that can intercept network requests and decide whether to serve cached content.

What to cache

  • App shell: core HTML, CSS, JS, fonts, logo
  • Offline page: a friendly fallback for navigation requests
  • Key content: most-used pages or API responses (where appropriate)

Caching strategies (choose intentionally)

  • Cache-first
    • Good for: static assets (CSS/JS/images that rarely change)
    • Risk: users may see old content if cache invalidation is not handled
  • Network-first
    • Good for: content that must be up to date (news, prices)
    • Benefit: falls back to cache when offline
  • Stale-while-revalidate
    • Good for: content where “slightly outdated is OK”
    • Benefit: fast response, updates in the background

Offline UX expectations

When offline, users should still be able to:

  • Open the app
  • Navigate to previously visited pages (where possible)
  • See a clear offline message for content that cannot be loaded

Tip: Make offline behaviour a planned feature, not an accident. Provide an offline banner or status indicator.

7) Installability: Manifest, Icons, and User Experience

Manifest essentials

Your manifest should include:

  • name and short_name
  • start_url
  • display (often standalone)
  • background_color and theme_color
  • A set of icons in multiple sizes (e.g., 192×192, 512×512)

Install prompts (practical guidance)

  • Don’t annoy users with constant prompts.
  • Offer installation after the user has shown intent (e.g., after returning twice, or after completing a task).
  • Provide a visible “Install app” button where appropriate.

8) Data and Content in PWAs (including CMS Content)

If your PWA uses CMS content, decide how to handle content in low-connectivity scenarios.

Options

  • Cache key routes (top pages, last-read articles).
  • Cache API responses with a network-first strategy.
  • Store some data locally (e.g., IndexedDB) for offline reading lists.

Be careful with:

  • Sensitive data (don’t store tokens or personal info in unsafe ways).
  • Stale content (show “last updated” timestamps when relevant).
  • Cache size (clean up old cached items).

9) Capstone Delivery: From “Works on My Machine” to Production-Ready

Your goal is a deployment that is:

  • Reliable (repeatable builds, predictable releases)
  • Fast (optimised assets, caching, good Core Web Vitals)
  • Discoverable (SEO basics in place)
  • Accessible (WCAG-aligned)
  • Secure (HTTPS, safe headers, dependency checks)

Production readiness checklist (CMS + PWA)

Content and CMS

  • Content types match real business needs
  • Draft/review/publish workflow in place
  • Roles and permissions configured
  • Content previews available (if relevant)

PWA

  • Manifest valid and tested
  • Service worker registered and working
  • Offline fallback page works
  • Caching strategy documented (what is cached and why)
  • Installability tested on at least one mobile device

Quality

  • Basic automated tests pass (unit/integration as appropriate)
  • Manual smoke test: navigation, forms, login (if any), error states

Performance

  • Images optimised (correct formats, lazy loading where appropriate)
  • Minified assets and compression enabled (Brotli/Gzip on host)
  • Lighthouse run and key issues addressed (especially Performance + Accessibility)

SEO

  • Unique page titles and meta descriptions
  • Correct heading structure
  • robots.txt and sitemap where applicable
  • Clean URLs and canonical tags (if needed)

Security

  • HTTPS enforced
  • Dependencies updated and audited
  • No secrets committed to Git
  • Basic security headers configured where supported

10) Deployment Approach for the Capstone

Recommended environments

  • Development: local machine + local CMS (or CMS dev space)
  • Staging/Preview: automatic deploy on pull requests for review
  • Production: manual approval or controlled merge-to-main releases

CI/CD basics (typical flow)

  1. Developer pushes changes to a branch.
  2. CI runs:
    • linting
    • tests
    • build
  3. If successful, deploy to preview/staging.
  4. After review, merge to main triggers production deploy.

CMS deployment considerations

  • Keep CMS configuration versioned where possible (content types, settings).
  • Manage secrets via your hosting platform’s environment variables.
  • Plan for backups and restore procedures.
  • If using a hosted headless CMS, focus on environment separation (dev vs prod spaces).

11) What to Submit (Capstone Expectations)

For your CMS + PWA capstone, you should be able to provide:

  • A live URL (production deployment)
  • A Git repository with clear commit history and README
  • A short delivery note including:
    • CMS choice and why it suits the use case
    • Content types created and workflow used
    • PWA features implemented (offline behaviour and installability)
    • Any known limitations and next steps

Knowledge Check (Self-Assessment)

Answer these before you consider your capstone “done”:

  1. Why did you choose a CMS (or headless CMS) for this project?
  2. What content types and fields did you model, and why?
  3. Which caching strategy did you apply, and what risks does it introduce?
  4. What happens when a user goes offline mid-session?
  5. Can a non-developer update the site content safely without breaking layout?
  6. If you deploy a bug, how quickly can you roll back or redeploy?

Practical Activity: Capstone Delivery Sprint

Complete the following in order:

  1. Content model: finalise 2–4 content types with required fields (including SEO fields).
  2. Workflow setup: configure roles + draft/review/publish.
  3. Front-end integration: render CMS content with consistent components and accessible markup.
  4. PWA implementation:
    • add manifest + icons
    • register service worker
    • implement offline fallback
    • choose caching strategy for assets and content
  5. Quality gates: run tests, fix failures, run Lighthouse and address major issues.
  6. Deploy: set up CI/CD, deploy to staging, then production.
  7. Handover: write README + delivery notes and share the live link.