Proposal: Provision of myfuture Platform Rebuild

Education Services Australia is uniquely positioned as the operational arm of Australia's education ministers — a not-for-profit entity that must deliver commercially viable digital products while serving a public-good mission. This dual mandate shapes everything about how myfuture needs to work: it must be as polished and engaging as any commercial career platform, yet inclusive, evidence-based, and accountable to every jurisdiction in Australia.

myfuture's strength is its position as a trusted, national, non-commercial career education platform at a time when the career education space is increasingly fragmented by commercial providers targeting narrow audiences. The rebuild opportunity is to amplify this advantage — delivering a modern, personalised experience that commercial competitors can't match because they lack myfuture's breadth, evidence base, and institutional trust.

We understand that myfuture serves fundamentally different audiences with different needs — students exploring careers for the first time, educators embedding career education in curriculum, parents seeking guidance for their children, and jurisdiction administrators tracking engagement at scale. The platform must serve all of these well, not just the most visible user group.

We also recognise this project sits within ESA's broader Digital Services portfolio. Our approach is designed to establish technology patterns and co-development practices that create value across ESA's digital transformation, not just for myfuture in isolation.

Critically, this is a platform that must evolve continuously. The career landscape changes, data sources update, and user expectations grow. The rebuild must create a foundation for ongoing innovation, not just a point-in-time delivery. This is why co-development and knowledge transfer are not optional extras — they are essential to myfuture's long-term success.

Proposed Technology Stack

The myfuture platform requires a stack that can handle multi-tenancy, personalisation, complex role-based access, real-time data integrations, and interactive tools — while remaining maintainable by ESA's internal team.

Front-end: Next.js (React)

• Server-side rendering for SEO and performance across all device types
• React component architecture enables the rich interactive tools myfuture requires (Career Bullseyes, My Career Profile, Virtual Work Exploration)
• Built-in API routes for serverless functions
• Incremental Static Regeneration for content-heavy pages (career stories, articles)
• App Router with nested layouts — ideal for dashboard-based experiences (educator, student, parent, jurisdiction, admin dashboards)
• Massive ecosystem reduces long-term hiring risk for ESA

CMS / Content Backend: Directus

• Open-source, self-hosted headless CMS
• REST and GraphQL APIs natively — supporting the API-first architecture requirement
• Flexible data modelling for complex content types (career profiles, occupation data, worksheets, courses)
• Role-based content workflows (draft → review → approve → publish)
• Newsletter management capabilities via extensions
• Content separated from application logic — editors work independently of developers
• Self-hosted in GovZone for complete data sovereignty

Application Backend: Node.js / Next.js API Routes

