Proposal: Provision of edu.au Website Build

Education Services Australia occupies a unique position in the Australian education landscape — a not-for-profit company owned by all Australian Ministers of Education, serving as the bridge between national education policy and practical digital delivery. Unlike typical government agencies or commercial entities, ESA must balance ministerial accountability, cross-jurisdictional coordination, and direct service delivery to education institutions across Australia.

The edu.au Domain Registrar is a critical piece of national education infrastructure. As the sole registrar for the closed edu.au second-level domain, it carries both regulatory authority (operating within auDA licensing rules) and a service obligation to make registration requirements clear and accessible to a diverse audience — from school administrators to university IT departments to government education bodies.

We understand that this rebuild is not an isolated project. It sits within ESA's broader Digital Services portfolio alongside the myfuture and SCIS platform rebuilds, representing a strategic investment in modernising ESA's digital foundations. Our approach to the edu.au build is designed with this context in mind — establishing reusable patterns, infrastructure, and ways of working that can create efficiency across ESA's portfolio.

We also recognise that ESA's internal teams need to own and evolve these platforms long after the initial build. This is not a project where a vendor builds something clever and walks away — it requires genuine partnership, knowledge transfer, and technology choices that ESA's team can confidently maintain.

Proposed Technology Stack

Our recommended stack is purpose-built for ESA's requirements: low maintenance, high flexibility, open source, and straightforward for your Technology team to adopt and maintain.

Front-end: Next.js (React)

• Industry-leading React framework with built-in server-side rendering (SSR) and static site generation (SSG)
• Delivers exceptional page load performance and SEO out of the box — directly supporting the objective of increased direct traffic
• Decoupled from the back-end, satisfying ESA's preference for front-end/back-end separation
• Huge developer ecosystem reduces long-term hiring and maintenance risk for ESA
• Built-in image optimisation, code splitting, and edge caching for device-optimised delivery

CMS / Back-end: Directus

• Open-source, self-hosted headless CMS with a mature, well-maintained codebase
• Provides both REST and GraphQL APIs natively — matching ESA's preference for API-driven architecture
• Intuitive admin interface that non-technical content authors can manage independently
• Role-based access control, content workflows, and approval processes built in
• Database-agnostic (PostgreSQL recommended) — no vendor lock-in
• Fully extensible via custom extensions and hooks
• Self-hosted within GovZone, ensuring complete data sovereignty

Infrastructure

