GitHub, Code Quality & Automated Testing Setup for Medusa/Mercur Marketplace

We have an operational multi-vendor marketplace built on Mercur 2.0 / MedusaJS with Next.js, TypeScript, PostgreSQL, GitHub, Railway, Vercel, and Stripe Connect. We are looking for an experienced engineer to establish a professional GitHub development, automated testing, code-quality, and deployment framework that will be used for all future development. The system should allow developers to safely add/customize features while giving the owner/team a simple way to verify that code has been tested and meets our development standards before approval. REQUIRED EXPERIENCE Strong experience with: • MedusaJS and its testing framework • Mercur experience strongly preferred • GitHub / GitHub Actions • CI/CD • Next.js / TypeScript / Node.js • Jest • @medusajs/test-utils • Playwright • SonarQube / SonarQube Cloud • GitHub Copilot • Railway / Vercel • PostgreSQL SCOPE 1. Review Existing Mercur / Medusa / GitHub Setup Review the current repository, Mercur/Medusa architecture, existing tests, branches, CI/CD, and Railway/Vercel deployment. Do not unnecessarily restructure the existing Mercur installation. Provide a brief recommendation before making major changes. 2. GitHub Development Controls Establish a professional development workflow including: • Main/production protection • Feature/fix branches • Pull Requests • Required automated checks • Appropriate approval requirements • Developer permissions • Controlled production deployment Future developers should not routinely push untested code directly to production. 3. GitHub Actions / CI Configure GitHub Actions so code submitted through Pull Requests automatically runs appropriate checks, including: • Build verification • TypeScript/type checking • Linting • Medusa/Jest tests • Medusa integration tests • Playwright tests • Security/dependency checks • SonarQube analysis Required failed checks should prevent code from being considered ready for production. 4. Medusa Native Testing Review and properly configure Medusa's native testing capabilities, including Jest and @medusajs/test-utils where appropriate. Establish backend/integration testing for areas such as: • APIs • Modules • Workflows • Business logic • Database behavior • Vendor permissions • Orders/payments • Future custom marketplace functionality Review existing Mercur/Medusa tests before creating unnecessary duplicate testing. Create working example tests that future developers can follow. 5. Playwright End-to-End Testing Configure Playwright and create several WORKING marketplace tests. Examples: Vendor login → create product → publish → verify product Customer → product → cart → checkout → test payment/order Vendor A → attempts to access Vendor B restricted data → access denied The purpose is to establish a reusable automated testing framework that future developers expand as features are added. Simply installing Playwright is not sufficient. 6. SonarQube / SonarQube Cloud Configure SonarQube/SonarQube Cloud with GitHub to identify issues such as: • Bugs • Security vulnerabilities • Code smells • Duplication • Maintainability issues • Technical debt Use free/open-source plans where practical. Do not activate paid software without approval. 7. GitHub Copilot – Code Verification Configure a practical repository-aware GitHub Copilot workflow that allows the owner/team to investigate the codebase and independently question technical claims. For example, we should be able to ask: • Does this functionality already exist? • Where is this feature implemented? • Which files/API control it? • Is this functionality from Medusa, Mercur, or custom code? • Trace this feature from frontend to backend. • What exactly did this developer change? • Are there tests covering this functionality? 8. Mercur / Medusa Documentation & Coding Standards Create concise repository documentation covering: • Mercur vs. Medusa architecture • Official Mercur/Medusa documentation references • Coding standards • Folder/naming standards • API/database standards • Testing requirements • Documentation requirements • Pull Request requirements • Deployment/release process Custom development should minimize unnecessary changes to Mercur/Medusa core so future framework updates remain manageable. 9. Staging / QA Workflow Review/configure the staging environment so the development process becomes: Developer → Feature Branch → Pull Request → GitHub Actions → Medusa Tests → Playwright → SonarQube → Code Review → Staging → Team QA → Approval → Production 10. Owner & Team Training – REQUIRED Training is an important deliverable. Provide a live recorded training session showing the owner/team how to: • Review a Pull Request • See exactly what a developer changed • See whether automated tests passed/failed • Review Medusa test results • Review Playwright results • Review SonarQube results • Test functionality on staging • Use GitHub Copilot to investigate the repository • Independently question developer technical claims • Determine whether required tests were added • Determine whether code is ready for approval • Verify what reached production • Understand basic rollback procedures Training should be understandable to a non-technical owner/team. DELIVERABLES • GitHub development workflow and branch protection • GitHub Actions / CI • Medusa/Jest testing setup • Working Medusa integration test examples • Playwright setup + working marketplace tests • SonarQube integration • GitHub Copilot code-verification workflow • Staging/QA workflow • Coding/testing standards • Mercur/Medusa technical documentation structure • Developer PR/testing/release templates • Simple owner verification guide • Live + recorded team training FINAL ACCEPTANCE TEST Before final payment, demonstrate the complete process with a controlled sample change: Feature Branch → Code Change → Pull Request → GitHub Actions → Medusa Tests → Playwright → SonarQube → PASS/FAIL → Staging → QA → Approval/Release. Also demonstrate how the owner can independently use GitHub/Copilot to investigate the code and verify a developer's technical claim. Documentation alone is not sufficient. The system must be working. WHEN APPLYING Please briefly answer: 1. What direct MedusaJS experience do you have? 2. Have you worked with Mercur? If yes, describe the project. 3. Have you used @medusajs/test-utils? 4. Describe your GitHub Actions/CI/CD experience. 5. Describe your Playwright experience. 6. Describe your SonarQube experience. 7. How would you keep Mercur customizations maintainable for future Mercur updates? 8. Can you train a non-technical owner/team to use and verify this system? 9. What fixed price and timeline would you propose? Target timeline: approximately 2–4 business days. Fixed-price engagement preferred. Please do not activate any paid third-party software or services without prior approval.