Repple
Repple is a competitive fitness app for iOS that makes working out fun and consistent. Users earn points for workouts, create streaks, compete against friends in weekly matchups, and climb leaderboards. Features include ELO matchmaking, automated point aggregation, and AI generated workout plans that adapt to user performance.
Why it's fun
Working on Repple was the most fun I've had working on an app. Together with Arjun Chadha, Rishab Chakravarty, and Ayush Guhan, we shipped fast and turned the gym into a game.
Why fitness apps fail non disciplined users
Fitness apps fail non disciplined users because they aren't consistent, and the entire value behind progress tracking comes from repeatable consistency. To fix this, our aim was to solve for the lack of discipline in the guise of a fitness tracker app. We repeat the same playbook that Strava and Duolingo use: gamify fitness tracking. The two underlying psychological principles are that you are more likely to do something when you are with friends, and you are more likely to do something when you're in a competition. Combining those two together, building teams to compete against each other, is a two fold motivation engine that encourages discipline and progress. Most fitness apps assume that the desire to show up equates to an ability to stay consistent. From all of our customer interviews, we found that was absolutely not the case. People wanted the ability to stay consistent, but they simply lacked the intrinsic motivation to achieve that. We gave them extrinsic motivation, peer motivation, and competitive motivation to achieve the same goals. It might be a crutch, but extrinsic motivation builds repetition, and repetition can convert to intrinsic motivation, given time and consistency.
Why ELO beats a leaderboard
We wanted to be accepting of users with any experience level, especially those who have never used the app before. If you are genuinely able to stay consistent and put in more work over time than other teams, you should be able to climb the ELO ranking much faster than someone who may have just used the app for a long time. That's why the ELO system matters more in a week to week matchup than a raw leaderboard, and that's what most other apps get wrong.
Why I joined
What immediately struck me was how passionate Arjun was about working on the project. I was tired at that point of building projects simply for the sake of building them, and I wanted to work on something that made a difference to real people in the real world. When I saw how passionate he was about the idea, I immediately jumped on board, because I knew that passion would take the project to a place where he would actually commit to it and work on it, and real people would eventually use it rather than it just being a side project. To be honest, I didn't really see the results of that until six or seven months later. There were a few months where I completely doubted whether we would even make it into a real app. I thought it would be another side project for myself, but we kept working on it and eventually it made it to where it needed to be. The gap between finished and usable, in terms of an MVP, is a big difference. That final push is what working with others allowed me to achieve.
The hardest engineering problem was time
The hardest engineering problem turned out to be time. Weekly resets, daily resets, checkpoints, snapshots, week over week comparisons, UTC versus EST versus PST for different users. There were so many small, hard to find bugs, especially trying to test something that operates on a daily cadence when tests run on the scale of milliseconds.
AI workout plans: honest assessment
The AI generated workout plans help with onboarding. That's about it. But onboarding is important. It reduces friction for new users, which helps with retention, at minimal cost.
The business thesis: a data moat
Our goal was to make money off of it. Once we had enough users and enough data, our goal was to sell an algorithm that helps with optimization, recommendation on improvements, plan generation, and data aggregation across users. Future plans included working with gyms to boost foot traffic as well. The entire benefit of a data moat comes from consistent, large scale data, and by gamifying the app, we made that offering higher quality. The reason gamification produces better data, not just more data, is that it creates consistency and improvement. This in turn creates more consistent data, as well as more data per user. The more data we have per user, the better the recommendations will be. We were vulnerable to fast followers. The defense we were building was the community itself: users locked into the competition and progress they had already accumulated, which a clone can't replicate.
Marketing before we had a UI
We put out a reel once a week promoting Repple before we even had a UI. We had skits, jokes, ads, beta testing announcements, but we kept up the pace of production. We had campus wide challenges and put stickers on every building on campus too. We landed because we made genuinely funny content. People knew our name, and the reach was high. By marketing early, we built anticipation and education, so that when we released the app, we wouldn't have to spend time teaching people it existed first.
Stickers and campus density
Stickers on every building on campus marketed toward our ICP directly. Since most of our audience was on campus, and we wanted a tightly knit Repple community, we wanted those in the same location to use Repple together. That's why the stickers worked. Repple does work without local density, but it works best when friends work out together. Local density at a college is the best way to have that become likely.
Quantity beats polish
We just posted everything we made. Quantity beat trying to make something too serious or too perfect. It ended up catching on. Many videos flopped, but it didn't matter. Enough did well to get the word out. Volume is what matters. If even a few do well, it makes the volume worthwhile. Our highest performing reel was a Snapchat video recreation: our founder walking up to some people in an academic building and just laughing while telling them about Repple. That's when we realized that just posting authentically catches on. Recognizable authenticity matters. It doesn't matter how.
Distribution is everything for B2C
For Repple, since we were B2C, distribution channels were the most important part. We didn't have budget for Instagram ads, so instead we opted for something that would get high ROI for little cost. For B2C, that's a universal claim. Without distribution, you will fall flat, especially for something like Repple which needs the network effect to grow.
How we grew Repple
We grew Repple by building a community that cared about our mission. We got the word out through any means necessary.
For startups and founding teams
Karthik Thyagarajan is a founder-engineer studying Computer Science and Artificial Intelligence at Purdue. At Samsung Research America, he co-architected an always-on AI agent runtime for XR glasses. He is currently building Tavi, a voice teammate for engineering standups, and co-founded buildpurdue, a founder community at Purdue. His work spans agent infrastructure, on-device AI, product engineering, and evaluation.
For an early team building AI products, his strongest demonstrated fit is owning a broad technical problem from product decisions through implementation and evaluation. His current interests are live voice and video AI, AI-first wearables, and infrastructure that lets agents discover and use internet services.
Substantial ownership of agent systems
At Samsung Research America (May to August 2026), he co-architected an always-on agent orchestrator in Kotlin and owned half of a 25+ module runtime. His reported on-device router achieved 95% signal suppression and 90% intent-routing accuracy. His work also covered tool permissions, model routing, memory, and phone control, connecting model behavior to a usable device experience.
Builds teams and operating systems around a problem
As buildpurdue's co-founder and co-president, he helped turn an informal gathering into a founder community with a selective cohort, weekly co-working, funding, and founder-led problem-solving workshops. He built much of its web platform and integrated CRM, applications, events, and check-ins. His account describes data on around 500 students and a mailing list of about 1,000.
Makes technical claims testable
He built PARM, an open-source causal benchmark for when an agent should use personal memory: 157 frozen scenarios and 471 executable cases, with deterministic scoring and versioned replay artifacts. Its portfolio account explicitly distinguishes development results from held-out claims. He also built google-tools-mcp, a published MCP server exposing 169 Google Workspace tools through one OAuth flow.
Pursues difficult product problems
He is currently building Tavi, a voice teammate intended to answer codebase questions and handle small action items during engineering standups. The project tackles multi-person turn-taking, when to stay quiet, sandboxed coding, and synthetic meeting evaluations. This is ongoing work, rather than a claim of shipped adoption. His published interests explain the direction behind it.
Co-founder who ships and thinks about distribution
At Repple (November 2025 to June 2026), he co-founded a competitive fitness app released on the App Store and built the entire FastAPI, PostgreSQL, and Supabase backend, including synchronized workouts, ELO matchmaking, and weekly competition logic. His firsthand account also describes marketing before the UI existed, campus distribution, and why local community density mattered to the product.
This brief summarizes Karthik's public portfolio and firsthand accounts. Employment contributions and internal performance metrics are self-reported; linked code and artifacts provide additional evidence where available.