• Containerised deployment (Docker) for consistent environments across SIT, UAT, PROD in GovZone
• CI/CD pipeline via GitLab CI (aligning with ESA's GitLab requirement)
• PostgreSQL database with automated backups and point-in-time recovery
• CloudFront or equivalent CDN for static asset delivery and edge caching
• Infrastructure as Code (Terraform/Pulumi) for reproducible, auditable deployments

Search: Meilisearch (self-hosted)

• Fast, typo-tolerant site search with relevance tuning
• Self-hosted within GovZone for data sovereignty compliance

Email Integration

• Componentised integration layer allowing easy swap of email service providers
• Newsletter subscriber capture via Directus with preference centre functionality
• Webhook-based sync to email platform (e.g., Campaign Monitor, Mailchimp)

Architecture Overview

┌─────────────────────────────────────────────────┐
│                   CDN / Edge                     │
├─────────────────────────────────────────────────┤
│         Next.js Front-end (SSR/SSG)             │
├─────────────────────────────────────────────────┤
│              API Layer (REST + GraphQL)          │
├──────────────┬──────────────┬───────────────────┤
│   Directus   │    Search    │  Email Service    │
│   (CMS)      │   Engine     │  Integration      │
├──────────────┴──────────────┴───────────────────┤
│            PostgreSQL Database                   │
├─────────────────────────────────────────────────┤
│         GovZone Infrastructure (Docker)          │
└─────────────────────────────────────────────────┘

Security and Compliance

ISM Classification 'OS'

• All data stored and processed within GovZone
• Encryption at rest (AES-256) and in transit (TLS 1.3)
• Role-based access control across all systems
• Security artifacts: SSP Annexes and associated control documentation will be prepared, reviewed, and maintained as part of delivery
• Regular vulnerability scanning and dependency auditing via CI/CD pipeline

OWASP Top 10 and ASVS L1

• Security-first development practices with automated SAST/DAST scanning
• Input validation, output encoding, CSRF protection, and Content Security Policy headers
• Dependency vulnerability monitoring (Dependabot/Snyk integration in GitLab)

WCAG 2.1 AA Compliance

• Accessibility built into the design system from day one
• Automated accessibility testing in CI/CD (axe-core)
• Manual testing with screen readers and keyboard navigation
• Accessibility audit prior to launch

Privacy

• Cookie consent management
• Privacy-by-design principles applied throughout
• No data leaves Australian borders
• Compliant with Australian Privacy Principles (APPs)

GovZone Deployment Strategy

• Containerised builds that are environment-agnostic
• GitLab CI pipelines that push to GovZone's container registry
• Infrastructure as Code for all environment provisioning
• Separate configuration management for SIT/UAT/PROD
• All secrets managed via GovZone-approved secrets management

Scalability and Maintenance

• Static generation for public pages means near-zero server load for most traffic
• Incremental Static Regeneration for dynamic content (news, events) without full rebuilds
• Horizontal scaling of API layer if traffic demands grow
• Directus plugin/extension model means product team can add new content types without developer involvement
• Automated security patching via CI/CD dependency update workflows

Project Approach

We follow a lean agile methodology adapted for fixed-scope government projects. This means structured phases with clear sign-off gates, but agile delivery practices within each phase.

Phase 1: Discovery & Requirements — 2 weeks

• Workshop with ESA product team, Technology team, and key stakeholders
• Review existing edu.au website, analytics, and content audit
• Information architecture review and simplification
• Finalise detailed requirements and acceptance criteria
• Establish shared tooling (GitLab, Jira/Azure DevOps, Slack/Teams channel)

Phase 2: Design — 3 weeks

• Wireframes for all key page templates and user journeys
• Brand refresh integration into design system
• Design review with ESA stakeholders
• Accessibility review of designs
• Design sign-off gate

Phase 3: Build — 6–8 weeks

• 2-week sprints with ESA Technology team embedded
• Sprint demos every 2 weeks
• Progressive deployment to SIT environment
• Content migration running in parallel with build
• Automated testing built alongside features

Phase 4: Testing & Training — 2–3 weeks

• UAT in GovZone UAT environment
• CMS training sessions for content authors
• Accessibility audit and remediation
• Performance and security testing
• Bug fix sprints

Phase 5: Launch — 1 week

• Staged deployment to PROD
• DNS cutover and monitoring
• Go-live support

Phase 6: Hypercare & Handover — 4 weeks

• Dedicated support for post-launch issues
• Technology team training (architecture, deployment, maintenance)
• Knowledge base documentation finalised
• Handover sign-off

How We Work With Your Team

We treat co-development as a core project requirement, not an afterthought. Our approach:

Embedded Collaboration

• ESA developers have full access to the GitLab repository from day one
• Shared branch strategy: feature branches, merge requests with mandatory code review
• ESA team members assigned to specific features/modules based on their learning goals
• Daily standups (async or sync, ESA's preference) and pair programming sessions

Code Quality Standards

• Shared linting and formatting rules (ESLint, Prettier) enforced via pre-commit hooks
• All code goes through merge request review — both Rocket Lab and ESA reviewers
• Minimum unit test coverage targets for all new code
• Integration tests for API endpoints and critical user journeys
• Automated CI pipeline: lint → test → build → security scan → deploy to SIT

Knowledge Transfer

• Architecture decision records (ADRs) for all significant technical choices
• Weekly code walkthrough sessions during build phase
• Documented deployment runbook
• Recorded training sessions for async learning

Skill Development

• Hands-on workshops: Next.js fundamentals, Directus administration, Docker/containerisation
• Progressively increasing ESA team ownership during build (observer → contributor → owner)
• Handover sprints where ESA team leads development with Rocket Lab in support role

Documentation Deliverables

• Architecture diagrams (C4 model)
• API documentation (auto-generated from code)
• CMS administration guide
• Deployment and operations runbook
• Troubleshooting guide with known issues and resolutions
• ISM compliance documentation

See also Part 5 (Previous Experience) below for full project detail.

Summary of Relevant Experience

See also Part 8 (Personnel) below for full detail on each team member.

Team Overview

See also Part 12 (Pricing) below for full pricing detail.

Value Proposition

Our approach delivers exceptional value for money for ESA by:

• Open source first: Next.js and Directus eliminate licensing costs — zero per-seat or per-page charges, ever
• Co-development reduces long-term cost: ESA's internal team can handle ongoing maintenance independently after handover, eliminating ongoing vendor dependency for routine changes
• Cross-portfolio efficiency: Patterns and infrastructure established in edu.au are directly reusable for myfuture and SCIS — reducing total cost of ownership across ESA's portfolio
• Milestone-linked payment: Pricing is linked to delivery milestones, ensuring ESA only pays for delivered outcomes
• Fixed scope with assumptions: Clear assumptions table ensures ESA understands the scope baseline, with a transparent change request process for variations

Four examples of relevant project experience demonstrating capability for this engagement:

Project 1

Project 2

Project 3

Project 4

Our solution for the edu.au website rebuild uses a modern, open-source, decoupled architecture purpose-built for ESA's requirements: low ongoing maintenance, high editorial flexibility, WCAG 2.1 AA accessibility, and full compliance with ESA's hosting and security requirements.

Detailed timeline subject to GovZone environment availability and ESA stakeholder availability for workshops and sign-off gates. Specific milestone dates will be agreed at project kick-off.

Head of Engineering

Technical Lead

UX/UI Designer

Project Manager

Front-end Developer

Referee 1

Referee 2

Total Price

Price Breakdown by Phase

Pricing Assumptions

• ESA provides timely access to GovZone environments and CI/CD integration points
• ESA provides existing brand assets and guidelines for the brand refresh
• Content migration covers existing edu.au website content; new content creation is ESA's responsibility
• ESA team members are available for co-development activities as agreed in project kick-off
• Pricing is based on the indicative timeline in Schedule 2; material changes to timeline may affect pricing

Ongoing Maintenance (Optional)