Full-Stack Developer for Physical Education Online Platform

ABOUT THE PROJECT We are building MyPEKit, an online platform currently under active development for UK initially and Worldwide Physical Education departments, teachers, students, and families. We have a substantial TypeScript codebase and several working features, but the current domain model does not yet fully reflect the product owner's vision as it needs to be totally flexible around a PE teachers, students and schools needs. We need a practical Full-Stack Developer to analyse the existing implementation, recommend the right direction, and help deliver curriculum, lesson-planning, assessment, timetable, and student-facing capabilities. The solution may involve incremental improvement, major refactoring, architectural redesign, or a rewrite where the evidence justifies it. CURRENT TECHNICAL STACK - Frontend: React, Next.js, TypeScript, Tailwind CSS, shadcn/Radix, and TanStack Table. - Backend: Next.js Server Actions, typed services and repositories, and Zod validation. - Database: PostgreSQL with Drizzle ORM. - Architecture: NX monorepo with multiple dashboards. - Infrastructure: Bun, Docker, Kubernetes, AWS Cognito, S3, and SES. - Caching: Redis. - Testing: Jest, Playwright, Storybook, ESLint, and TypeScript checks. - Integrations: Wonde school data and account provisioning. Exact experience with every technology is not required. Strong React, TypeScript, backend, and relational database experience is essential. CURRENT PROBLEMS Much of the curriculum domain is too rigid and centred around the Scheme of Work (SoW). Lessons, activities, assessments, skills, tactics, quizzes, and delivery are often structurally dependent on it. This is one dimensional and fixed. By the existing system being fixed and linear it needs to eb focused on the teacher, students, facilities and school needs alongside being totally flexible so that a range of delivery approaches by the PE teacher throughout the world can be easily used in a range of physical education settings. these could be via sports, themes, frameworks, drills, games based learning, concept learning, skill specific learning, and teaching approaches using our resources or their own resources. The fixed platform needs to be moveable, rotational, editable and not one dimensional. - Sports, themes, teaching frameworks, skills and tactics are not represented consistently as a canonical domain. - Curriculum components are difficult to reuse across Sports, frameworks, themes and SoWs. - Schools need to copy, customise, combine, or import their own content across different years, Key Stages, countries, exam boards, and frameworks. - Assessment needs configurable frameworks, school-specific criteria, and continuous evidence. these need to be adaptable and changeable once a curriculum changes, an exam board changes the exam syllabus, or the assessment objective is amended, changed or edited. Or simply an update in the national curriculum of the specific country changes. - Deep joins and enrichment chains create performance and maintainability problems. - Existing student features need to become a more coherent learning and progress experience. WHAT WE WANT TO BUILD The target direction includes: - Canonical Sport Categories and Sports, including school-owned content. - Reusable Topics, Sports, Themes, Frameworks, Skills, Activities, Tactics, Themes, Lessons, Assessments, and Quizzes. - Versioned, time-bound SoWs, plans, resources and lessons that compose content and may contain multiple Sports. - Permission-based editing, approval, publishing, and teacher adaptation. - Student experiences for approved lessons, actions, feedback, progress, evidence, and next steps. - A data architecture that balances integrity, flexibility, and efficient reads. - Safe migration or staged replacement that protects existing data and validated functionality. - Student and parent access to see learning, progress and extra curricular aspects. WHAT YOU WILL DO - Review the requirements and map them against the existing monorepo and database. - Identify root product, domain, security, data, and performance gaps. - Recommend and explain the most practical technical approach. - Implement frontend, backend, and PostgreSQL changes. - Build accessible React and Next.js workflows. - Deliver safe migrations, backfills, permissions, and tenant isolation. - Improve slow queries, N+1 patterns, and unnecessary service or Redis calls. - Add focused tests and document important decisions and migration steps. ENGINEERING EXPECTATIONS We expect clean, readable, maintainable, production-quality code, including: - Clear architecture, package boundaries, and minimal unnecessary abstraction. - Secure multi-tenant access, least privilege, idempotency, and transaction safety. - Tested migrations, backfills, rollback plans, and regression protection. - Database performance, structured logging, and production verification. - Accessibility, internationalisation, code review, and technical documentation. VERY USEFUL EXPERIENCE Experience with curriculum, EdTech, learning-management, assessment, timetable, or student-facing platforms would be a significant advantage. Familiarity with school workflows, safeguarding, privacy, SEND, differentiation, or UK education is useful but not required. Strong domain discovery skills matter more than knowing every education term. You should be comfortable working directly with the product owner to understand and challenge the intended model. WE WELCOME ALTERNATIVE APPROACHES We have an initial architecture and migration direction, but we want it evaluated rather than followed blindly. We welcome a better, simpler, safer, or more scalable approach supported by clear reasoning. ATTACHED REFERENCE MATERIALS Two product requirement documents are attached as initial references. The selected developer should compare them with the codebase, identify gaps or contradictions, clarify uncertainties, and recommend a practical approach. They are starting points for analysis, not instructions to implement without evaluation.