Backlog

Next up

In Progress

Done

Main Roadmap

<h2>Summary</h2><p>Test the complete workflow with a deliberately limited group of sports, athletes, and recruiting stakeholders before considering a public beta.</p><h2>Pilot goals</h2><ul><li><p>Validate the profile structure and required data.</p></li><li><p>Test whether match explanations are useful and understandable.</p></li><li><p>Identify stale, missing, or hard-to-verify program data.</p></li><li><p>Review consent, visibility, and document-access expectations.</p></li><li><p>Document failure modes and correction workflows.</p></li><li><p>Measure operational effort before scaling coverage.</p></li></ul><h2>Not a launch</h2><p>A private pilot is not evidence of broad product availability, guaranteed recruiting outcomes, or marketplace traction.</p><h2>Feedback question</h2><p>What minimum result would make a private pilot useful enough for you to participate?</p>

Limited private pilot

RekrutMe

<h2>Summary</h2><p>Allow authorized programs to discover relevant athletes using criteria tied to a specific program or recruitment opportunity.</p><h2>Possible scope</h2><ul><li><p>Filter by sport, event or position, performance, academic profile, intended entry period, preferences, and verification status.</p></li><li><p>Rank by the fit with a named program rather than a generic school score.</p></li><li><p>Save athletes to a shortlist.</p></li><li><p>Record a limited recruitment status after the privacy and consent model is validated.</p></li></ul><h2>Dependencies</h2><ul><li><p>Program data model.</p></li><li><p>Explainable matching.</p></li><li><p>Athlete visibility controls.</p></li><li><p>Access permissions and audit trail.</p></li><li><p>Rules against bulk export and scraping.</p></li></ul><h2>Feedback question</h2><p>Which three filters would be essential for a first recruiting search, and which filters could create unfair or unnecessary screening?</p>

Completed

Coach and recruiter candidate search

<h2>Summary</h2><p>Give athletes explicit control over discoverability, contact information, and access to sensitive documents.</p><h2>Target requirements</h2><ul><li><p>Separate profile completeness from profile visibility.</p></li><li><p>Classify data as public, restricted, or sensitive.</p></li><li><p>Keep transcripts, test reports, identity records, and similar documents out of public search.</p></li><li><p>Grant access by role, purpose, and athlete consent.</p></li><li><p>Record sensitive access and important changes.</p></li><li><p>Support correction, export, deletion, and retention rules.</p></li><li><p>Address age checks and guardian involvement where legally required.</p></li><li><p>Protect the candidate database against bulk scraping and misuse.</p></li></ul><h2>Status note</h2><p>These are product requirements. They are not a claim that the controls are already implemented.</p><h2>Feedback question</h2><p>Which information should a coach see before the athlete approves contact, and which information should always require a separate permission?</p>

Consent-based profile visibility and document access

<h2>Summary</h2><p>Produce reviewable program-level matches that separate mandatory criteria from weighted fit and explain the result in plain language.</p><h2>Planned dimensions</h2><ul><li><p>Academic fit.</p></li><li><p>Athletic fit.</p></li><li><p>Preference fit.</p></li><li><p>Scholarship fit.</p></li><li><p>Program fit.</p></li><li><p>Data confidence.</p></li></ul><h2>Intended output</h2><ul><li><p>A clearly defined fit band or score.</p></li><li><p>Component-level results.</p></li><li><p>Reasons for relevance.</p></li><li><p>Failed or borderline criteria.</p></li><li><p>Missing or unverified information.</p></li><li><p>Calculation date and rule version.</p></li><li><p>A visible reminder that the result is not a college decision.</p></li></ul><h2>Not a goal</h2><p>The prototype will not calculate an exact admission probability or guarantee eligibility, roster placement, coach contact, or scholarship funding.</p><h2>Feedback question</h2><p>What explanation would help you trust a match—and what would make a score feel misleading?</p>

Explainable matching prototype

<h2>Summary</h2><p>Model the university separately from each athletic program and, where useful, from a time-limited recruitment opportunity.</p><h2>Why it matters</h2><p>One institution can have several teams with different coaches, events or positions, performance expectations, academic criteria, recruiting priorities, and support options. A university-only match is too broad.</p><h2>Planned scope</h2><ul><li><p>Institution identity, location, size, study areas, and general contacts.</p></li><li><p>Athletic program, sport, association, division, coaches, and supported events or positions.</p></li><li><p>Program-specific academic and athletic recruiting criteria.</p></li><li><p>Scholarship or financial-aid information with sources and dates.</p></li><li><p>Optional recruitment opportunity with entry period, need, deadline, and status.</p></li></ul><h2>Feedback question</h2><p>Which program-level facts change a recruiting decision most often but are usually difficult to find or keep current?</p>

Program-level college data model

<h2>Summary</h2><p>Create one consistent public identity for REKRUTME with a canonical website, public roadmap, public documentation, and startup profile.</p><h2>Why it matters</h2><p>A project that is still in development needs a clear source of truth. Reviewers and potential pilot participants should be able to understand the product concept, current stage, limitations, next milestones, and official contact channels without finding conflicting descriptions.</p><h2>Included scope</h2><ul><li><p>Canonical website at <code>rekrutme.team</code>.</p></li><li><p>Public feedback, roadmap, and updates in Featurebase.</p></li><li><p>Public project documentation on GitHub.</p></li><li><p>F6S startup profile.</p></li><li><p>Consistent claims, links, and stage language.</p></li></ul><h2>Not included</h2><ul><li><p>Public product accounts.</p></li><li><p>Athlete applications or document uploads.</p></li><li><p>A public beta.</p></li><li><p>Recruiting outcomes or traction claims.</p></li></ul><h2>Feedback question</h2><p>What information would you need to decide whether REKRUTME is credible enough for a pilot conversation?</p>

Public project foundation

<h2>Summary</h2><p>Create a profile organized into Personal, Academics, Sports, and Preferences so that an athlete's original information remains structured and understandable.</p><h2>Planned scope</h2><ul><li><p>Personal and contact information relevant to the recruiting process.</p></li><li><p>Original academic records and grading system.</p></li><li><p>Standardized or language test records with dates and evidence.</p></li><li><p>Sport, events or positions, performances, personal bests, and achievements.</p></li><li><p>College, study, location, division, and scholarship preferences.</p></li><li><p>Completeness and verification indicators.</p></li></ul><h2>Design principle</h2><p>A normalized value must not replace the original record. The profile should preserve source values, units, dates, documents, and verification status.</p><h2>Open questions</h2><ul><li><p>Which fields are essential before matching begins?</p></li><li><p>Which fields can remain private until the athlete approves access?</p></li><li><p>How should team sports and qualitative evidence be represented?</p></li></ul><h2>Feedback question</h2><p>Which profile field is essential for a useful first match, and which common field would create unnecessary collection risk?</p>