Why we built Classes

Classes shipped in our first year as a "complete the coaching offer" feature. Coaches who ran 1-on-1 sessions could also run small group classes through the app: a single program assigned to multiple trainees, scheduled at fixed times, shared check-ins.

The pitch made sense on a whiteboard. Most coaches eventually wanted to run groups. Teshape would meet them where they were. Classic platform-thinking.

What we learned in the data

Ten months in, the data was uncomfortable:

  • 8% of weekly active coaches used Classes. The other 92% never created one.
  • 30% of inbound bug reports touched Classes code paths. The feature was a shared dependency with 1-on-1 sessions, so any Classes bug had risk of leaking into the core experience.
  • 15% of feature-request volume was Classes-related. The users who used it wanted more from it. The cost of doubling down on a feature 8% of users touched was indefensible.

The removal sprint

One week, three goals: communicate the removal to the 8% who used it, migrate their existing classes to multi-client templates, delete the code paths cleanly.

Day 1: email + in-app notice. Day 2–3: migration script. Day 4–5: code removal across mobile, web, and core. Day 6: regression testing. Day 7: ship.

The downstream simplifications

Removing Classes simplified a long list of features that had been carrying a "what if this is a class" branch. Scheduling, notifications, check-ins, billing, search. Each of those got 20–40% smaller in code. The shipping velocity on every remaining feature went up.

Active coach engagement went up 12% the following month. The narrative reading is that the app got faster and the path to value got clearer. The data reading agrees. Subtracting a feature is almost never the obvious move and is almost always the right one.