One Day Stronger.

Why I built it

I have proximal hamstring tendinopathy (PHT) and left for a year-long sabbatical with 0 access to consistent PT. The PT options for someone on the go like I was either require insurance or are prohibitively expensive. I wanted PT that could be on the go with me and be flexible to adapt to my inconsistent lifestyle.

Beyond meeting my needs though, it made me question what solutions are available to people that don't have access to a consistent physical therapist whether it was location, expense, pain, or something else that served as a limiting factor for them.

How I thought about it before I built it

Definition. After the struggles I faced during my year abroad, I knew this was the perfect use case to focus on while I grew my AI skill set. The problem was real and personal, and beyond my own needs there were other people, those not just traveling, with a similar accessibility gap. Before jumping into anything, I knew the most important part of working with AI was building the right context, so I set to work with Claude on that foundation from the start. Putting my product hat on, we built out a product strategy and a PRD for what to build first. These documents became the foundation that everything else was built on top of and that every important decision below was pulled into.

Growth. When I began looking at this problem, I saw its opportunity across physical therapy as a whole. Most apps that exist today require insurance or are static guides written by therapists, which left a whole user group being overlooked. I took these ideas and worked with Claude to sort through why that was and what a realistic approach was. We ran through the application strategy and tightened to tendinopathies first, then other musculoskeletal injuries. Three risk areas drove the boundary: negligence (no diagnosis, no symptom interpretation), HIPAA-adjacent data handling (build toward it from day one to avoid a painful retrofit), and state PT licensing (stay clear of "practicing PT").

Scope. For MVP, I scoped the project down to just my use case, since meeting my own needs as a solution I would actually use was the cleanest way to do it. I wrote these down and refined them with Claude until I was able to say what was absolutely core and what could be thought about later. Claude and I then worked together to refine these into user stories.

Source integrity. The application needed to pull from clinical resources, not random internet sites. To keep budget accounted for and build small to start, workouts pulled from peer-reviewed clinical literature and clinical textbook content.

Working model with Claude. I worked with Claude in a management style, the same way I would scope a problem with an engineering partner. I set the scope, provided the context, had Claude ask questions until we were aligned, then we built. The LLM is a coworker I manage, not something autonomous.

How I built it

The stack is intentionally lean: React Native with Expo for cross-platform reach, TypeScript for type safety against the database schema, Supabase for backend and auth, and Groq for primary LLM inference with Gemini as fallback. Cost was an explicit architectural constraint from the start, so every choice mapped to free tiers.

I began with foundational project files (PRD, architecture, design system, dev guide, LLM contracts) so Claude had real guardrails and context. I brought in Claude Design once the foundation was in place to help shape the look. From there, I built feature by feature against a process I refined as I went: plan, confirm, implement, pause for manual testing, fix, commit, retrospective.

Iterations and lessons

The first attempt was JUST OKAY. Claude tried to build a huge user story in one go, and multiple cycles of errors followed which never got to the root cause. We solved this through smaller building blocks, iterating on our process, forcing root cause troubleshooting, implementing retrospectives, and making sure the LLM was learning as it went.

LightRAG → structured Supabase schema. RAG made sense when the scope was "all PT" because the source material was a deep sea of clinical literature. Once the scope tightened to tendinopathies with well-established phased rehab protocols, non-deterministic retrieval was the wrong tool. I rebuilt against a structured schema that gave me the reliability guarantees the clinical domain required.

Modeling Claude on the software development process changed everything. The more I shaped our working agreement to mirror an agile development cycle (planning, building, testing, retro), the better we worked together and the fewer errors we hit. Claude needed the discipline of the process as much as a human engineer would.

Lazy prompting comes with a high cost. There is a real urge as a human to give a quick feedback line and assume the LLM will figure out what you meant and fix the right thing. That rarely works, and the cost is real: token waste, the wrong fix, or fixing the symptom instead of the root cause. Good results require detail and problem-solving to build the right system together.

Recognizing a setup problem fast is the highest-leverage move. When something is off, the question is rarely capability. It is almost always the system around the LLM, and the longer you spend tuning prompts on a broken setup, the more cycles you waste before having to rebuild anyway.

Where it's headed

The app generates phase-appropriate PHT workouts I trust, and the growth is following my roadmap to support other tendinopathies and broader musculoskeletal injuries. I am the only user so far, and honestly, this doesn't yet replace my existing PT practice. The next step is expanding my user group so I can broaden my understanding of needs beyond my own, which opens the bigger product questions: how do I take this public, how do I think about monetization, what does the model look like for serving the user group that the current PT options leave behind. Claude and I have more to do to check those boxes.