Case studyResearch
Research Plan
Background
SlopTeacher enables developers to test their understanding of a public GitHub repository. After completing a full test, users receive a score and diagnostic and can optionally share a badge linked to their result page.
The product concept is based on the hypothesis that developers may need a structured way to assess their understanding of a codebase and communicate the results to others.
Research is required to determine whether this problem is meaningful, which users experience it, what alternatives they use, and whether SlopTeacher's assessment and badge features address their needs.
The research will focus on six objectives:
- Validate the problem: Determine whether developers struggle to explain, evaluate, debug, or extend repositories they have built or contributed to.
- Understand existing behaviour: Investigate how developers currently prepare to explain their projects and identify gaps in their understanding.
- Evaluate existing alternatives: Understand how coding assistants, interview preparation platforms, and technical assessment tools address related needs.
- Identify the initial target segment: Determine which developers experience the problem most acutely and have a clear reason to use SlopTeacher.
- Evaluate the badge proposition: Investigate whether users want to share their assessment results and whether external viewers find those results useful.
- Inform product decisions: Use the findings to refine the assessment experience, scoring, feedback, sharing mechanism, and initial positioning.
3.1 Problem Validation
- How do developers determine whether they understand their own repositories?
- Have developers experienced difficulty explaining their implementation decisions or code behaviour?
- In what situations does this difficulty become important?
- What are the consequences of being unable to explain or modify a codebase?
- How frequently do these situations occur?
- Does the problem differ between early-career developers, experienced developers, and job seekers?
3.2 Current Workflows and Alternatives
- How do developers prepare to explain projects during interviews or technical discussions?
- What methods do they use to identify gaps in their understanding?
- Do they use AI assistants, documentation, peer reviews, mock interviews, or manual code walkthroughs?
- What works well about these approaches?
- What limitations or frustrations do they encounter?
- What would make them switch from an existing workflow to a dedicated assessment tool?
3.3 Assessment Experience
- Would developers find questions based on their own repositories useful?
- Which types of questions best reveal understanding: implementation details, dependencies, architecture, debugging, edge cases, or trade-offs?
- What makes feedback credible and actionable?
- How much explanation should accompany a score?
- What would make users trust or distrust an automated assessment?
- How should the product communicate uncertainty or limitations in its evaluation?
3.4 Badge and Sharing Experience
- Do developers want to share evidence of their repository assessment results?
- Where would they display a badge, if anywhere?
- What would motivate them to share a result publicly?
- What concerns might prevent them from sharing?
- What information would an external viewer need to interpret the badge?
- Would recruiters, mentors, or other developers consider the result useful?
- Would the badge still be valuable if it were not considered during hiring?
3.5 Market and Positioning
- Which user segment has the strongest need for repository-specific assessment?
- Is interview preparation the primary use case, or is independent learning equally important?
- How does SlopTeacher compare with general-purpose AI assistants and existing interview tools?
- What would make SlopTeacher meaningfully different from those alternatives?
- Is there evidence of willingness to pay, or should the initial product focus on free adoption and learning?
The initial research will focus on developers who have built or contributed to real repositories.
| Participant segment | Research purpose | Initial priority |
|---|---|---|
| Early-career developers | Understand confidence, knowledge gaps, and project explanation challenges | High |
| Developers preparing for technical interviews | Understand interview preparation workflows and repository-specific needs | High |
| Independent developers | Understand self-assessment and ongoing code comprehension needs | Medium |
| Developers contributing to unfamiliar repositories | Understand repository onboarding and codebase comprehension | Medium |
| Engineering mentors or senior developers | Understand how they evaluate another developer's understanding | Secondary |
| Recruiters or technical interviewers | Understand whether an external assessment result would be useful or credible | Secondary |
Initial Sample
Conduct 5-8 exploratory developer interviews in the first round.
This is a practical starting sample for qualitative discovery, not a statistically representative sample of the developer population.
Recruit participants based on relevant experience rather than assuming that every developer uses AI tools or experiences the same problem.
After the first round, assess whether additional participants are needed to investigate contradictory findings or underrepresented segments.
After collecting the evidence, findings will be organized into the following categories.
5.1 Observed Behaviours
Document what participants actually do, including how they prepare, explain code, and identify gaps.
5.2 Pain Points
Identify recurring difficulties and the situations in which they occur.
5.3 Existing Workarounds
Record the tools and processes participants use, along with their perceived strengths and limitations.
5.4 User Needs
Identify what participants are trying to accomplish, independently of the proposed SlopTeacher solution.
5.5 Contradictory Evidence
Record cases where participants do not experience the assumed problem or prefer existing alternatives.
5.6 Product Implications
Translate supported findings into potential changes to the assessment experience, feedback, scoring, sharing, or positioning.
Each finding should include its evidence source, the number or type of participants supporting it where applicable, and any relevant limitations.
Do not treat a single participant's statement as a universal pattern.
The initial research will investigate the following hypotheses.
| ID | Assumption | Evidence to investigate |
|---|---|---|
| A1 | Developers may have gaps in their understanding of repositories they have built or contributed to | Past experiences explaining, debugging, or extending code |
| A2 | Developers may struggle to anticipate questions about their own projects | Interview preparation methods and previous technical discussions |
| A3 | Repository-specific assessment may be more relevant than generic practice for certain use cases | Participant feedback and comparative prototype testing |
| A4 | Evidence-grounded feedback may be more useful than a score alone | Feedback comprehension and reported actionability |
| A5 | Developers may value a portable assessment result | Sharing preferences and actual badge behaviour |
| A6 | External viewers may find a repository-specific assessment result useful | Badge viewer research |
| A7 | Users may prefer control over whether their results are shared | Privacy expectations and sharing preferences |
| A8 | SlopTeacher may provide value beyond a general-purpose AI assistant | Comparative task testing |
These assumptions are hypotheses, not established facts. The research may support, refine, or reject them.
The research will be considered useful when it produces enough evidence to make informed product decisions, not merely when every planned activity has been completed.
Research deliverables
- Research questions and participant criteria documented.
- Initial developer interviews completed and documented.
- Competitive analysis reviewed against official sources and hands-on testing where possible.
- Market metrics recorded with traceable sources.
- Assumptions evaluated against collected evidence.
- Prototype feedback collected from relevant participants.
- Badge comprehension and credibility investigated.
- Key insights synthesized with supporting evidence.
- Product implications and unresolved questions documented.
Decision criteria
At the end of the research, determine:
- Whether the core problem is supported by participant evidence.
- Which target segment experiences the problem most clearly.
- Whether repository-specific assessment provides value beyond existing alternatives.
- Whether the scoring and diagnostic are understandable and credible.
- Whether the badge adds meaningful value to users or external viewers.
- Which product assumptions need further testing.
- Which features should be prioritized, changed, or deprioritized.
No numerical success thresholds are assigned in advance because baseline data is not yet available. Quantitative targets should be established when appropriate after initial observation and testing.
- The initial interview sample will be small and exploratory.
- Participants may not represent the broader developer population.
- Self-reported experiences may differ from observed behaviour.
- Public competitor documentation may not describe every feature or limitation.
- Positive reactions to a prototype do not establish retention or willingness to pay.
- Badge-sharing intent does not establish actual sharing behaviour.
- Recruiter interest does not establish that the badge predicts job performance.
- Market-level statistics do not directly measure demand for SlopTeacher.
These limitations should be included when interpreting the results.
The research should establish a clearer understanding of the problem SlopTeacher is trying to solve, the users most likely to experience it, the alternatives they already use, and the value of repository-specific assessment.
It should also determine whether the shareable badge is a meaningful part of the product experience or an optional feature with limited user value.
The final outcome will be an evidence-based set of product insights and recommendations that can inform the subsequent User Personas, Jobs To Be Done, and product development decisions.
Competitive Analysis
SlopTeacher sits at the intersection of four adjacent categories:
- Repository understanding and coding assistants: Help developers explore codebases, explain files, navigate symbols, and ask repository-specific questions.
- Technical interview preparation: Help developers practise coding interviews, system design, and technical questioning.
- Technical skills assessment: Evaluate candidates through coding challenges or structured technical assessments.
- Digital credentials and shareable achievements: Let users share badges or credentials that represent a learning outcome, achievement, or assessed competency.
SlopTeacher combines repository-grounded assessment, diagnostic feedback, and an optional shareable badge. The key competitive question is whether this combination provides meaningful value beyond existing alternatives.
2.1 GitHub Copilot
Category: Repository understanding / AI coding assistant
Official sources:
- Using GitHub Copilot to explore a codebase
- Asking GitHub Copilot questions in GitHub
- Indexing repositories for GitHub Copilot
Documented capabilities
- Answers questions about a repository's purpose, structure, files, symbols, and functionality.
- Can use repository context to ground responses in actual files and symbols.
- Supports follow-up questions about the same codebase.
Competitive strengths
- Repository questions are integrated into an existing developer workflow.
- Users can ask their own questions rather than follow a fixed assessment.
- Developers may already have access to a coding assistant, reducing the need for a separate tool for basic code explanations.
Potential gap SlopTeacher could address: GitHub Copilot's repository exploration workflow is primarily designed to help users understand and work with code. SlopTeacher could structure a test in which the user must answer questions and then receive an assessment of those answers.
Implication for SlopTeacher: Do not position SlopTeacher as merely "AI that understands a GitHub repository." Position it around the assessment loop: question, user explanation, evidence-based evaluation, diagnostic, and optional shareable result.
2.2 GitHub Copilot Code Review
Category: Code review / quality assistance
Official source: GitHub Copilot documentation
Code review tools examine code changes and help developers identify issues. They are adjacent rather than direct substitutes because evaluating code is not the same as evaluating a person's understanding of it.
Potential SlopTeacher distinction: SlopTeacher could assess whether a user can explain why an implementation works, what trade-offs it makes, and where it may fail, instead of primarily reviewing code for defects.
2.3 interviewing.io
Category: Technical interview practice
Official source: interviewing.io
interviewing.io offers technical interview practice, including mock interviews and AI-based interview practice. It competes for the user's time and budget when the goal is technical interview preparation.
Competitive strengths
- Interview-oriented practice is its central value proposition.
- Users can practise communicating and solving problems in an interview-like setting.
Potential SlopTeacher distinction: SlopTeacher's proposed focus is the user's own repository, rather than only a general interview prompt or standardized coding problem.
2.4 CodeSignal
Category: Technical assessment and skills evaluation
Official sources:
Documented capabilities
- Provides technical assessments and structured coding environments.
- Produces scores and reports for assessments.
- Supports sharing assessment reports by link in its documented assessment workflow.
- Offers hiring-oriented evaluation and assessment workflows.
Competitive strengths
- Structured assessment and reporting are established product capabilities.
- Its workflows are designed around evaluating technical skills, particularly in hiring contexts.
Potential SlopTeacher distinction: SlopTeacher could offer a lightweight self-service workflow focused on a developer's own public repository and a badge that the developer chooses to publish on their GitHub profile.
2.5 LeetCode
Category: Coding interview preparation
Official source: LeetCode
LeetCode is a well-known alternative for developers preparing for coding interviews through practice problems and related resources.
Competitive strengths
- Provides a repeatable practice workflow.
- Supports preparation for algorithmic and technical interview questions.
Potential SlopTeacher distinction: SlopTeacher would focus on understanding an existing codebase rather than primarily solving a standalone coding problem.
2.6 General-purpose AI assistants, including ChatGPT
Category: Flexible substitute
Official source: ChatGPT
Users can ask an AI assistant to explain a repository, create practice questions, act as an interviewer, and critique their answers if they provide sufficient code context.
Competitive strengths
- Flexible conversational interaction.
- Can be adapted to many repositories and assessment styles.
- May be sufficient for users who are comfortable designing their own prompts and evaluation criteria.
Potential SlopTeacher distinction: SlopTeacher could reduce setup effort and provide a consistent sequence of questions, repository-linked evidence, scoring criteria, a diagnostic report, and an optional badge.
2.7 Credly
Category: Digital credentials and badges
Official source: What is a badge? (Credly Help Center)
Credly describes digital badges as representations of learning outcomes, experience, or competencies. Badges can link to contextual metadata and be shared online.
Competitive relevance: Credly is relevant to the badge and credential model rather than repository assessment itself.
Potential SlopTeacher distinction: SlopTeacher's badge could be tied to a specific repository assessment, score, and completion result, rather than a credential issued for a course or professional program.
Interpretation rules
- Documented means the capability is described in the cited public product materials.
- Not established means this research has not verified the capability as a central part of the product. It does not mean the capability is absent.
- SlopTeacher entries describe intended product behaviour, not independently validated outcomes.
| Capability | GitHub Copilot | interviewing.io | CodeSignal | LeetCode | Credly | SlopTeacher opportunity |
|---|---|---|---|---|---|---|
| Understand or explore repository context | Documented | Not established as core | Not established as core | Not core | No | Core |
| Technical interview practice | Adjacent | Core | Assessment/interview workflows | Core for coding practice | No | Repository-specific practice |
| Structured technical assessment | Not established as core | Interview practice available | Core | Problem-based | No | Core |
| Score/report | Not established as core for repo exploration | Feedback available; verify current detail | Documented | Problem results | Credential metadata, not a repository test score | Core |
| User's own repository as assessment source | Repository Q&A documented | Verify current scope | Verify current scope | Not core | No | Core |
| Code-linked evidence in assessment feedback | Repository answers can cite files/symbols; full assessment workflow not established | Verify | Depends on assessment/report | Depends on problem | Credential metadata | Intended core |
| Shareable result or achievement | Not equivalent to a score badge | Verify current sharing options | Assessment reports shareable by link | Profile/activity features; not equivalent to a repository badge | Core | Opt-in badge and result page |
| Badge designed for GitHub profile | Not core | Not established | Not established as core | Not established as core | Shareable credentials | Intended feature |
Sources: GitHub Copilot documentation; interviewing.io; CodeSignal official assessment documentation; LeetCode; Credly Help Center.
Finding 1: Repository context is not sufficient differentiation
GitHub Copilot already supports asking questions about a codebase and grounding responses in repository files and symbols.
Product implication: SlopTeacher should compete on the structured assessment experience rather than basic repository analysis.
Finding 2: Interview practice is an established use case
interviewing.io and LeetCode address important parts of interview preparation, while CodeSignal provides structured technical assessment.
Product implication: SlopTeacher needs to show why questions about a user's own repository provide value that generic interview practice does not.
Finding 3: The assessment result must be credible
A score or a label such as "pass," "pending," or "slop" is only useful if the user and external viewer understand what it measures.
Product implication: Each result should explain the assessment scope, criteria, evidence, and limitations. Avoid suggesting that one test proves general engineering competence.
Finding 4: The badge adds a distribution loop
The badge lets the assessment result travel beyond SlopTeacher. GitHub supports profile READMEs, where users can describe their work and include images.
Official source: Managing your profile README (GitHub Docs).
Product implication: Treat badge sharing as a product loop to test, not as guaranteed viral growth. Measure whether users share the badge, whether viewers open the result, and whether the result page generates meaningful engagement.
Finding 5: General-purpose AI is a high-priority substitute
A user can manually ask an AI assistant to quiz them on a repository. If that workflow is good enough, SlopTeacher must make the difference visible.
Product implication: Run a direct comparison. Give users a similar repository-understanding task in SlopTeacher and with a general-purpose assistant. Compare setup effort, question relevance, feedback usefulness, user trust, and task completion. Do not claim superiority before collecting results.
Positioning statement
SlopTeacher helps developers test how well they understand a GitHub repository and optionally share a score-backed assessment badge with others.
Proposed value proposition
Test your understanding. See your gaps. Share your result.
Potential differentiators to validate
- Repository-grounded questions: Questions refer to actual files, functions, dependencies, and design choices in the submitted repository.
- Assessment rather than explanation alone: The user must answer questions rather than only receive explanations from an AI assistant.
- Evidence-backed feedback: Results explain which parts of the repository support the assessment and why an answer was considered strong or weak.
- A portable result: Users can opt in to sharing a badge and a result page.
- User-controlled disclosure: Results remain unshared until the user chooses to share them.
These are product hypotheses and intended capabilities. Only claim features that the current implementation supports.
Positioning risks
- "Ownership" may be interpreted as authorship verification. SlopTeacher tests understanding, not necessarily who wrote the code.
- The label "slop" may be memorable but could alienate users or make an uncertain AI judgement appear definitive.
- A public badge can be mistaken for an accredited certification if its scope and issuer are unclear.
- A secret URL offers access control by possession of the link, not proof of the viewer's identity.
- If scoring is inconsistent or not tied to evidence, sharing can amplify distrust rather than credibility.
Market Research
SlopTeacher is an early-stage product at the intersection of:
- Developer learning and self-assessment.
- Technical interview preparation.
- Repository comprehension and code maintenance.
- Skills assessment.
- Shareable digital achievements.
It would be misleading to claim that SlopTeacher has already established a distinct market category. The research question is whether a sufficiently large and reachable user segment has this problem and values the product's specific combination of features.
Primary market hypothesis
Individual developers who need to explain a real repository may value a structured assessment that identifies gaps in their understanding and produces an optional, shareable result.
Secondary market hypotheses
- Developers may use SlopTeacher as part of interview preparation.
- Independent developers may use it before extending or maintaining a project.
- Engineering teams may use repository assessments for learning or onboarding.
- Hiring teams may eventually use results as supplementary evidence.
The individual developer use case should be tested first. Team and hiring use cases introduce additional needs around fairness, privacy, assessment validity, and integration.
The following are published metrics from external sources. They provide context, not a direct estimate of SlopTeacher's market.
7.1 Stack Overflow Developer Survey 2025
Sources:
| Metric | Published result | What it suggests | What it does not prove |
|---|---|---|---|
| Respondents using or planning to use AI tools in development | 84% | AI tools are a mainstream part of the development context | That 84% need or would use SlopTeacher |
| Respondents reporting distrust in AI output accuracy | 46% | Verification and trust are relevant concerns | That repository-specific assessment is the preferred solution |
| Respondents reporting trust in AI output accuracy | 33% | Trust is mixed, rather than uniformly negative | That the remaining respondents all distrust AI |
| Respondents frustrated by AI solutions that are almost right | 66% | Correctness and debugging remain important pain points | That this frustration is caused by lack of code ownership |
The 2025 survey received more than 49,000 responses from 177 countries, according to Stack Overflow's press release. This is a large global developer survey, but it is a survey of respondents and should not automatically be treated as a perfect census of all developers.
Interpretation for SlopTeacher: These results support the context that AI tools are widely used and developers have concerns about output quality. They do not establish demand for SlopTeacher's assessment or badge.
7.2 GitHub Octoverse 2025
Source: GitHub Octoverse 2025
GitHub reported:
- More than 180 million developers on GitHub.
- More than 36 million developers joined in the preceding year.
- More than 4.3 million AI-related repositories, nearly doubling in less than two years.
- Roughly 80% of new GitHub users tried Copilot within their first week.
Interpretation for SlopTeacher: GitHub is a large and active ecosystem for developer work, making GitHub-based distribution and repository assessment plausible. However, the total number of GitHub developers is not SlopTeacher's addressable market. Many will not be active developers in the target segment, need this type of test, or be willing to use a third-party assessment.
7.3 HackerRank 2025 Developer Skills Report
Source: HackerRank 2025 Developer Skills Report
HackerRank reports that its 2025 report combines platform data with a survey of 13,732 developers, engineering managers, recruiters, executives, and students across 102 countries, collected in Q4 2024 and early 2025.
Selected findings reported by HackerRank:
- 74% of developers surveyed said they struggle to land jobs.
- 66% said they would rather be evaluated on real-world skills.
- 78% said assessments do not align with real-world tasks.
- 62% said they feel forced to overprepare for algorithm-heavy assessments that do not reflect real work.
Interpretation for SlopTeacher: The report supports investigating whether developers want assessments tied more closely to real work. It does not specifically establish demand for repository ownership tests or public badges.
7.4 Digital credentials and profile sharing
Sources:
Credly describes digital badges as shareable representations of learning outcomes, experiences, or competencies that can link to contextual metadata. GitHub allows users to display a profile README at the top of their profile and include images.
These sources establish that the sharing format and distribution surface exist. They do not establish that recruiters will value a SlopTeacher badge or that a badge will improve hiring outcomes.
Interpretation for SlopTeacher: A GitHub badge is technically aligned with how developers present their work. Its professional value must be tested with both badge earners and viewers.
Trend 1: AI tools are widely used, while trust in their output is mixed
Stack Overflow's 2025 survey reported 84% usage or planned usage of AI tools and 46% active distrust of their output accuracy.
Product implication: Verification is a relevant context for the product. Do not conclude that SlopTeacher solves this problem until user research demonstrates the connection.
Trend 2: GitHub is a large distribution surface
GitHub reported more than 180 million developers in its 2025 Octoverse report.
Product implication: GitHub repositories provide a natural input source, and GitHub profile badges provide a natural place to display results. The total GitHub population should not be used as SlopTeacher's TAM.
Trend 3: Technical assessment vendors are emphasizing practical skills
HackerRank's survey findings indicate interest in real-world assessments, while CodeSignal offers structured technical assessment and reporting.
Product implication: SlopTeacher should investigate whether assessing a developer's own repository creates a meaningful advantage over standardized technical tasks. Do not assume all current assessments are generic or unrealistic.
Trend 4: Digital badges can carry contextual information
Digital credential platforms demonstrate established mechanisms for sharing achievement metadata.
Product implication: The SlopTeacher badge should link to a result page with clear information about the assessment, score, date, repository scope, and limitations. The image alone should not carry claims that cannot be substantiated.
The following segments are hypotheses for research. They are not personas derived from interviews.
| Segment | Triggering situation | Job to be done | Potential value | Initial priority |
|---|---|---|---|---|
| Early-career developers | Preparing to explain a portfolio project | Find gaps in understanding before an interview | Repository-specific practice and feedback | High |
| Job-seeking developers | Preparing for a technical interview or project walkthrough | Practise explaining implementation decisions | Structured rehearsal and optional shareable result | High |
| Independent developers | Returning to or extending a project | Check understanding before making changes | Self-assessment and knowledge-gap discovery | Medium |
| Developers learning an unfamiliar codebase | Joining a project or contributing to open source | Understand key components and dependencies | Structured comprehension practice | Medium |
| Engineering teams | Onboarding or reviewing contributors | Support consistent code walkthroughs | Team learning and supplementary assessment | Later |
| Hiring teams | Reviewing a candidate's submitted repository | Gather supplementary evidence about understanding | Structured discussion starting point | Later |
Recommended beachhead
Begin with individual developers preparing to explain their own projects in interviews.
Reasons to test this segment first:
- The use case has a clear triggering event.
- The repository already exists, which lowers setup friction.
- The user can assess value immediately by reviewing questions and feedback.
- The badge offers a plausible, but unproven, incentive to share results on a GitHub profile.
This is a strategic recommendation, not a finding that this segment has the highest willingness to pay.
These are candidate JTBD statements to validate through interviews. The dedicated Jobs to be Done card repeats the statements and critical questions for quick reference.
Core job
When I need to explain a repository I have built or contributed to, I want to test whether I can explain its important implementation details and trade-offs, so I can identify gaps before someone else exposes them.
Interview preparation job
When I am preparing for a technical interview, I want to practise questions grounded in my own project, so I can explain the decisions and behaviour of the codebase rather than only practise generic coding problems.
Self-assessment job
When I am unsure how well I understand a codebase, I want an assessment that identifies specific knowledge gaps, so I know what to revisit.
Sharing job
When I complete an assessment, I want to share a clear record of my result, so other people can inspect what I was assessed on and what the score means.
Critical validation questions
- Do users currently experience these situations?
- What do they do instead?
- How often does the problem occur?
- What happens if they do nothing?
- Do they prefer private learning feedback, a public badge, or both?
- What would make them trust or distrust the score?
- Would they share the result if it did not improve their professional credibility?
- Would they still use SlopTeacher if the badge feature were removed?
The badge could bridge the assessment experience and a developer's public profile.
Proposed flow
- User submits a public GitHub repository.
- SlopTeacher generates and administers a repository-grounded test.
- User completes the full assessment and receives a score and diagnostic.
- User chooses whether to share the result.
- If sharing is enabled, the app creates a long, random secret URL for the result.
- The user adds the badge image and link to a GitHub profile README or another suitable surface.
- A viewer opens the badge link and sees the result page.
Potential benefits to test
- The badge gives users a tangible output from completing the test.
- The result page can provide more context than a static image.
- Users may have an incentive to share if the badge helps them communicate their project understanding.
- Shared results may introduce new users to SlopTeacher.
Risks and limitations
- A badge may have little value if external viewers do not recognize or trust the issuer.
- Users may avoid sharing weak results, creating selection bias in publicly visible scores.
- A badge could be mistaken for a certification unless its meaning is explicit.
- A score may be gamed or become stale as the repository changes.
- A secret link can be forwarded. It controls access by possession of the URL; it does not verify the viewer's identity.
- A result for one repository and one assessment should not imply broad competence across programming or software engineering.
Suggested badge metadata
The result page should, where supported, make these fields clear:
- Assessment title and version.
- Repository name and a link to the assessed repository.
- Date of completion.
- Score and the scale used.
- Assessment scope and scoring criteria.
- What the score does and does not establish.
- Whether the repository's current state may differ from the assessed version.
- A way to revoke or rotate a shared link, if supported.
Do not use the total GitHub developer count as TAM
GitHub's reported population of more than 180 million developers is an ecosystem metric, not a count of potential SlopTeacher customers.
A credible market-size model needs to estimate:
- The population in the chosen geography and segment.
- The proportion who own or contribute to a relevant repository.
- The proportion who have a need to test their understanding.
- The proportion who find SlopTeacher preferable to existing alternatives.
- The proportion who complete an assessment, return, or pay, depending on the business model.
Those proportions are currently unknown.
Recommended market-sizing approach
Use a bottom-up model once the target segment and business model are clearer.
Potential annual paid market
Target users in selected segment × proportion with the problem × proportion willing to pay × annual revenue per paying user
For a free product, use a separate adoption model:
Reachable target users × activation rate × test completion rate × repeat/share rate
These are formulas, not estimates. Do not fill them with invented percentages.
Current market-size status
| Measure | Status | Reason |
|---|---|---|
| Total addressable market (TAM) | Not estimated | No validated target population or pricing model |
| Serviceable available market (SAM) | Not estimated | Initial geography and reachable segment are not fixed |
| Serviceable obtainable market (SOM) | Not estimated | No distribution, conversion, or retention data |
| Willingness to pay | Unknown | Requires interviews or pricing experiments |
| Badge adoption rate | Unknown | Requires product usage data |
| Recruiter trust in results | Unknown | Requires viewer research and assessment validation |
It is more credible to leave these fields unestimated than to insert a precise number that cannot be defended.
These are secondary-research conclusions and hypotheses, not user-research findings.
Finding 1: AI use and trust concerns establish context, not direct demand
Public developer surveys show widespread AI tool use and concerns about output accuracy.
Implication: Verification is a relevant topic to investigate, but the link to SlopTeacher's specific assessment must be validated.
Finding 2: GitHub is a plausible input source and distribution surface
GitHub's reported developer population and profile README functionality make repository-based testing and profile badge sharing technically plausible.
Implication: Do not use the total GitHub population as the addressable market. Estimate the relevant segment from reliable population data and validate its needs.
Finding 3: Developers may value assessments grounded in real work
HackerRank's reported findings support investigating whether practical assessment feels more relevant than algorithm-heavy tasks.
Implication: Test whether repository-specific questions are perceived as more useful than existing interview preparation methods.
Finding 4: The badge is a hypothesis, not proven acquisition
Digital credentials and GitHub profile customization establish that badges can be shared. They do not prove that users will share SlopTeacher results or that viewers will trust them.
Implication: Measure badge opt-in, result-page views, referral starts, and new assessment completions attributable to badge links.
Finding 5: The initial audience should be narrow
Developers preparing to explain their own projects have a clear situation in which the product could be useful.
Implication: Test this segment first, then expand to teams or hiring workflows only if evidence supports it.
The recommended validation plan (stages 1-5 and metrics) lives under Research Plan.
- This report is based on public secondary sources, not new user interviews.
- Competitor capabilities can change. Product pages and documentation should be rechecked before publication.
- Competitor categories overlap; the categories here are analytical groupings, not official industry classifications.
- Metrics from Stack Overflow and HackerRank are attributed to their publishers. Survey findings do not automatically generalize to all developers.
- Industry-level AI adoption and hiring metrics are not evidence of SlopTeacher demand.
- No TAM, SAM, SOM, conversion rate, badge adoption rate, or willingness-to-pay figure has been invented.
- Product differentiation remains a hypothesis until validated against alternatives.
- A test score is not equivalent to proof of authorship, identity, or general software engineering competence.
- The security of secret-link sharing depends on implementation details beyond the product description.
- No claim is made that SlopTeacher improves hiring outcomes, interview pass rates, or engineering performance.
All sources below are public product documentation, publisher reports, or official product pages. Research snapshot date: 11 October 2026. Publisher statistics are cited as reported by the publisher.
Developer and market research
- Stack Overflow. 2025 Developer Survey. AI adoption, trust, and frustration findings.
- Stack Overflow. 2025 Developer Survey press release. Survey response count and geographic coverage.
- GitHub. Octoverse 2025. GitHub developer population and AI repository signals.
- HackerRank. 2025 Developer Skills Report. Developer hiring and assessment survey findings.
Competitive and product documentation
- GitHub Docs. Using GitHub Copilot to explore a codebase.
- GitHub Docs. Asking GitHub Copilot questions in GitHub.
- GitHub Docs. Indexing repositories for GitHub Copilot.
- interviewing.io. Official website.
- CodeSignal. Technical Assessments.
- CodeSignal Help Center. Quick Start Guide: Assessments.
- CodeSignal Help Center. Assessment design best practices.
- LeetCode. Official website.
- Credly Help Center. What is a badge?.
- GitHub Docs. Managing your profile README.
Do not state that:
- "Most developers do not understand their own code."
- "AI coding has created a widespread repository ownership crisis."
- "Recruiters trust SlopTeacher badges."
- "SlopTeacher proves a developer wrote the repository."
- "SlopTeacher predicts interview performance."
- "The badge will make users go viral."
- "The product has a multi-billion-dollar market" without a transparent, defensible market model.
- "No competitor offers repository-specific assessment" without a current, documented competitive audit.
Use careful alternatives:
- "This report identifies a hypothesis that needs validation."
- "Public research supports the broader context, but not direct demand for SlopTeacher."
- "The badge is designed to communicate the result of a specific assessment."
- "The product aims to provide repository-grounded evidence of demonstrated understanding."
User Personas
Initial focus is developers who have built or contributed to real repositories.
| Persona | What they need | Priority |
|---|---|---|
| Early-career developers | Build confidence, surface knowledge gaps, and get better at explaining their own projects. | High |
| Developers preparing for technical interviews | Practice interview-style explanation against a repository they actually claim to know. | High |
| Independent developers | Self-assess ongoing code comprehension without a team or mentor looking over their shoulder. | Medium |
| Developers contributing to unfamiliar repositories | Onboard into a codebase faster and prove they understand what they are changing. | Medium |
| Engineering mentors or senior developers | Evaluate another developer's understanding with a shared, repository-grounded artifact. | Secondary |
| Recruiters or technical interviewers | Decide whether an external ownership assessment result is useful or credible in hiring. | Secondary |
Jobs to be Done
Candidate JTBD statements from Market Research (§10). Validate through interviews before treating as findings.
When I need to explain a repository I have built or contributed to, I want to test whether I can explain its important implementation details and trade-offs, so I can identify gaps before someone else exposes them.
When I am preparing for a technical interview, I want to practise questions grounded in my own project, so I can explain the decisions and behaviour of the codebase rather than only practise generic coding problems.
When I am unsure how well I understand a codebase, I want an assessment that identifies specific knowledge gaps, so I know what to revisit.
When I complete an assessment, I want to share a clear record of my result, so other people can inspect what I was assessed on and what the score means.
- Do users currently experience these situations?
- What do they do instead?
- How often does the problem occur?
- What happens if they do nothing?
- Do they prefer private learning feedback, a public badge, or both?
- What would make them trust or distrust the score?
- Would they share the result if it did not improve their professional credibility?
- Would they still use SlopTeacher if the badge feature were removed?
Key Insights
- The core gap is demonstrating ownership of a real repository, not producing working code.
- Differentiation must come from structured, repo-grounded assessment and credible feedback: generic AI and interview tools already cover adjacent jobs.
- Best first beachhead: developers preparing to explain their own projects in technical interviews.
- The shareable badge is a distribution hypothesis, not proven demand or proof of authorship.
- Current direction rests on secondary research and assumptions; primary interviews still need to validate which segments feel the pain and trust the score.
