WordPress Plugin Developer Needed for AI-Powered Personalised Learning Platform Using Tutor LMS Pro

Project overview We are seeking an experienced senior WordPress plugin developer, or a small specialist development team, to build a bespoke personalised learning platform for an established chemical engineering education website. The website currently runs on WordPress and uses Tutor LMS Pro to deliver online courses. We have a substantial existing bank of approximately 1,000 lessons, quizzes, worked examples, simulations and supporting learning materials. The goal of this project is to develop a custom WordPress plugin that can use this existing content bank to generate personalised learning pathways for individual students. Students will provide information about: * Their university level or academic year * Their current modules * Their university and module names * Their assessment type * Their examination or coursework dates * The topics included in their syllabus * The areas they find difficult * Their available study time * Their target result * Their current level of understanding * An optional uploaded module descriptor or syllabus The system will then identify, select and sequence the most relevant content from our existing lesson bank and present it to the student as a personalised course and study plan. The student should then be able to purchase the personalised pathway outright or access it through an adaptive monthly or term-based subscription. A detailed WordPress Plugin Developer Specification has already been prepared and will be shared with shortlisted candidates. ⸻ Core project objective The plugin should transform our existing fixed course catalogue into a personalised learning system. Rather than requiring every student to purchase a complete course covering several academic years, the plugin should identify the specific lessons, topics, quizzes, simulations and practice resources that are relevant to the student’s current needs. For example, a second-year student preparing for examinations in Mass Balances, Heat Transfer and Distillation may receive a personalised pathway containing: * Relevant prerequisite lessons * Core topic lessons * Worked examples * Diagnostic quizzes * Practice questions * Relevant simulations * A structured weekly study schedule * Revision milestones * Automated reminders The final student experience should feel like one coherent personalised course, even where the content is assembled from reusable lessons or hidden learning blocks behind the scenes. ⸻ Existing website and technology The current platform uses: * WordPress * Tutor LMS Pro * Tutor LMS Native eCommerce and payment gateway * Tutor LMS subscriptions * Elementor * A commercial WordPress theme * Brevo for email marketing and automated communications * Existing custom engineering simulations * A large bank of existing Tutor LMS lessons and course content The plugin must be developed as an independent custom WordPress plugin. Core Tutor LMS files, theme files and third-party plugin files must not be modified. The solution should remain maintainable when Tutor LMS, WordPress, Elementor or the active theme are updated. ⸻ Required plugin functionality 1. Student intake and needs-assessment system The plugin should provide a multi-step questionnaire or conversational interface that collects the information needed to build a personalised learning pathway. The form should support: * Academic level or year * University * Degree programme * Module names and module codes * Subjects and topics being studied * Assessment type * Assessment dates * Areas of difficulty * Target grade or objective * Available study hours per week * Existing knowledge * Preferred learning pace * Optional syllabus or module descriptor upload * Optional free-text explanation of the student’s needs The questionnaire must be responsive, accessible and save progress where appropriate. ⸻ 2. Content taxonomy and metadata system The developer will need to create an administration system through which our existing lessons and learning resources can be classified. Each lesson or reusable learning block may require metadata such as: * Subject * Topic * Subtopic * Academic level * Difficulty * Learning outcomes * Prerequisites * Estimated study time * Assessment relevance * Resource type * Required, recommended or optional status * Associated quiz * Associated simulation * Associated worked example * Relevant university terminology * Suitable assessment types * Content version and review status The plugin must make this content searchable and usable by the recommendation engine. Bulk editing, filtering, importing and exporting metadata will be important because the platform contains a large volume of content. ⸻ 3. Personalised curriculum recommendation engine The plugin should analyse the student’s submitted information and identify the most appropriate content. The recommendation engine should: * Match student needs against the lesson bank * Select relevant lessons or learning blocks * Avoid duplicate content * Detect missing prerequisite knowledge * Add foundation content where required * Exclude irrelevant or excessively advanced material * Sequence content in a sensible learning order * Divide content into modules or milestones * Classify content as essential, recommended or optional * Calculate estimated completion time * Apply maximum content or credit limits * Produce a clear explanation of why content was selected The final result should not appear to be a random playlist. It must feel like a deliberately structured course. ⸻ 4. Diagnostic quiz system The plugin should support initial and ongoing diagnostic assessments. The system should be capable of: * Selecting questions from topic-specific question banks * Generating a diagnostic quiz based on the selected modules * Calculating proficiency by topic * Identifying knowledge gaps * Recommending prerequisite or remedial content * Triggering new recommendations based on quiz performance * Generating progress checks during the learning pathway * Supporting question randomisation * Supporting parameterised numerical questions where practical AI-generated numerical questions should not be trusted without validation. Deterministic question banks and approved templates should be used for formal assessment logic. ⸻ 5. Personalised course or pathway creation The plugin must create a personalised student-facing learning experience. We are open to the developer recommending the best supported architecture, but the preferred approach is to avoid duplicating every lesson into a completely new Tutor LMS course for every student. The anticipated architecture is: * One master content bank * Reusable hidden lessons, content blocks or micro-courses * A student-specific pathway record * A custom dashboard presenting the selected content as one coherent course * Tutor LMS used for content delivery, progress, quizzes and enrolment The developer should explain whether they recommend: * Hidden reusable Tutor LMS micro-courses * A virtual pathway that references canonical lessons * A hybrid architecture * Another maintainable approach The system must preserve a single authoritative version of each learning resource wherever possible. ⸻ 6. Personalised study-plan generator The selected curriculum should be converted into an actionable study plan. The scheduling engine should use: * Assessment dates * Lesson duration * Quiz duration * Estimated practice time * Available study days * Weekly study hours * Topic priority * Prerequisite order * Revision requirements The plugin should automatically generate: * A weekly study plan * Daily or session-based tasks * Topic milestones * Quiz dates * Revision blocks * Practice examination dates * Final review periods * Deadline countdowns The study plan should be visible within the student dashboard and should also be exportable or downloadable. Potential outputs may include: * Printable PDF study plan * Calendar export * Weekly email summary * Dashboard checklist * Progress timeline If a student misses planned work or changes an assessment date, the system should be capable of recalculating the remaining plan. ⸻ 7. One-time purchase pathway Students should be able to purchase a fixed personalised pathway outright. The one-time product may include: * A fixed selected curriculum * A fixed study plan * Initial diagnostic assessment * Relevant quizzes and practice resources * Relevant simulations where included * Automated reminders * Access for a configurable period The plugin should assign the pathway to an appropriate predefined pricing tier based on factors such as: * Total study hours * Number of active modules * Number and type of resources * Included simulations * Overall pathway size We prefer predetermined pricing bands rather than creating an unpredictable unique price for every individual lesson combination. ⸻ 8. Adaptive subscription pathway The system should also support an ongoing subscription product. Subscribers may receive: * Monthly or termly plan recalculation * New assessment-date planning * Controlled module replacement * Updated study schedules * Progress-based recommendations * Additional diagnostic quizzes * Revision reminders * Simulations * AI-assisted learning support * Access to monthly live classes * Question submission * Automated learning reports The subscription must provide ongoing automated value without requiring constant manual intervention or the regular creation of new video content. The developer should implement configurable limits such as: * Maximum number of active modules * Maximum active lesson credits * Number of pathway rebuilds allowed * Module replacement frequency * Content transition period after a module is removed * Subscription cancellation and expiry rules ⸻ 9. Automated plan adjustment At configurable intervals, subscribers should be invited to update their learning requirements. The plugin may ask: * Are you still studying the same modules? * Have your assessment dates changed? * Which topics are now causing difficulty? * How much time can you study this month? * Have you completed or dropped any modules? * Have new assignments or examinations been announced? The system should then: * Recalculate priorities * Reorder lessons * Add or remove learning blocks * Update the study schedule * Recalculate revision dates * Preserve relevant progress * Warn the student before content access is removed This process should be self-service and largely automated. ⸻ 10. Progress-based recommendation engine Tutor LMS activity and quiz data should be used to adjust the student pathway. Examples include: * High quiz scores may allow foundation content to become optional * Moderate scores may trigger additional review * Low scores may add prerequisite lessons * Repeated failed attempts may trigger a different worked example * Inactivity may trigger a simplified recovery plan * Completed modules may be replaced with upcoming modules * Missed deadlines may trigger automatic rescheduling The system should retain a clear audit trail explaining why recommendations changed. ⸻ 11. Tutor LMS integration The plugin must integrate reliably with Tutor LMS Pro. Expected integration areas include: * Courses * Lessons * Topics * Quizzes * Enrolments * Student progress * Quiz results * Course access * Completion status * Student dashboard * Native payments * Orders * Subscriptions * Refunds * Cancellations * Expiry * Renewals The developer must use documented APIs, hooks and extension points wherever possible. Any dependency on undocumented Tutor LMS internal functions must be clearly identified before development. ⸻ 12. Tutor LMS Native eCommerce integration We want to retain Tutor LMS Native Payment and Native eCommerce if technically viable. The preferred payment flow is: 1. The student completes the questionnaire. 2. The system generates a recommended pathway. 3. The pathway is assigned to a predefined pricing tier. 4. The student chooses one-time purchase or subscription. 5. Tutor LMS Native checkout processes the payment. 6. Successful payment activates the personalised pathway. 7. Cancellation, failed renewal, expiry or refund changes access automatically. The plugin should not grant paid access until payment status has been confirmed. The developer should explain the safest method for linking a unique student pathway to a standard Tutor LMS payment product or subscription plan. ⸻ 13. AI-agent integration The plugin may connect to an external AI agent or language model. The AI layer should assist with: * Reading uploaded module descriptors * Extracting module topics * Interpreting different university terminology * Understanding free-text student requests * Mapping syllabus language to internal content tags * Asking relevant follow-up questions * Ranking candidate content * Explaining recommendations * Providing controlled learning support * Summarising student progress The AI must not independently control: * Payments * Prices * Refunds * Access permissions * Subscription status * WordPress administration * Final prerequisite rules * Final entitlement decisions The WordPress plugin must remain the deterministic operational layer. The AI should return structured data, such as approved content IDs, confidence scores and explanations. The plugin must validate this output before it affects the student pathway. The system should also support fallback rules when the AI service is unavailable. ⸻ 14. Student dashboard The student should see one clear personalised learning area. The dashboard should display: * Personalised course title * Current modules * Assessment dates * Overall progress * Weekly study plan * Next recommended task * Essential lessons * Recommended lessons * Optional lessons * Upcoming quizzes * Revision tasks * Relevant simulations * Performance by topic * Subscription status * Module replacement allowance * Plan rebuild allowance * Live class information * Notifications * Downloadable study plan * Calendar export The dashboard should not expose confusing backend course structures or multiple hidden micro-courses. ⸻ 15. Administrator dashboard Administrators should be able to: * Review all generated pathways * Search by student * View selected lessons and modules * See why content was recommended * Manually add or remove content * Reorder content * Override prerequisite decisions * Rebuild a pathway * Pause or reactivate access * Review AI output * View diagnostic results * Edit pricing bands * Configure pathway limits * Configure module replacement rules * Configure subscription allowances * View scheduled jobs * View failed processes * Re-run failed background jobs * Export pathway and analytics data * Review content usage * Identify commonly requested topics All significant administrative changes should be logged. ⸻ 16. Notifications and Brevo integration The plugin should support automated communications through WordPress and/or Brevo. Notification triggers may include: * Pathway created * Payment confirmed * Weekly plan ready * Lesson overdue * Quiz due * Quiz failed * New recommendation available * Assessment approaching * Study plan recalculated * Module replacement available * Module replacement completed * Subscription renewal failed * Subscription expiring * Student inactive * Monthly live class approaching Messages should include relevant dynamic information, such as the student’s module, assessment date and next task. ⸻ 17. Simulations and practice activities The plugin should recommend existing engineering simulations based on the student’s selected modules. Examples include: * Distillation simulator * Heat exchanger simulator * Batch reactor simulator The system should control which simulations are available based on: * Pathway content * Product tier * Subscription status * Progress * Module selection The plugin should also support reusable simulation challenges and practice tasks. ⸻ 18. Live classes Subscribers may receive access to a monthly live group class or office hour. The plugin should support: * Displaying upcoming class details * Restricting access by product or subscription * Accepting student question submissions * Sending reminders * Displaying meeting links * Providing access to recordings * Tagging recordings by topic * Recommending recordings to relevant students This feature should be scalable and should not create an expectation of unlimited one-to-one tutoring. ⸻ 19. Reporting and analytics The plugin should track the full student journey. Required analytics may include: * Questionnaire started * Questionnaire completed * File uploaded * Diagnostic started * Diagnostic completed * Pathway generated * Recommendation viewed * Recommendation edited * Checkout started * Purchase completed * Subscription started * Pathway activated * Lesson completed * Quiz completed * Study task missed * Plan recalculated * Module replaced * Subscription cancelled * Pathway completed Administrative reporting should help identify: * Most requested modules * Most requested topics * Common prerequisite gaps * Common university terminology * Most frequently recommended content * Conversion by pathway size * Conversion by academic level * One-time versus subscription conversion * Subscriber engagement * Module replacement behaviour * Cancellation behaviour * Completion rates * Underused content ⸻ Technical requirements The plugin must: * Follow WordPress coding standards * Use object-oriented and modular architecture * Use namespaced PHP classes * Use secure custom REST endpoints where needed * Use WordPress roles and capabilities correctly * Use nonces, sanitisation, escaping and permission checks * Be compatible with modern supported PHP versions * Be responsive * Be accessible * Be translation-ready * Use background jobs for slow operations * Avoid long-running synchronous requests * Support retry and failure logging * Avoid unnecessary duplication of Tutor LMS content * Be suitable for staging and production environments * Include migration and rollback procedures * Include structured logging * Include an audit trail * Include developer documentation * Include administrator documentation The developer must not modify WordPress core, Tutor LMS core, the active theme or third-party plugin files. ⸻ Performance and scalability The platform may contain approximately 1,000 learning resources and potentially thousands of student pathways. The developer should explain: * How pathways will be stored * How content relationships will be indexed * How large metadata searches will be handled * How AI requests will be queued * How background jobs will be processed * How abandoned draft pathways will be cleaned * How duplicate content will be avoided * How the system will behave at higher user volumes * What hosting requirements may be necessary * What caching should and should not be used ⸻ Security and privacy The plugin may process student profile data, uploaded academic documents and learning-performance information. The solution should include: * Secure file uploads * File type and size restrictions * Malware scanning where possible * Private file storage * Access controls * GDPR-conscious data retention * Data export * Data deletion * Consent handling * Clear AI data-processing boundaries * Protection against prompt injection * Protection against unauthorised content access * Protection against price or entitlement manipulation * Rate limiting for public endpoints * Administrative audit logs Uploaded documents must be treated as untrusted input. ⸻ Expected project phases We expect the project to be delivered in phases. Phase 1: Paid technical discovery This should include: * Review of the complete developer specification * Review of the current WordPress and Tutor LMS setup * Review of the existing lesson structure * Tutor LMS integration feasibility assessment * Recommended technical architecture * Proposed data model * AI integration approach * Payment and subscription workflow * Risks and limitations * Proof-of-concept scope * Delivery roadmap * Final quotation Phase 2: Proof of concept The proof of concept may initially cover: * Three subject areas * A limited number of classified lessons * Student intake form * Basic diagnostic * Rules-based content selection * Pathway generation * Basic study-plan generation * Test checkout * Basic student dashboard Phase 3: Minimum viable product This may include: * Full content metadata system * Curriculum engine * Prerequisite engine * Scheduling engine * Pricing tiers * Tutor LMS payment integration * Student dashboard * Administrator dashboard * Notifications * Subscription rules * Module replacement * Initial AI integration Phase 4: Adaptive learning and advanced automation This may include: * Progress-based recommendations * Automated monthly recalculation * Syllabus interpretation * Advanced AI-agent integration * Parameterised practice questions * Enhanced analytics * Live class workflows * Further performance optimisation ⸻ Required developer experience Please apply only if you have strong experience in several of the following areas: * Advanced custom WordPress plugin development * Tutor LMS Pro development or deep LMS integration experience * WordPress REST API * Custom database tables * Complex user dashboards * Subscription and entitlement systems * Payment lifecycle handling * Background job processing * AI or large-language-model API integration * Structured AI outputs * Retrieval systems * Learning management systems * Rules engines * Quiz and assessment systems * Secure file uploads * Brevo integration * Performance optimisation * GDPR and secure WordPress development This is not primarily an Elementor design project. We are not looking for someone who only installs and configures existing plugins. We require a developer capable of designing and building a maintainable software product within WordPress. ⸻ What to include in your proposal Please address each of the following points. 1. Describe your experience developing complex custom WordPress plugins. 2. Describe your experience with Tutor LMS Pro or comparable LMS platforms. 3. Explain how you would create personalised pathways without duplicating entire courses unnecessarily. 4. Explain how you would integrate Tutor LMS Native eCommerce with unique student pathways. 5. Explain how you would separate AI recommendations from deterministic pricing and access rules. 6. Explain how you would store pathway, progress and entitlement data. 7. Identify any likely Tutor LMS limitations or risks. 8. Describe your approach to background jobs, performance and error handling. 9. Provide examples of comparable work. 10. State whether you are an individual developer or part of a team. 11. Identify which parts of the project you would personally complete. 12. Provide an estimated cost and timescale for the paid discovery phase. 13. Provide a preliminary phased budget range for the full project. 14. List any recurring third-party costs you anticipate. 15. Confirm your availability for ongoing maintenance after launch. Generic proposals will not be shortlisted. Please begin your proposal with the words: PERSONALISED LMS This confirms that you have read the complete project description. ⸻ Deliverables Expected deliverables include: * Technical discovery report * Architecture specification * Data model * Custom WordPress plugin * Tutor LMS integrations * Native payment and subscription integrations * Student-facing interface * Administrator interface * AI-agent integration interface * Background processing system * Notifications and Brevo integration * Reporting and analytics * Automated and manual tests * Staging deployment * Production deployment support * Source code * Build instructions * Administrator documentation * Developer documentation * Maintenance and handover documentation All source code and project-specific intellectual property must be transferred to the client upon payment. The final plugin must not depend on the original developer remaining available in order to operate. ⸻ Initial engagement We intend to begin with a paid technical discovery phase rather than immediately commissioning the full build. The first contract will be to: * Review the existing website * Review Tutor LMS capabilities and limitations * Review the complete plugin specification * Recommend the final architecture * Define the proof of concept * Identify technical risks * Produce an implementation plan and fixed or phased quotation Developers who perform well during discovery may be invited to complete the proof of concept and full production build.