Senior Full-Stack / Unity Engineer for Reusable Curriculum & Multilingual Content Architecture

Senior Full-Stack / Backend + Unity Engineer – EdTech Curriculum Architecture Long-Term Opportunity: Curriculum Architecture, Unity Integration, Multilingual System, Website & App Development About STEMinnoKey STEMinnoKey is an EdTech platform for mathematics and STEM learning. Website: https://steminnokey.com/ Our platform includes interactive mathematics learning content developed in Unity, including: Virtual Manipulatives Multiple-Choice Questions (MCQs) Interactive Games Curriculum-based learning activities We are expanding STEMinnoKey internationally and need to redesign our curriculum and multilingual content architecture so that the same educational content can be efficiently reused across different countries, curricula, and languages. This is not simply a new website project or a Unity game-development project. We are looking for a senior engineer who can understand our existing website, backend, database structure, curriculum system, and Unity application, design a scalable architecture, integrate it into the current system, and potentially continue working with us on the maintenance and expansion of the entire STEMinnoKey platform. IMPORTANT: Please Test STEMinnoKey Before Applying Before submitting your proposal, please visit: https://steminnokey.com/ Please explore the website and test the STEMinnoKey application yourself. We want applicants to understand: What STEMinnoKey is How our learning content works How Unity-based activities are presented How the curriculum is currently experienced by users What type of educational content the new architecture must manage Please do not submit a generic proposal without reviewing the actual product. In your application, tell us briefly what part of STEMinnoKey you tested or reviewed. 1. Current Curriculum Structure Our current main curriculum is called the: Global Core Curriculum It consists of seven levels: Kindergarten 1 Kindergarten 2 Grade 1 Grade 2 Grade 3 Grade 4 Grade 5 Each grade contains approximately 25 chapters. Each chapter has a fixed structure of five units: Virtual Manipulative × 1 MCQ × 2 Game × 2 The interactive educational content has already been developed in Unity. The five-unit structure of a chapter will remain fixed. 2. Problem With the Current Architecture Currently, when we create a new curriculum, the required units are copied into that new curriculum. For example, if the same learning activity is required in several curricula, separate copies may be created. As we add: More countries More curricula More grades More languages the number of duplicated units increases. This is inefficient and makes future maintenance, updating, translation, and international expansion more difficult. We want to replace this architecture. 3. Core Architectural Principle The new system should be based on: Reuse by Reference — Not Duplication A piece of educational content should normally exist only once. Multiple chapters or curricula should be able to reference and use that same content through stable IDs. For example, if one Grade 2 chapter is used in: UK Curriculum India Curriculum Estonia Curriculum South Africa Curriculum we do not want four separate copies of its Unity content. Instead, all four curricula should be able to reference the same existing chapter/content package. The engineer must understand and implement a reusable, relational content architecture rather than a clone-and-modify system. 4. Chapter-Based Curriculum Management Previously, curriculum creation was largely unit-based. We now want curriculum management to become chapter-based. Each chapter will always contain the same five content slots: Chapter Structure Slot 1 Virtual Manipulative Slot 2 MCQ 1 Slot 3 MCQ 2 Slot 4 Game 1 Slot 5 Game 2 Administrators should create or modify curricula primarily by selecting, arranging, replacing, or reusing chapters, rather than manually copying individual units. The relationship should conceptually be: Curriculum → Grade → Chapter → Unit Slots → Existing Content IDs The actual implementation should be proposed after reviewing our current code and database. 5. Global Core Curriculum as the Base The Global Core Curriculum should serve as the main reusable curriculum source. When we create a curriculum for another country, most chapters should normally reference existing Global Core Curriculum chapters. For example: Global Core Curriculum – Grade 3 Chapter 1 Chapter 2 Chapter 3 ... Chapter 25 A national curriculum could initially reference these same chapters without duplicating them. 6. Country-Specific Chapter Replacement Different countries sometimes require different educational content. Typical examples include: Currency Measurement units Country-specific terminology National curriculum requirements We therefore need the ability to replace only selected chapters. Example: A general money chapter may exist in the Global Core Curriculum. For the UK curriculum, that chapter could be replaced by: Pounds and Pence For the US curriculum, the same chapter position could instead use: Dollars and Cents Most other chapters would continue to reference the Global Core Curriculum. Therefore, the system should support: Global Core Curriculum + Selected Country-Specific Chapter Overrides We do not want to duplicate an entire curriculum simply because one or two chapters are different. 7. Reusable Chapter and Content Architecture The system should allow: One chapter to be used in multiple curricula One Unity activity to be referenced by multiple chapters where appropriate Existing content to be reused without duplication Chapters to have stable IDs Units/content to have stable IDs National curricula to reference Global Core chapters Individual chapters to be replaced when required Changes to mappings without unnecessarily copying underlying content Versioning and update behavior must also be considered. The engineer should recommend how changes to shared content should affect curricula that reference that content. 8. Multilingual Architecture STEMinnoKey will support multiple countries and languages. We do not want to duplicate an entire activity for every language. The underlying educational content should remain shared where possible. This may include: Mathematical structure Correct answers Images Interactive logic Unity activity Game logic Content relationships Language-specific text should be managed separately. Examples include: Questions Instructions Labels Explanations Feedback Other learner-facing text Conceptually: Shared Content ID → English text → Korean text → French text → Arabic text → Estonian text → Georgian text → Urdu text → Additional languages later The architecture must allow additional languages to be added without duplicating the underlying Unity content. 9. Translation Status and Future AI Translation We are also planning an AI-assisted translation system. The initial architecture should therefore prepare for translation states such as: Source AI Generated Under Review Human Reviewed Approved Published Revision Required Automatic translation itself may be developed as a later phase, but the data architecture created now must support it correctly. We do not want to redesign the database again when automatic translation is introduced. 10. Stable Identifiers Stable identifiers are essential. The system may need identifiers for: Curriculum Curriculum version Country Grade Chapter Unit slot Unity content Question Text item Language Translation Content version The selected engineer should review the identifiers already used by STEMinnoKey before proposing a final ID strategy. Existing IDs should be preserved where practical to avoid breaking the current application. 11. Unity Integration Our educational application and learning content are built with Unity / C#. The new curriculum architecture must therefore work with the existing Unity application. The engineer must determine how Unity will: Identify a curriculum Identify the correct grade Load the correct chapter Identify its five unit slots Load the corresponding VM, MCQs, and Games Retrieve the correct language Load localized questions and instructions Handle country-specific chapter replacements Detect missing or invalid content Remain compatible with existing content where possible We are specifically interested in engineers who understand both backend architecture and Unity integration. A developer who only knows Unity UI or game development is not sufficient for this role. 12. Existing System Audit Before making major architectural changes, the selected engineer must first review the existing system. This should include, where applicable: Existing Unity project Existing C# structure Current backend Current database Current APIs Current curriculum data Existing content IDs Current unit/chapter relationships Existing Excel data Current import procedures Current multilingual support Existing GitLab repository and development workflow We do not want an engineer to replace working systems unnecessarily. The new architecture should be designed after understanding what can be reused. 13. Curriculum Management / Admin Function Ultimately, STEMinnoKey administrators should be able to manage curricula efficiently. The system should support functions such as: Create a curriculum Select a grade Select existing chapters Arrange chapters in curriculum order Reuse a Global Core chapter Replace a chapter with a country-specific version View which curricula use a chapter Prevent unnecessary duplication Validate curriculum structure Add future curricula without redevelopment The objective is to make international curriculum creation significantly faster and easier. 14. Excel / CSV Import and Export We currently use Excel as part of curriculum and translation preparation. The new system should support practical Excel or CSV import/export where useful. Potential uses include: Curriculum chapter mapping Translation import Translation export Bulk data updates Content review Curriculum preparation However, we do not want uncontrolled Excel duplication to become the permanent architecture. The engineer should recommend an appropriate relationship between: Database Admin interface Excel/CSV import Export Unity 15. Validation and Error Prevention The new system should include validation before curriculum or translation data is published. Examples include: Missing Chapter ID Missing Unit ID Missing Unity content Duplicate IDs Broken references Invalid chapter mapping Incorrect number of units Missing required content Invalid language codes Missing source language Missing translation Invalid curriculum order Unsupported country/language combinations A dry-run or validation process before applying bulk changes would be desirable. 16. Migration of Existing Content We already have curriculum and Unity content in use. The selected engineer must provide a safe migration strategy. The goal is to move from the current duplicated/unit-based system to the new reusable chapter/content architecture without breaking existing application functionality. Migration should consider: Existing curriculum records Existing Unity content Existing users Existing content IDs Duplicate units Existing translations Existing API dependencies Backward compatibility Rollback or recovery if necessary We prefer incremental migration rather than unnecessary redevelopment of the entire system. 17. GitLab Integration Our development code is managed through GitLab. Approved development must ultimately be integrated into the existing STEMinnoKey GitLab environment. We expect professional source-control practices, including: Clear commits Appropriate branches Documented changes No uncontrolled replacement of production code Testing before merge Handover of source code Technical documentation The final system must not depend solely on code stored on the freelancer's personal computer or private repository. 18. Initial Project Milestones We will begin with two small paid milestones. This is intentional. We want to evaluate: Technical understanding Architecture quality Coding ability Communication Reliability Knowledge of Unity Knowledge of backend systems Ability to work with an existing product before entering into a larger long-term contract. Milestone 1 — Working Prototype Budget: USD 100 The selected engineer will: Review the relevant current architecture. Confirm understanding of the existing curriculum and Unity content structure. Propose the new reusable curriculum architecture. Build a working prototype demonstrating the core concept. The prototype should demonstrate, at minimum: Chapter-based curriculum composition Fixed five-unit chapter structure Reuse by reference rather than duplication Global Core Curriculum structure Country-specific chapter replacement Stable content relationships Basic multilingual/localization architecture Compatibility concept with existing Unity content The prototype does not need to redesign the entire application. Its purpose is to prove that the architecture is practical before integration into the actual system. 19. Milestone 2 — GitLab Integration and Usable Implementation Budget: USD 100 After Milestone 1 is reviewed and approved, the selected solution should be integrated into the actual STEMinnoKey development environment. Milestone 2 includes: Implementation in the existing codebase GitLab integration Connection with actual curriculum data Connection with existing Unity content Backend integration Required API changes Curriculum mapping Basic localization integration Import and validation where required Test-environment implementation Bug correction Technical documentation Source-code handover The result must be actually usable in the STEMinnoKey development/test environment, rather than only a standalone demonstration. Milestone 2 will be considered successful when the approved prototype architecture has been implemented through GitLab and can be tested with actual STEMinnoKey curriculum and Unity content. 20. Long-Term Contract After the Initial Milestones If the first two milestones are completed successfully, our intention is to continue working with the selected engineer under a long-term development and maintenance arrangement. This is therefore an opportunity for ongoing work rather than only a USD 200 one-time project. Future responsibilities may include the following. Curriculum Expansion Create additional national curricula Improve curriculum composition tools Expand chapter-sharing functions Develop country override systems Improve curriculum versioning Develop curriculum review and publishing workflows Multilingual Expansion Add additional languages Develop automatic translation Integrate AI translation services Develop translation review workflows Improve localization administration Support right-to-left languages where required Unity Application Maintain the existing Unity application Integrate new backend functions Maintain content-loading systems Resolve bugs Improve performance Add new application functions Maintain compatibility with new curriculum structures Support future Unity content development Backend Maintain and expand APIs Improve database architecture Develop administrator functions Improve security Improve data validation Improve performance and scalability Support international expansion Website Maintain the STEMinnoKey website Add and improve website functions Connect website forms and management systems Improve account functions Develop new management sections Maintain integrations with the application and backend Resolve bugs and technical issues UI / UX UI improvement is not the first priority of this project, but future work may include: Website UI improvements Application UI improvements Admin interface improvements Responsive design User workflow improvements Platform Expansion Future work may also include: Pilot School management Partner management Academic Advisor management Collaborator functions School administration Reporting Analytics New educational functions International deployment We want an engineer who can gradually become familiar with the entire STEMinnoKey ecosystem and help us maintain and expand both the website and application. 21. Required Technical Skills Strong experience is required in several of the following areas: Senior Full-Stack Development Backend Architecture Database Architecture Unity C# REST API development JSON Relational database design PostgreSQL, MySQL, or similar databases Data modeling Data migration Reusable/reference-based content architecture Content Management Systems Localization / Internationalization (i18n) Stable ID systems Versioning Excel / CSV import and export Git GitLab Existing-codebase maintenance 22. Preferred Experience Experience in any of the following will be particularly valuable: EdTech Learning Management Systems Curriculum Management Systems Content Management Systems Digital publishing Multilingual platforms Localization systems Reusable learning objects Unity educational applications Unity/backend integrations International SaaS platforms AI-assisted translation systems 23. The Engineer We Are Looking For We are looking for someone who can think beyond individual programming tasks. The right engineer should be able to: Understand an existing system before changing it Design clean data relationships Identify unnecessary duplication Build reusable architecture Work with both backend and Unity Consider future scalability Protect existing working functionality Document technical decisions Communicate clearly Work independently Maintain code over the long term We value architecture and maintainability more than quick temporary fixes. 24. What We Are NOT Looking For Please do not apply if your proposed solution is simply: Clone Curriculum → Copy Units → Modify Copies That is the architecture we are trying to replace. We need: Shared Content → Stable IDs → Chapter References → Curriculum Mapping → Country Overrides → Localization We are also not looking only for: A website designer A front-end-only developer A Unity UI designer A game artist A developer who cannot work with an existing backend A developer who cannot understand database/content architecture 25. Questions You Must Answer When Applying Please answer the following questions in your proposal. 1. Product Review Visit: https://steminnokey.com/ What part of the STEMinnoKey website or application did you review or test? Please mention something specific enough to show that you actually reviewed the product. 2. Reusable Content Architecture How would you allow several curricula to use the same chapter or Unity learning content without creating duplicate copies? 3. Chapter Architecture Each chapter always has: 1 Virtual Manipulative 2 MCQs 2 Games How would you model this relationship? 4. Country Curriculum How would you use the Global Core Curriculum as a base while allowing an individual country to replace only selected chapters? 5. Localization How would you separate shared educational/Unity content from translated questions, instructions, and other language-specific text? 6. Unity Integration How should Unity identify and load: Curriculum Chapter Unit Content Country-specific replacement Language-specific text without duplicating the underlying content? 7. Migration How would you migrate an existing system containing duplicated curriculum units into a reference-based architecture while minimizing the risk of breaking the current application? 8. Similar Work Have you previously developed any of the following? CMS LMS Curriculum management system Multilingual system Localization architecture Reusable content platform Unity/backend integration Please provide relevant examples. 9. GitLab Are you comfortable reviewing and integrating your work into an existing GitLab-managed production codebase? 10. Long-Term Availability If the initial two milestones are successful, are you interested in continuing with STEMinnoKey for long-term maintenance and expansion of the website, backend, and Unity application? 26. Proposal Screening Generic proposals are unlikely to be considered. We will give preference to applicants who: Actually test STEMinnoKey before applying Clearly understand the duplication problem Explain a reference-based architecture Understand database relationships Understand Unity/backend integration Understand localization Can explain migration risk Are interested in long-term development Please keep your initial proposal focused on the technical approach and relevant experience. Project Structure Milestone 1 — USD 100 Working architecture prototype Milestone 2 — USD 100 Integration into GitLab and implementation in the actual STEMinnoKey test/development environment After Successful Completion Long-term contract for continued curriculum development, multilingual expansion, website maintenance, backend development, Unity application maintenance, and future platform expansion. We are looking for a capable engineer who can begin with this curriculum architecture project and potentially become a long-term technical contributor to STEMinnoKey.