SWYM and its Founders
Our team created SWYM, an app that integrates AI and pose estimation to analyse swimming techniques through videos filmed on phones. The prototype tracks a swimmer’s body frame by frame to offer personalised technique recommendations along with drills for improvement.
Early on, our team decided to dive in and conquer our tasks based on our strengths. One teammate framed the problem and its opportunity and built the prototype; another designed the business model and assessed SWYM’s defensibility; meanwhile, one handled the financials. My role started where prototyping ended, exploring the question: so, what comes next? How do we measure and test whether SWYM can withstand the tides once it is out in open water? Which guardrails are crucial before real swimmers use it? Why would swimmers trust an AI app, and what can it offer that a professional coach cannot?
Of everything SWYM has taught me, the biggest takeaway was not how far we could swim, but knowing when it would be smarter to turn back.
Testing the Waters within Swimlanes
Designing SWYM’s testing phase was an iterative process that focused on determining how our idea would actually help swimmers. Developing a strategy here was where I had to make significant decisions, starting with what we should test in the first place. The initial draft leaned toward testing our prototype, but after collective feedback from the team, we decided to reroute. We agreed that testing the prototype would indicate how accurately the underlying AI model could estimate swimmers’ poses, and not whether SWYM helps athletes swim better. Therefore, our new approach was to test the live app and design an evaluation strategy that would run once SWYM is accessible to swimmers. Then, I suggested conducting an experimental test between two sample groups from a student club (one using SWYM and one without), where a professional coach would blindly judge the two groups’ technique. With limited evidence, we presented targets rather than results, and chose to frame the test as a pilot.
As consumers, we tend to see successful companies as the ones that keep pushing forward. However, this project changed that view for me, because some of the most important decisions my team made were about when we should stop. In the test we proposed, we chose to clearly define stop signs before receiving any sort of data, such as no visible improvements or swimmers reporting pain. Initially, this felt like undermining the progress my teammates had worked hard on. Over time, I realised that a test that cannot fail is just a glamorised demo. Deciding on stop signs in advance safeguards against escalation of commitment. Yet, these signs only indicate when to leave the pool, not how to keep swimmers safe while they are still in it.
Following that, I looked closer at our swimlanes, the guardrails that keep swimmers safe while SWYM is being tested. I realised that two of them were not as solid as they first seemed. The first was our “no medical claims” disclaimer, which seemed to protect swimmers but, in actuality, protected SWYM. A beginner with a sore shoulder would likely still follow a drill, despite what our terms say. Hence, it was backed up with a pain flag that stops drill advice, refers swimmers to a physio, and has a coach review the case. The second issue concerned filming the videos themselves. We overlooked the fact that a public pool is full of other swimmers who never agreed to be recorded, which is problematic under GDPR. Processing this footage would mean handling personal data. This led us to include automatic bystander blurring as part of the solution. Both cases showed me that swimlanes only work when they are centred around the swimmers they are meant to protect, and not just the business.
Swimming in Synchronisation
Navigating these waters as a team of four taught me that staying in synchronisation matters as much as moving fast. Dividing the project by our strengths made us more effective, but when four people write slides in parallel, numbers start to drift. Ironically, it was the same problem I raised about SWYM itself, as people lose trust when what they see does not match what was promised. What kept us aligned was checking each other’s work. When a teammate questioned the misalignment in the quoted coaching price, we directly referred back to our source list. Although we had someone checking for consistency, agreeing on one shared figure from the start would have prevented the numbers from deviating, rather than forcing us to catch them afterwards.
Demo Day gave us insight into how people responded to SWYM outside our own lane. Even though the event took place after our pitch deck was already submitted, the feedback we gained was helpful. When rotating around the lecture hall, we heard ideas from other teams ranging from hospitality to healthcare to legal compliance. What I noticed was that they did not use AI to replace people, and the strongest ideas used it to make existing jobs easier and smarter. This was also exactly what SWYM aimed to accomplish, and what the course has been pointing towards all along.
When other teams approached our table, I was pleasantly surprised by how much SWYM resonated, even with people outside our target market of triathletes. One person wanted to do an Ironman on a tight budget, which fit our tiered pricing plan perfectly. Others indicated that they swam for fun and had never thought much about technique, or had one specific stroke they wanted to fix. Our initial plan for SWYM was catered towards triathletes, but because it learns from each swimmer’s individual progress, it could technically serve any swimmer. Looking back, these conversations are not necessarily proof of demand, but if we had gained this feedback before submission, I would have widened our experimentation and testing beyond aspiring athletes. That is the first thing I would change in our testing.
Beyond the Shallow End of AI
It is easy to assume that access to AI is a competitive advantage, and working on SWYM showed me why that is rarely true. In the shallow end, every AI sports app is similar, as the underlying tools are openly available and competitors already offer AI swim analysis. What sets one apart goes beyond what the app can do. When our team was going back and forth between directions, we agreed that the deciding factor should be which option would build a learning loop. Every recording, coach check, drill recommendation, and fixed fault is a building block for a solution that competitors cannot simply copy. This also made me realise that AI is not meant to reinvent the wheel. In our case, swim coaches exist, and people with the means can book a training session. The uncharted waters are everything in between, starting with the unmonitored swims where faults are repeated stroke by stroke. AI does not replace the coach, but dives in when a coach cannot. This only works if swimmers trust advice they cannot verify themselves, which is exactly where my work on testing and guardrails became essential.
Knowing how far to swim matters, but knowing when to turn back matters more.
