Our focus wasn't to redesign the product from scratch.
The original UX already reflected how performance teams actually work, so we preserved the existing product experience while rebuilding the underlying infrastructure.
Real-Time Data Infrastructure
We replaced static datasets with a structured ingestion architecture capable of receiving information from multiple sources.
The system was designed around:
GPS and wearable data
HRV and recovery metrics
Sleep information
Wellness submissions
Training-load records
External performance systems
Each integration required validation, normalization, and error handling so inconsistent or incomplete data wouldn't compromise the platform.
Live Performance Calculations
Static calculations were replaced with dynamic processing.
The platform could evaluate:
ACWR
Training-load trends
Readiness scores
Historical performance
Rolling training windows
Individual athlete baselines
This allowed performance metrics to evolve with the athlete instead of remaining fixed to predefined values.
Intelligent Performance Insights
We replaced simulated recommendations with a data-driven inference layer.
Insights were generated based on actual athlete conditions and predefined performance rules.
For example, when training load increased significantly while recovery indicators dropped below an athlete's baseline, the system could surface an appropriate risk signal rather than displaying a generic recommendation.
Role-Based Access
Athliq required different users to work with different levels of information.
We implemented role-based access so that:
Performance Directors could monitor squad-level performance
Sport Scientists could analyze training and performance metrics
Physiotherapists could access injury and return-to-play information
Coaches could focus on readiness and daily training
Athletes could access relevant individual information
Access restrictions were enforced at the system level rather than simply being controlled through the interface.
Monitoring & Reliability
Production systems need visibility when something goes wrong.
We introduced logging and monitoring across data ingestion, calculations, and system events.
The platform could identify issues such as:
Missing data
Delayed integrations
Invalid records
Calculation anomalies
Stale data sources
Application errors
This helped prevent outdated information from being presented as current performance data.
Athliq transformed a fragmented performance-monitoring workflow into a centralized platform.
Instead of moving between multiple browser tabs, spreadsheets, forms, and communication channels, performance teams could access their core athlete information through a unified dashboard.
The platform provided role-specific views, continuously updated performance information, historical context, and actionable signals from integrated data sources.
More importantly, it created a shared data layer for coaches, sport scientists, physiotherapists, and performance directors.
The product evolved from a concept-validation prototype into a production-ready performance intelligence platform.
What Made the Project Interesting
The biggest challenge wasn't simply building another analytics dashboard.
It was translating real-world sports performance workflows into reliable software infrastructure.
The original product concept came from someone deeply familiar with the domain. Our role was to preserve that domain knowledge while introducing the engineering foundations required for scalability, reliability, security, and live data processing.
The result was a system designed around the questions performance teams actually need answered—not simply around the data available to them.
Athliq Today
Athliq has evolved into a multi-role sports performance platform supporting professional and university-level performance environments.
The platform brings together data from multiple sources and transforms it into role-specific performance insights, giving teams a centralized environment for monitoring readiness, training load, recovery, and athlete progression.
From a coach's notebook and fragmented data sources to a scalable performance intelligence platform.
I've been quietly building landing page templates. Six are out today, each with its own brand, its own type pairing and one interaction it's built around:
→ Aurel: a skincare brand with a WebGL serum drop that bulges toward your cursor
→ Ferro Type: a type foundry where the hero word bends its weight and width under the pointer
→ Meridian Expeditions: contour maps that redraw themselves as you switch routes
→ Oda: an architecture studio whose timber cabin draws itself, with a live sun study
→ Relay: a dev tool where the editor types a workflow and the run graph executes it live
→ Signal: a mission-control SaaS with a live infrastructure graph that contains threats as they flare
Built to be edited with AI. Every template ships with a README, a DESIGN.md and an AGENTS.md, so Claude, Cursor or whatever assistant you use changes it the way it was built, not the way it guesses.
Ferro Type is the one I would open first. Bending a variable font under the pointer re-lays out the text every frame, which is a much bigger bill than it looks, and stepping the weight in a few fixed increments is usually what keeps it smooth on a laptop that is not plugged in....
So I Recently rebranded my upcoming AI Agent Harness from "Crank" to "Pixie" which is the name of my cat. Do you think it was the right decision?
Which one do you prefer? Crank or Pixie?!
Check it out here: pixie.ecnivs.com
#FreelancerLife #AIHarness #FrontendDesign #AIAgent #ArtificialIntelligence #WebDevelopment #Design #TasteTest
Pixie gets my vote too. Naming it after your cat makes it memorable, and it feels a lot friendlier for a tool people trust with their code. Nice rebrand.
A competitive online chess platform combining real-time multiplayer gameplay, tournaments, player rankings, payments, staking infrastructure, and a comprehensive in-platform economy.