Turning Public Sports Data into a College Basketball Coaching MVP
I transformed an aspiring founder’s early-stage concept into a client-accepted, full-stack analytics MVP by defining the product, designing the architecture, and building the data pipeline, calculation engine, interface, tests, and documented handoff from the ground up.
The project began at the concept stage. An aspiring founder had a vision for a college basketball coaching analytics product but no existing prototype, technical architecture, or defined implementation plan. The goal was to help coaches explore statistics, compare lineup combinations, plan plays, evaluate results over time, and examine player performance, shot locations, possessions, opponent tendencies, and play outcomes. The system was designed around preprocessed analytics rather than continuous live computation: publicly available information could be collected and prepared in advance so coaches could query and compare useful information quickly during preparation or in-game decision support. Through regular conversations, sketches, paper calculations, and incremental demonstrations, I translated the founder’s domain vision into a workable product scope, analytical model, and technical roadmap.
The product at a glance
From scattered public records to a usable coaching analytics MVP
These diagrams describe the verified system at a high level. Source names, formulas, schemas, project identifiers, and real records are excluded; all example labels and data are fictional.
End-to-end architecture
A complete analytics path—not simply a dashboard
Manually triggered collectors retrieved source data without hiding its inconsistencies.
Normalize identities, connect related records, handle gaps and duplicates, and add derived context.
Store analysis-ready records with one consistent interpretation of the source information.
Express APIs powered an AngularJS interface for search, comparison, and play planning.
Data transformation
Multiple inconsistent records became one analysis-ready model
name: "R. Hart"team: "NC"number: 14player: "Riley Hart"school: "North City"player_id: nullathlete_id: "P-014"team_code: "NCTY"lineup: incomplete- Resolve identities
- Normalize formats
- Connect source records
- Handle gaps and duplicates
- Add related and derived data
canonical_id: "player_014"display_name: "Riley Hart"team: "North City"source_links: 3lineup_context: enrichedderived_metrics: availableFictional names and fields demonstrate the verified transformation pattern without reproducing client data.
Domain translation
A coaching question became tested software
Coach-facing workflow
Prepared analytics could be queried quickly when decisions mattered
- 1Refresh public data
Trigger the MVP’s collectors manually to retrieve the latest available source information.
- 2Transform and prepare
Normalize, connect, enrich, and calculate before the information reaches the interface.
- 3Search and review
Explore player, game, lineup, shot, possession, and outcome statistics.
- 4Compare lineups
Review combinations through one consistent analytical model.
- 5Plan plays and strategy
Use preprocessed information during preparation and in-game decision support.
The system prepared analytics ahead of use; it did not continuously scrape or recalculate every metric live during a game.
The impact path
Inherited
An aspiring founder had a strong vision for college basketball coaching analytics but no prototype, technical architecture, or defined implementation plan.
Owned
I led product discovery and converted a broad domain vision into a defined MVP scope, user workflows, data requirements, and technical plan.
Changed
I wrote Node.js data collectors and web scrapers that retrieved raw roster, box-score, play-by-play, shot-location, and lineup information from public sources.
Result
Accepted — Client-reviewed MVP
What I inherited
The problem and the reality around it
The problem
- An aspiring founder had a strong vision for college basketball coaching analytics but no prototype, technical architecture, or defined implementation plan.
- Public roster, box-score, play-by-play, shot-location, and lineup data varied across sources and had to become one dependable analytical model.
- Coaching concepts needed to be translated into calculations that were both computationally correct and meaningful for lineup comparison and play planning.
The constraints
- Multiple inconsistent public data sources with conflicting names, identifiers, formats, and incomplete records
- A calculation-heavy product whose basketball logic began as conversations, sketches, and paper formulas
- Manual data refreshes appropriate to the MVP scope
- A complete handoff that the client could install and run without continued assistance
- Client identity, project identity, source identities, formulas, schemas, and real records remain confidential
What I owned
My responsibility in the work
I led product discovery and converted a broad domain vision into a defined MVP scope, user workflows, data requirements, and technical plan.
I designed the complete architecture across raw collection, transformation, normalization, enrichment, storage, calculations, APIs, and the AngularJS interface.
I built and validated the product as a solo full-stack developer, then documented it for an independent client handoff.
How I approached it
Decisions, tradeoffs, and delivery
I designed the application architecture, data flow, storage model, transformation process, API layer, calculation system, and user interface as one connected product. Custom Node.js data collectors retrieved raw roster, box-score, play-by-play, shot-location, and lineup information from multiple public sources. I intentionally separated collection from interpretation: the ingestion layer captured the available raw data, while a dedicated transformation layer handled the harder work of making it consistent and useful. That layer reconciled variations in names, identifiers, formats, completeness, and record structure; connected related information distributed across sources; normalized the results into a shared MongoDB model; and enriched the records with additional context and derived metrics. I then worked with the client to translate coaching questions into calculation rules, exposed the processed information through Express APIs, and built an AngularJS MVP for searching statistics, comparing lineups, and supporting play-planning decisions. Manual refreshes kept the engagement focused on validating the core analytical workflow rather than adding production scheduling infrastructure before it was needed.
- I wrote Node.js data collectors and web scrapers that retrieved raw roster, box-score, play-by-play, shot-location, and lineup information from public sources.
- I kept ingestion separate from interpretation and built a dedicated transformation layer to reconcile inconsistent names, identifiers, formats, missing fields, duplicate records, and related information spread across sources.
- I normalized the transformed data into a shared MongoDB model and enriched records with connected context and derived basketball metrics.
- I worked with the client to turn coaching questions into executable calculation rules rather than implementing a prewritten set of formulas.
- I exposed the processed information through Express APIs and built an AngularJS MVP for searching statistics, comparing lineups, and supporting play-planning decisions.
- I validated the transformation and calculation logic with unit tests, manual end-to-end testing, incremental demonstrations, and client review.
- I delivered setup and technical documentation covering the collectors, transformation process, models, APIs, calculations, architecture, and application operation.
How I led
The team and stakeholder system
Although I was the sole developer, the product depended on close collaboration with the client. The client brought the basketball vision and strategic questions; I led the discovery process that converted those ideas into data requirements, product workflows, calculation behavior, and an executable technical plan. We used ongoing conversations, sketches, paper calculations, and incremental demonstrations to refine the MVP. I validated the system through unit tests, manual end-to-end testing, and client review so the results were correct both computationally and in the way they represented the underlying coaching concepts. After approximately five to six months, the client reviewed and accepted the application at MVP stage. I delivered a documented codebase with setup and technical guidance detailed enough for the client to install, run, understand, and continue the product independently.
Results
What changed
Accepted
Client-reviewed MVP
The client reviewed the completed system and confirmed it at MVP stage. · Shared outcome
5–6 months
Greenfield delivery window
I moved the product from early discovery through full-stack implementation, validation, and documented handoff. · My contribution
Independent
Runnable client handoff
The supplied setup documentation allowed the client to install and run the MVP without continued assistance. · Shared outcome
Leadership evidence
How I moved the people system
- — I facilitated discovery with a nontechnical founder and turned broad coaching ideas into a practical MVP scope and delivery plan.
- — I bridged domain expertise and engineering through sketches, paper calculations, incremental demonstrations, and client review.
- — I owned the engagement end to end while maintaining clear scope boundaries between an accepted MVP, a production deployment, and later product adoption.
- — I completed a handoff that transferred understanding as well as code, allowing the client to operate the MVP independently.
Technical evidence
How I moved the product system
- — Greenfield architecture spanning public-data collection, transformation, normalization, enrichment, storage, calculations, APIs, and an AngularJS interface.
- — A thin raw-ingestion layer separated from a dedicated transformation and enrichment pipeline.
- — Reconciliation of inconsistent names, identifiers, formats, incomplete records, duplicates, and cross-source relationships.
- — Domain calculations translated from coaching concepts and validated through unit tests, manual testing, and client review.
- — A runnable full-stack MVP supporting statistical search, lineup comparison, and play-planning workflows.
Technical footprint
Technologies and system areas
What I took from it
The lesson I carry forward
This project demonstrates my ability to enter an ambiguous, domain-heavy problem and turn it into a defined, working product. I moved from conversations, sketches, and paper calculations to a complete technical architecture and full-stack MVP, combining product discovery, data engineering, domain modeling, API and interface design, automated testing, manual validation, and technical documentation. It also reinforced an important principle of analytics engineering: the visible interface is only the final layer. Useful analytics depend on trustworthy inputs, explicit transformation rules, coherent data models, and calculations validated against both technical expectations and real-world meaning. The accepted MVP showed that I could solve difficult data problems independently while bridging a domain expert’s vision and the software needed to make it usable.
Related work · Data