Technical Guide: Building School Websites

Forge Schools websites are built with performance, accessibility, and maintainability in mind. Here is our standard stack:

**Framework:** Next.js (React-based, server-side rendering for SEO) **Styling:** Tailwind CSS (utility-first, consistent design system) **Hosting:** Vercel (automatic deployments, global CDN, free tier) **CMS:** Content managed through structured data files (no database needed) **Images:** Optimized with Next.js Image component, served from Vercel

**Why this stack:** - Fast page loads even on slow connections (critical in Africa) - SEO-friendly out of the box - Free hosting with generous limits - Easy for multiple volunteers to contribute - Low maintenance overhead

Each school website follows a standard template:

**Step 1: Clone the Template** Clone the forge-school-template repository from our GitHub organization.

**Step 2: Configure School Data** Edit the central configuration file with the school's information: name, location, colors, contact details, and content.

**Step 3: Add Images** Place optimized images in the public directory. Follow our naming conventions: hero.jpg, classroom-1.jpg, staff-principal.jpg, etc.

**Step 4: Customize Styling** Adjust the color scheme in the Tailwind config to match the school's brand colors.

**Step 5: Test Locally** Run the development server and verify all pages render correctly on desktop and mobile.

**Step 6: Deploy** Push to GitHub and Vercel deploys automatically. Share the preview URL with the school contact for review.

Every Forge Schools website must meet these performance targets:

**Lighthouse Scores (minimum):** - Performance: 90+ - Accessibility: 95+ - Best Practices: 95+ - SEO: 95+

**Core Web Vitals:** - Largest Contentful Paint (LCP): Under 2.5 seconds - First Input Delay (FID): Under 100ms - Cumulative Layout Shift (CLS): Under 0.1

**How to achieve this:** - Use Next.js Image component for all images (automatic optimization) - Minimize external scripts (no heavy analytics, no chat widgets) - Use system fonts or self-hosted fonts (no external font requests) - Implement lazy loading for below-the-fold images - Keep the bundle size under 100KB gzipped

Performance is not optional. Many of our school visitors are on 2G or 3G connections with limited data plans.

Our websites must be accessible to all users:

**Required:** - Semantic HTML (proper heading hierarchy, landmark elements) - Alt text on every image - Keyboard navigation works for all interactive elements - Color contrast ratio of 4.5:1 minimum for text - Focus indicators visible on all interactive elements - Forms have proper labels and error messaging - Language attribute set on the html element

**Testing:** - Run axe-core in the browser on every page - Navigate the entire site using only keyboard - Test with screen reader (VoiceOver on Mac, NVDA on Windows) - Verify in high-contrast mode - Test at 200% browser zoom

Accessibility is a human right, not a feature. We do not ship without it.

Before a site goes live, it must pass code review:

**Self-Review Checklist:** - All content is accurate and complete - No placeholder or lorem ipsum text - Images are optimized and have alt text - Site is responsive from 320px to 1920px - Contact form works and sends to correct email - All links work (no 404s) - Meta tags and Open Graph data are configured - Favicon is set

**Peer Review:** - Submit a pull request to the school's repository - Another developer reviews the code - Address all feedback before merging - Final QA check on the production URL

**Handoff to School:** - Share the live URL with the school contact - Walk them through how to request changes - Document any school-specific customizations - Provide a simple guide for content update requests

Your code will be maintained by future volunteers. Write it as if the person reading it has never seen the project before, because they probably have not.