GTM Sauce

Symmetry · B2C · gym workout tracker

Start each test from a real user problem and A/B test for two weeks

Credited for reaching $160K/month; most tests don't move the needle

Workedexperimentationfeature-development

What they did

Start from a problem, not a solution: What problem am I solving? How do I know it's real? Then list solutions/hypotheses, estimate how much each moves the target metric, define guardrail metrics, and A/B test control vs new version for at least two weeks before analyzing. Maintains 'Evelyn' (Experiment Velocity Engine List) database of experiments sourced from user interviews; product experiments in PostHog, paywall tests in Superwall. Evolved from building what founders wanted (terrible) to building user requests (mediocre) to this.

What happened

Credited as the main reason the app reached $160K/month in a year; most tests don't move the needle

In their words

How I Built This $160K/Month Gym App

Play from 5:27

… to building. And when we started digging into it, I thought it was super cool because you got this app to $160,000 a month within one year. And that's like really, really fast. Like usually you'll see, you know, maybe get to 30 or 50 K within a year. You did it super fast. And I think one of those reasons was sort of you had this sort of different approach to building that you shared with me where things just kind of started working right away.

5:27

So could you share with me that approach to like how you knew what to build, what features to build? Yeah, so we went through three different phases when building Symmetry. First, we built what we wanted. Terrible idea. Second, we built what users wanted, like directly from feedback requests. Mediocre. And now we approach a methodical and scientific way of actually building useful things. Okay, yeah, so I agree. I mean, I see a lot of people that go and just start building stuff. Maybe they ask their AI tool about what to build, or maybe they build based on instincts.

5:58

But yours is a little different. Could you dive a little bit more into what you mean by that? Yeah, so people normally are incorrect about what is important to build and what is not important. Let's say you build a dark theme or a light theme, this may affect like 2% of your daily active users. Whereas if you api-test the paywall, it's going to affect a lot of users in a radical way. That's why there are like even softwares just to api-test at …

… how do you go about A-B testing two different things? How do you track that? How do you think about it? Okay, first, you're not coming from a solution place, you must come from a problem space. So coming up with problems. And then after you go for the solution, here you come up with different hypotheses, different solutions, and you design experiments to test these hypotheses. So first, what problem am I solving? How do I know it's real?

11:20

We must know if this is happening. And then what's the solution and the hypothesis? How much will each hypothesis move the metric? Are there any guardrail metrics I should watch out? And then also very important, you must A-B test everything. You have your control version, the version of your app currently, and the new version being A-B tested. And after at least two weeks of running the experiment, you then analyze the data and really know what is happening to the users. For example, this is what we call Evelyn, Experiment Velocity Engine List in your numbers. Here we have all of our A-B test tracks. This is a database that comes from user interviews.

11:51

it's user interviews that show us the user problem then we do the hypothesis and then we do the experiments these experiments are being tracked in postdoc so here we track everything and we can see how everything is running for example this was an experiment i mentioned earlier about the page you see after the onboarding where you see your workouts you see here we tested two different variants apart from the control and they moved nothing the …

… a quick thought, which was like, I didn't start building anything until all these AI coding tools came out. And I definitely fall into the trap of like, oh, that would be cool. That'd be cool if it existed without any information. And so listening to you talk here, I'm like, OK, there's a lot of good things to keep in mind. Cool. Let's switch topics a little bit. So you talked to us about all the things you analyze and all the tools you use.

12:57

Maybe just walk us through the tech stack you've used to build this app or the tech stack and tools you use on a daily basis to run this app. Well, obviously I use, me and my team, we use Cloud everywhere. We love to use Cloud with MCPs and we connect to this analytics tool like PostHoc or SuperWorld or RemedyCat with MCP and see all our data from there. I also use Whisperflow a lot. I like to speak with my computer and that way I'm faster than typing. Also for A-B testing, the payables, we use SuperRule. They have really good experimentation tools. For A-B testing, we use PostHoc.

13:27

Then we use Notion to track all of our documentation and Slack to speak with the team. And that's pretty much it. Okay, thanks for sharing TechStack. I'm also curious, we've been talking all about your app here. Could you just give me a quick demo of your app that makes over $160,000 a month? Yeah, so our app we try to make it really simple. So the first thing you see when you come is just like your plan to work out. You click on the plan and you …

Get tactics like this every Monday

New tactics from the week's founder interviews, each linked to where it was said.

More from this episode

Tags: ab-test, hypothesis, guardrail-metrics, user-interviews, paywall-testing