Publicly documented
The engineering account describes the architecture, permission boundaries, training-history model, and development practices. The implementation descriptions are author-reported; the application source remains private.
The defining project · Sports Performance Platform
The decisions behind
Sports Performance Platform.
I’m building software that connects coach planning and review with an athlete’s training, readiness, and development. The work is as much about the meaning of the information as the interface that presents it.
The problem & my responsibility
Connect the work.
Keep the context.
Coaches need to plan, understand athlete context, and review what happened. Athletes need to know what is assigned, carry it out, and see their progress. SPP’s product goal is to connect those responsibilities through a shared view of training and development.
My work spans product direction, the Coach Portal, the Player experience, backend APIs, data modelling, and permissions. I’m responsible for connecting those parts to the workflows they serve.
The platform is in development. Public access and launch timing have not been announced. This case study focuses on selected decisions and published previews.
The workflow
From team context
to planned work.
The overview brings readiness, availability, and recent changes into a coaching view. Assignments brings planned training, schedules, and completion status into focus. Together, these screens show how the Coach Portal presents context alongside the work that needs attention.
The Player experience addresses the athlete’s side: assigned training, session execution, readiness, and progress. Both images below are Coach Portal views.
Decision 01 · Training history
A training plan can change. An athlete’s history shouldn’t.
A coach needs to revise future programming without changing the record of an athlete’s completed session. If the plan and the result lose their distinct meanings, reviewing past work becomes less reliable.
The choice: separate prescription from performance.
SPP stores prescribed exercise data separately from performed results. The public engineering account describes completed results as historical records that remain separate from later programming changes.
Prescribed
What was planned
Future programming can be revised.
Performed
What happened
Completed results retain their historical meaning.
The reason is practical: a change to what comes next should not silently redefine what already happened. This distinction makes the responsibility of each record explicit and gives the product a clear rule for preserving training history.
This is a documented implementation decision. The published account does not include an executable test or a before-and-after record that independently verifies the behaviour. The comparison above explains the model; it is not a test result.
Decision 02 · Organisation & permissions
The right context starts with the right access.
SPP supports organisations containing teams, coaches, and athletes. An athlete completing assigned work, a coach managing a team, and organisation staff each need a different scope of access.
The choice: enforce authority behind the interface.
The public engineering account places authorization in the backend, with explicit organisation and role context. It also distinguishes organisation-level responsibilities from staff working within assigned teams.
The reason is straightforward: access should not depend only on what a screen displays or hides. The practical consequence is that permissions belong in API authorization, data queries, and application workflows as well as the interface.
The public material describes that enforcement; it does not publish cross-organisation or role-scope test results. These descriptions are not a security certification.
Evidence & current status
What this work establishes.
Published and checked
The two Coach screenshots are authentic published development previews. Their downloaded files were verified against the pinned public repository. That establishes image provenance, not application behaviour.
Still to validate independently
The public material does not provide executable application tests, a verified end-to-end workflow, or measured user and business outcomes. Screenshots and descriptions alone do not establish those results.
SPP remains in development. These screens use fictional demonstration data, and pictured features may change before release. Public access and launch timing have not been announced.
Let’s start a conversation
Have a project or
opportunity in mind?
Get in touch about a role, a product, or Sports Performance Platform.