UX Testers for very cool AI Startup that kills software regressions

We are looking for 6–8 software developers to participate in a paid usability and product research study for Rubber Duck. Rubber Duck is an MCP-native developer tool designed to help AI coding assistants understand, repair and verify software codebases - effectively avoiding software regressions due to AI Coding Agents. We want honest, detailed criticism. Your compensation will be based on completing the study and documenting your experience—not on whether your feedback is positive. We are particularly interested in first-time users who regularly work with Cursor, Claude Code, Codex, or similar AI coding tools. WHAT YOU WILL DO Phase 1 — Test the installation and onboarding experience You will: • Start a screen recording before beginning the setup process. • Create a Rubber Duck account and obtain an access token. • Configure the Rubber Duck MCP services in Cursor, Claude Code, or Codex. • Run the health check. • Index a public, personal, or otherwise non-confidential repository (Python, JS/TS, C/C++). • Record how long each step takes. • Document unclear instructions, unexpected behavior, errors, and blockers. Please attempt the setup independently first. If you remain blocked on the same problem for approximately 20 minutes, stop, document the problem, and contact us so that we can help you continue. A failed installation is still valuable research. A genuine attempt with a clear recording, logs, and explanation will be paid for the installation milestone. Phase 2 — Use Rubber Duck on a real development task Using a public or non-sensitive repository, test Rubber Duck on at least one task that resembles something you might encounter in your normal work. Examples include: • Understanding an unfamiliar codebase • Locating the cause of a bug • Generating code or feature that fit your codebase • Reviewing code or an AI-generated change • Investigating a security concern • Evaluating the impact of a proposed change • Planning a feature • Checking whether code logic behaves as expected • Comparing two implementations Explain what you would normally do without Rubber Duck and compare that process with the result you received from Rubber Duck. Phase 3 — Test the Rubber Duck Playground You will star, fork, clone and test the following playground: https://github.com/RubberDuck-com/rubberduck-use-case-playground Web page: https://www.rubberduck.com/playground You will: • Star the repository and fork it. • Clone the repository if needed. • Start the local playground hub. • Launch the Rubber Duck Pizzeria demo. • Complete four assigned use cases (all 10). • Compare the actual experience with the expected outcome shown in the playground. • Evaluate whether the playground helps you understand what Rubber Duck does. • Identify confusing instructions, terminology, navigation, or missing information. • Explain whether the playground would make you more or less likely to continue using the product. Phase 4 — Submit UX and product feedback Your final submission must include: 1. Screen recording One or more unedited screen recordings showing the first-time setup and the most important parts of your test. No video editing is required. Your face does not need to be visible, but we strongly prefer spoken think-aloud commentary. Do not expose API tokens, passwords, private source code, or other confidential information in the recording. 2. Installation and task timeline Include: • Operating system and version • IDE or coding agent used • Previous MCP experience • Start and completion time for each major step • Time to first successful Rubber Duck result • Any steps that could not be completed 3. Issue and friction report For each issue, include: • Step where it occurred • What you expected • What actually happened • Steps to reproduce it • Screenshot or recording timestamp • Severity: blocker, major, moderate, or minor • Your proposed improvement 4. Concrete UX recommendations Provide at least five useful observations or recommendations. Each recommendation should explain: • The current problem • Why it matters • What should be changed • A concrete example of the improved wording, flow, interface, or behavior Do not provide generic feedback such as “make the UI better” or “improve the documentation.” 5. Use-case scorecard For every use case you test, report: • Whether you completed it • Time required • Usefulness from 1–5 • Confidence in the answer from 1–5 • What was useful • What was missing or incorrect • Whether you would use it in real work • How it compares with your current workflow or tools 6. Product and marketing questionnaire You will answer questions about: • The use cases you tested • Real situations from your previous work where the product might have helped • Whether it could have made those situations possible, faster, safer, or easier • Situations where it would not have helped • How you would describe the problem Rubber Duck solves in your own words • Other tools or manual processes you currently use • Where you discover developer products • What would convince you to try or purchase a product like this • What would prevent you or your team from adopting it WHO SHOULD APPLY You are a good fit when you: • Have at least two years of software development, QA engineering, security, DevOps, or technical leadership experience • Use Git regularly • Use an AI coding assistant at least weekly • Are comfortable running a local development project from a terminal • Can test with a public, personal, or non-confidential repository • Can record your screen and speak through what you are thinking • Can write detailed and specific feedback in English • Have never used Rubber Duck before Previous MCP experience is helpful but not required. We intend to select a mixture of developers who have and have not configured MCP servers before. PAYMENTS 50$ for completing the tasks above + 50$ for a 1-1 call explaining your feedbacks to us.