Turn a domain expert’s idea into a product another person can actually run
An early coaching concept became a client-accepted full-stack MVP through product discovery, public-data transformation, calculation design, testing, and documented handoff.
Accepted
Client-reviewed MVP
The client reviewed the completed system and confirmed it at MVP stage.
5–6 months
Greenfield delivery
The project moved from early discovery through architecture, implementation, validation, and handoff.
Independent
Runnable handoff
The supplied documentation allowed the client to install and run the MVP without continued assistance.
The real situation
The project began with an aspiring founder, a strong vision for college basketball analytics, and no prototype, architecture, or defined implementation plan. The product needed to help coaches explore statistics, compare lineups, evaluate players, and support play-planning decisions.
The visible interface was only the final layer. Public roster, box-score, play-by-play, shot-location, and lineup data varied across sources, while the coaching concepts themselves began as conversations, sketches, and paper formulas.
What the business was carrying
The visible problem
- The founder needed a practical MVP scope and technical roadmap.
- Public data sources used inconsistent names, identifiers, formats, and record structures.
- Coaching questions had to become calculations that were both computationally correct and meaningful in basketball terms.
Why the obvious fix was not enough
The harder system underneath
- Collecting data was easier than making several sources agree.
- The product required domain discovery and technical implementation to evolve together.
- The final handoff had to be understandable and runnable without continued dependence on me.
The MVP foundation
The interface became useful only after the data and domain logic became coherent
The product connected founder discovery, raw public data, transformation rules, calculations, APIs, interface workflows, and an independent handoff.
Before
- Broad founder vision
- No prototype or architecture
- Inconsistent public data
- Coaching logic living in conversations and paper calculations
After
- Client-accepted MVP
- Coherent full-stack architecture
- Validated analytical calculations
- Independently runnable handoff
- 01
Discover
Define decisions the product should support
Translate coaching questions into workflows, data needs, and calculation behavior.
- 02
Collect
Retrieve raw public information
Gather rosters, box scores, play-by-play, shot locations, and lineup data.
- 03
Transform
Reconcile and enrich the records
Normalize identifiers and formats before calculations depend on them.
- 04
Use
Expose analytics through a working MVP
Provide search, lineup comparison, and play-planning workflows with a documented setup.
What changed
Decisions that moved the work forward
- 1 Define
Turn the vision into an MVP
Regular conversations, sketches, paper calculations, and demonstrations clarified user workflows, data requirements, calculations, and scope.
- 2 Transform
Separate collection from interpretation
Node.js collectors gathered raw data while a dedicated layer reconciled identifiers, formats, missing values, duplicates, and cross-source relationships.
- 3 Model
Create one analytical foundation
Normalized and enriched records entered MongoDB, calculation rules were implemented, and Express APIs exposed usable information.
- 4 Deliver
Build, validate, and document the complete product
I created the AngularJS interface, unit tests, end-to-end validation, and setup documentation for independent client operation.
What the business gained
Results beyond the implementation
01
The broad idea became a defined product with an explicit technical architecture.
02
Inconsistent public data became a coherent model supporting search, lineup comparison, and play planning.
03
The client received both the code and enough operating knowledge to continue independently.
What this proves for a client
The scale may change. The systems judgment still transfers.
A useful MVP is not the smallest pile of features. It is the smallest coherent product that proves the difficult assumptions, gives the user a real workflow, and leaves a clear path for the next stage.
Technical footprint
Evidence and boundaries
- ✓ Sole developer
- ✓ Approximately 5–6 month greenfield engagement
- ✓ Client-accepted MVP
- ✓ Independent documented handoff
- ✓ Unit and manual validation
The client, project, source identities, formulas, schemas, real records, and identifying implementation details remain confidential.
Visual recap
From public sports data and paper calculations to a runnable coaching MVP.
Related practical guide
Turn Data Into a Business Capability
Read the guide →A practical next step
Turn the idea into a testable product shape
A discovery and architecture sprint can define the user decisions, data, assumptions, and smallest coherent MVP before the build expands.