• Unified JavaScript/TypeScript stack across front-end and back-end (reduces ESA team's learning curve)
• Custom API layer for: user authentication and authorisation (SSO integration, MFA), dashboard data aggregation, career tool engines (My Career Profile matching, Career Bullseyes logic), external data integrations (labour market, course databases), invitation management and notification dispatch
• Microservices-ready: individual services can be extracted as scale demands

Authentication: NextAuth.js + Custom Auth Layer

• SSO integration (SAML/OIDC) for institutional login where available
• Username/password with MFA for direct accounts
• Role-based access control (RBAC) across 5+ user types
• Invitation-based registration flows
• Session management meeting ISM requirements

Database: PostgreSQL

• Multi-tenant data architecture with row-level security
• Supports the complex relationships required (users → schools → jurisdictions → classes → activities)
• Full-text search capabilities for site-wide search
• Proven at scale for education platforms

Search: Meilisearch (self-hosted)

• Site-wide search across all content, occupations, courses, resources
• Faceted search, filtering, typo tolerance
• Self-hosted within GovZone

Infrastructure

• Containerised deployment (Docker/Kubernetes) for GovZone SIT, UAT, PROD
• GitLab CI/CD pipelines
• Infrastructure as Code (Terraform/Pulumi)
• Redis for session management and caching
• Object storage for media assets (worksheets, documents)
• Automated backups with point-in-time recovery

Architecture Overview

┌──────────────────────────────────────────────────────────┐
│                     CDN / Edge Cache                      │
├──────────────────────────────────────────────────────────┤
│              Next.js Application (SSR/SSG)                │
│   ┌──────────┬──────────┬───────────┬──────────────┐     │
│   │ Public   │ Student  │ Educator  │ Admin        │     │
│   │ Pages    │ Dashboard│ Dashboard │ Dashboard    │     │
│   └──────────┴──────────┴───────────┴──────────────┘     │
├──────────────────────────────────────────────────────────┤
│                    API Layer (REST + GraphQL)              │
│   ┌──────────┬──────────┬───────────┬──────────────┐     │
│   │ Auth     │ Career   │ Content   │ Analytics    │     │
│   │ Service  │ Tools    │ API       │ Service      │     │
│   │ (SSO/MFA)│ Engine   │ (Directus)│              │     │
│   └──────────┴──────────┴───────────┴──────────────┘     │
├──────────┬───────────┬───────────┬───────────────────────┤
│PostgreSQL│  Redis    │ Search    │ External APIs          │
│(Multi-   │ (Cache/   │ (Meili-  │ (Labour market,        │
│ tenant)  │  Session) │  search)  │  courses, SSO)         │
├──────────┴───────────┴───────────┴───────────────────────┤
│              GovZone Infrastructure (Docker/K8s)          │
└──────────────────────────────────────────────────────────┘

Security and Compliance

ISM Classification 'OS'

• All data processed and stored within GovZone
• Encryption at rest (AES-256) and in transit (TLS 1.3)
• Multi-factor authentication for all user accounts
• Role-based access control across all application layers
• SSP Annexes and control documentation prepared and maintained throughout delivery
• Secrets management via GovZone-approved vault
• Regular penetration testing and vulnerability assessments

OWASP Top 10 and ASVS L1

• Automated SAST/DAST scanning in CI/CD pipeline
• Input validation, output encoding, CSRF/XSS protection
• Content Security Policy headers
• Rate limiting and brute-force protection on auth endpoints
• Dependency vulnerability monitoring (GitLab dependency scanning)

WCAG 2.1 AA

• Accessibility-first design system with semantic HTML, ARIA landmarks, keyboard navigation
• Automated testing (axe-core) in CI/CD
• Manual testing with assistive technologies
• Critical for myfuture's diverse user base including students of varying abilities

Privacy

• Australian Privacy Principles compliance
• Privacy-by-design throughout
• Data stored exclusively in Australia
• Secure account deletion workflows with audit logging
• Parental consent workflows for student accounts where required
• Cookie consent management

Multi-Tenancy Architecture

myfuture's tenancy model (jurisdictions → sectors → schools → classes) requires careful data architecture:

• PostgreSQL row-level security for tenant data isolation
• Configurable jurisdiction-specific settings (branding, content, features)
• Jurisdiction dashboard with aggregated analytics
• Bulk user management at school/jurisdiction level
• Tenant hierarchy: jurisdiction > sector > school > class > student

External Data Integrations

• Labour market data: API-driven integration for real-time occupation and industry data
• Course databases: Integration with course/qualification registries
• SSO providers: SAML/OIDC integration for institutional authentication
• Email service: Webhook-based integration for newsletters and notifications (componentised for easy provider swap)
• Ad/sponsorship: Configurable ad placement engine with geotargeting and user-type targeting

Career Tools Architecture

The interactive career tools are a defining feature of myfuture. Our approach:

My Career Profile

• User inputs (interests, strengths, values, achievements) stored in PostgreSQL
• Matching algorithm running server-side, returning personalised career/learning suggestions
• Results persisted with history for dashboard tracking
• Progressive profiling — builds over time as users add more data

Career Bullseyes

• Interactive front-end (React) linked to subject-career relationship data
• Data maintained via Directus CMS for easy updates
• Deep links to exploration tools for each career

Virtual Work Exploration (VWX)

• Modular architecture — can be built as an integrated module or integrate with best-of-breed external solution
• Work experience form builder using Directus data models
• Assessment engine with points/progress tracking
• Results surfaced on student dashboard

Worksheets (Explore + Build)

• Pre-built templates managed in Directus
• Build tool: drag-and-drop worksheet builder using platform resources as building blocks
• PDF export for offline use
• Curriculum alignment metadata

Scalability

• Static generation for public content pages (zero server load)
• Server-side rendering for personalised dashboard pages
• Redis caching for frequently accessed data (occupation data, course listings)
• Database read replicas for reporting/analytics queries
• Horizontal scaling of API containers as user load grows
• CDN for all static assets and media

Project Approach

Given myfuture's complexity and 14-month timeline, we use a phased agile approach with clear milestone gates aligned to ESA's indicative timeline.

Phase 1: Discovery & Requirements (Apr–May 2026) — 6 weeks

• Stakeholder workshops with product team, Technology team, business stakeholders
• Review existing myfuture platform, analytics, user research, and content
• Detailed requirements refinement
• Technical architecture design and review with ESA Technology team
• User persona validation and journey mapping
• Information architecture and navigation design
• GovZone environment setup and CI/CD pipeline configuration
• Co-development onboarding: tooling, coding standards, branch strategy
• Gate: Requirements sign-off

Phase 2: Design & Wireframes (May–Jul 2026) — 8 weeks

• Wireframes for all dashboard types, career tools, public pages
• Myfuture branding toolkit refresh
• Design system creation (component library with accessibility built in)
• User testing with career practitioners and students nationally
• Responsive design for all device types
• Gate: Design sign-off

Phase 3: Build (Jul 2026–Feb 2027) — 8 months

Build is structured in delivery streams running in parallel:

Phase 4: Testing & Training

• Full UAT cycle with key user groups
• User testing with students and career practitioners (coordinated with school terms)
• CMS training for content authors
• Accessibility audit and remediation
• Performance testing under realistic load
• Security testing and penetration test
• Gate: UAT sign-off

Phase 5: Launch

• Staged rollout strategy (consider pilot jurisdictions)
• Data migration cutover
• DNS and routing cutover
• Intensive monitoring period
• Rollback plan prepared and tested

Phase 6: Hypercare (Apr–May 2027) — 8 weeks

• Dedicated support for post-launch issues
• Performance monitoring and optimisation
• User feedback collection and prioritised fixes

Phase 7: Handover (Jun 2027) — 4 weeks

• Dedicated handover sprints: ESA team leads, Rocket Lab supports
• Final knowledge base review and completion
• Technology team training (architecture deep-dive, ops runbook)
• Gate: Handover sign-off

Philosophy

myfuture is a platform ESA will own and evolve for years. The co-development model must produce an ESA team that can independently maintain, enhance, and scale the platform after handover. We structure co-development as a progression:

Months 1–3: Observe & Learn

• ESA team members attend all ceremonies (standups, planning, retros)
• Paired code reviews — ESA team reviews all Rocket Lab merge requests
• Architecture walkthrough sessions (weekly)
• Workshops: Next.js fundamentals, Directus administration, TypeScript, Docker, CI/CD

Months 4–8: Contribute

• ESA developers assigned to specific features/modules
• Pair programming sessions on complex features
• ESA team writes tests and documentation
• Joint code reviews — ESA team submits merge requests reviewed by Rocket Lab
• ESA team manages selected Directus configurations

Months 9–12: Co-Lead

• ESA developers lead implementation of defined features with Rocket Lab support
• ESA team manages deployment pipeline
• Joint architecture decisions with ESA Technology team driving

Months 13–14: Own

• Handover sprints: ESA team leads all development
• Rocket Lab in advisory/support role
• ESA team handles incident response with Rocket Lab backup

Technical Standards (Enforced Jointly)

• Code standards: ESLint + Prettier + TypeScript strict mode, enforced via pre-commit hooks and CI
• Code review: All merge requests require at least one Rocket Lab and one ESA reviewer
• Testing: Minimum coverage targets; unit tests for business logic, integration tests for APIs, E2E tests for critical user journeys
• CI/CD: GitLab CI pipeline — lint → test → build → security scan → deploy
• Documentation: Architecture Decision Records (ADRs) for all significant choices

Governance

• Joint steering committee: Rocket Lab project lead + ESA Program Manager + Technology Development Team lead + Business team representative
• Shared tooling: Jira or Azure DevOps for sprint tracking; GitLab for code; Confluence/SharePoint for knowledge base
• Cadence: Sprint demos (fortnightly), steering committee (monthly), retrospectives (fortnightly)
• Accountability: Rocket Lab is responsible and accountable for all deliverables. ESA participation enhances the outcome but does not shift delivery accountability.

Knowledge Base Deliverables

All maintained in ESA's chosen platform (Confluence/SharePoint):

• Architecture diagrams (C4 model — context, container, component, code)
• Data model documentation
• API documentation (auto-generated + contextual)
• Deployment and operations runbook
• GovZone environment configuration guide
• CMS administration guide
• Troubleshooting guide with known issues
• ISM compliance documentation (SSP Annexes, control documentation)
• Security incident response procedures

Handover Checklist

• Source code transferred to ESA-owned GitLab (no proprietary packages without source access)
• All environments documented and ESA team can provision independently
• CI/CD pipeline fully owned by ESA team
• Deployment scripts and build pipeline scripts documented and tested by ESA
• Unit/integration test suites passing with documented coverage
• Knowledge base complete and reviewed by ESA team
• ESA team has independently completed at least one feature delivery
• Operations runbook tested via simulated incident
• ISM compliance documentation complete and reviewed

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 foundation: Next.js, Directus, and PostgreSQL eliminate licensing costs — no per-user, per-seat, or per-page charges at any scale
• Co-development reduces long-term cost: ESA's internal team can independently maintain and extend the platform after handover, eliminating expensive ongoing vendor dependency
• Cross-portfolio efficiency: Shared patterns, design system, and infrastructure from the edu.au build reduce discovery and setup costs for myfuture. If engaged for both, ESA benefits from consolidated onboarding and shared infrastructure
• Parallel build streams: Structured parallel delivery enables a 14-month timeline with high throughput — without inflating the team size unnecessarily
• Milestone-linked payment: All pricing is linked to delivered milestones, ensuring ESA pays only for outcomes
• Clear assumptions: Transparent assumptions table protects against hidden costs — ESA knows exactly what is and isn't included

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

Project 1

Project 2

Project 3

Project 4

Specific milestone dates subject to GovZone environment availability and school-term constraints for user testing windows. Dates will be confirmed at project kick-off.

Head of Engineering

Technical Lead / Solutions Architect

Senior Full-Stack Developer

Lead UX/UI Designer

Project Manager / Delivery Lead

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 user research, analytics, and content for discovery phase
• Detailed requirements will be refined during discovery — this pricing is based on the high-level requirements summary provided
• Content migration covers existing myfuture content and users; data quality issues discovered during migration may require additional effort
• External data source APIs (labour market, courses) are accessible and documented; significant integration complexity may affect scope
• VWX pricing assumes a built-in-house approach; if an off-the-shelf solution is preferred, pricing may be adjusted
• ESA team members are available for co-development activities as agreed at project kick-off
• User testing windows are coordinated with school terms and confirmed at least 4 weeks in advance
• Pricing is based on the indicative timeline; material changes to timeline may affect pricing

Ongoing Maintenance (Optional)