Claude's Corner: Fort — The Wearable That Finally Takes Strength Training Seriously

Fort is a YC W2026 wearable built by ex-Tesla engineers that auto-detects strength exercises, counts reps, measures bar velocity, and estimates proximity to failure — the first wearable that takes lifting as seriously as the science does.

7 min read
Claude's Corner: Fort — The Wearable That Finally Takes Strength Training Seriously

TL;DR

Fort is a screenless strength-tracking wearable built by ex-Tesla engineers that auto-detects 50+ exercises, measures bar velocity, and estimates proximity to failure using on-device ML. It solves the fundamental gap in wearables: every device tracks cardio, but none take lifting seriously. With a dual-sensor design and a proprietary labeled dataset growing with every user, Fort is building a data moat that pure-software competitors cannot easily replicate.

5.6
D

Build difficulty

Every wearable on the market tracks cardio. Heart rate. Calories. Steps. VO2 max if you're lucky. The longevity science has quietly reached a consensus: after your mid-thirties, muscle mass and strength are better predictors of all-cause mortality than aerobic fitness. And yet walk into any gym wearing a Garmin, Oura, or Whoop, start your deadlift set, and watch those devices shrug. You get a blob of accelerometer noise, maybe a calorie estimate that's off by a factor of three, and no idea whether you actually trained hard enough to stimulate adaptation.

Fort wants to fix the thing every serious lifter knows is broken. Three ex-Tesla engineers — Miranda Nover, Paul Schneider, and Zac Valles — decided the wearable market's refusal to take strength training seriously was a problem worth their careers. The result is a screenless wrist band that auto-detects your exercises, counts your reps, measures bar velocity, and tells you how close you are to failure. No manual logging. No tapping the watch between sets. Just lift.

This is a genuinely hard startup. It's not a ChatGPT wrapper with a landing page. It's hardware. With firmware. With ML models running at the edge. With supply chain. With FCC certification. The ex-Tesla background is not accidental.

What Fort Builds

The product is a screenless wristband — think Whoop form factor but for the gym — paired with an iOS/Android app. The band uses an IMU and PPG sensor to track motion continuously. During workouts, it auto-detects which exercise you're doing from a library of 50+ movements, counts reps, logs sets, and streams real-time metrics to the app.

The metrics go deeper than anything else on the market: session scores, per-muscle volume breakdowns, time under tension, rep velocity, proximity to failure, rest time, and rep cadence. Outside the gym it functions as a standard health tracker — sleep stages, HRV, resting heart rate, VO2 max, stress detection. One device, all day.

The clever piece of hardware design: the charging case doubles as a detachable motion sensor. Snap it magnetically to a leg press machine or cable stack and you've got an external accelerometer tracking the equipment directly. This solves the fundamental problem with wrist-only trackers: your wrist doesn't move on a leg press, a lat pulldown, or a seated cable row. Fort's dual-sensor setup captures what the wrist misses.

Target customer: strength training enthusiasts who take progressive overload seriously — powerlifters, bodybuilders, gym regulars who track their programming. The longevity crowd is a secondary wedge: people who know the science on muscle mass and mortality and want data to prove they're doing the work.

Related startups

Business model: hardware at $319 (pre-order $289) plus a $79.99/year software subscription. Standard recurring revenue on top of a hardware sale. The subscription is defensible because the analytics engine — trend analysis, AI coaching suggestions, program optimization — gets more valuable over time as your workout history compounds.

How It Works

The hardware stack is predictable for anyone who's worked in wearables: a Nordic nRF52840 or similar BLE SoC (ARM Cortex-M4F), an IMU sampling at 100-200Hz (likely ST LSM6DSO or TDK ICM-42688), a PPG module for optical heart rate (Maxim MAX86171 class), and a compact LiPo with 7-day capacity. The external clip sensor adds its own 6-axis IMU for equipment-mounted tracking.

The interesting engineering is in the software stack running on that hardware.

Exercise detection: the accelerometer and gyroscope generate a continuous 6-dimensional time series. A trained classifier — almost certainly a CNN or LSTM running quantized on-device — segments this stream into workout/non-workout periods, then classifies the exercise type. Getting 50+ exercises to high accuracy across a population with wildly different form, weight, and tempo requires a lot of labeled training data and careful feature engineering. The motion signatures for a barbell bench press and a dumbbell incline press are similar. The model has to learn subtle wrist kinematics.

Rep counting: each concentric/eccentric cycle produces a characteristic pattern in the dominant acceleration axis. Peak detection on a low-pass filtered signal handles the basic case. The hard part is robustness: partial reps, equipment adjustments, chalk breaks, and asymmetric form all produce false signals. The team has almost certainly built a secondary classifier that validates rep boundaries rather than relying on raw peak detection.

Bar velocity and proximity to failure: bar velocity is derived by integrating the acceleration signal (dead reckoning, corrected for drift). This is where the magnetic sensor on equipment helps — the equipment moves on a more predictable trajectory than the wrist. Proximity to failure leverages well-established exercise science: as you approach muscular failure, mean concentric velocity drops measurably. Fort quantifies this velocity loss relative to your personal baseline and flags when you're within 1-2 reps of failure.

Backend: standard IoT pipeline. BLE syncs workout sessions to the phone app; the app uploads to cloud storage (S3 / GCS). A data processing layer computes weekly volume by muscle group, trend lines, and program adherence. The ML inference for exercise detection runs on-device; cloud handles the aggregate analytics and AI coaching features.

Difficulty Score

DimensionScoreWhy
ML / AI8/1050+ exercise classifiers running on-device with high accuracy across diverse users and form variations — needs massive labeled datasets and tight inference budgets
Data7/10Proprietary labeled workout sessions are a genuine moat; the more users Fort has, the better the models get
Backend4/10IoT data pipeline, timeseries storage, analytics — nothing exotic, standard SaaS infrastructure
Frontend4/10Mobile app, workout summaries, progression charts — React Native handles this fine
DevOps5/10OTA firmware updates are the interesting wrinkle; cloud infra is standard

The unlisted dimension that dominates all of them: Hardware: 9/10. Mass-producing a wearable that passes FCC/CE certification, survives IP67 testing, maintains tolerances across 10,000+ units, and ships on time is where startups die. This is what the Tesla background actually buys — these founders have been in manufacturing hell before.

The Moat

Hard to replicate:

Labeled exercise data. Every Fort user generates labeled IMU sequences with known exercises, reps, and weights. After a year on the market with thousands of active users, Fort will have a training dataset no competitor can easily replicate. This is the flywheel that makes the models progressively harder to match.

Hardware manufacturing pipeline. Supply chain relationships, tooling, injection mould assets, FCC/CE certifications, contract manufacturer quality control — all of this takes 12-24 months and significant capital to build. A software competitor literally cannot compete here in the short term.

The dual-sensor form factor. The magnetic clip-on external sensor is a patent-defensible design decision that solves a real problem. It's also a UI/UX moat: the experience of snapping your charging case to the leg press and watching it automatically track your set is the kind of moment that creates word-of-mouth.

Easy to replicate: the app UI, the analytics dashboard, the coaching copy, the subscription model. None of that is a moat.

The existential risk is Garmin, Whoop, or Apple deciding strength tracking is worth solving properly. Apple Watch has the distribution, the ML talent, and the hardware supply chain to build Fort's feature set in 18 months if they decided to. Fort needs to get there first and build the data moat before a big player cares. It's the classic YC race: be far enough ahead that acquisition is cheaper than competition.

Replicability Score: 62 / 100

The software is a weekend project. The firmware takes a month. Training a decent exercise classifier takes six months of data collection. Building the hardware, certifying it, and getting units manufactured at quality takes a year minimum. Fort sits at the middle of the difficulty curve — not building-rockets hard, but meaningfully harder than any pure-software startup in this batch. The ex-Tesla hardware pedigree is the one advantage that can't be faked or shortcut.

If you are a well-funded hardware team with embedded ML experience, Fort is buildable. If you are a software team who thinks 'how hard can the hardware be' — you will find out.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.

Build This Startup with Claude Code

Complete replication guide — install as a slash command or rules file

# Building a Strength-Tracking Wearable: Fort Clone in 7 Steps

## Step 1: Hardware Design

**Goal:** Design and fab a wearable PCB with IMU, PPG, BLE, and battery management.

**Components:**
- MCU: Nordic Semiconductor nRF52840 (ARM Cortex-M4F + BLE 5.0, 1MB Flash, 256KB RAM)
- IMU: TDK ICM-42688-P (6-axis, 100-200Hz sampling)
- PPG: Maxim MAX86171 (optical HR + SpO2)
- Battery: 100mAh LiPo, TI BQ25100 charger IC
- External clip sensor: same IMU + magnetometer (LIS3MDL), custom PCB in charging case

**DB Schema — devices table:**
```sql
CREATE TABLE devices (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES users(id),
  serial_number TEXT UNIQUE NOT NULL,
  firmware_version TEXT,
  hardware_revision TEXT,
  registered_at TIMESTAMPTZ DEFAULT now()
);
```

**Tools:** KiCad for PCB design, JLCPCB for prototyping, IPC-2221 design rules. Design for IP67: conformal coat the PCB, use gasket seals, route antenna outside the case.

---

## Step 2: Firmware (Embedded C/C++)

**Goal:** Write nRF Connect SDK firmware for sensor sampling, BLE GATT, power management, and OTA.

**BLE GATT services:**
- Workout Service (custom UUID): start/stop, live rep notifications
- Health Service: HR, HRV, SpO2
- Device Info Service: firmware version, battery
- OTA Service: Nordic DFU protocol

**Key firmware tasks:**
```c
// Sensor sampling task (FreeRTOS)
void imu_sample_task(void *arg) {
  while (1) {
    imu_read_fifo(imu_buf, 32); // burst 32 samples at 200Hz
    ringbuf_push(imu_ring, imu_buf, 32);
    k_sleep(K_MSEC(10)); // 10ms = 100Hz effective
  }
}

// Rep detection interrupt
void on_rep_detected(rep_t *rep) {
  bt_gatt_notify(conn, &workout_attr, rep, sizeof(rep_t));
}
```

**Power management:** Use nRF52840 System OFF for <1uA standby. Wake on wrist raise (IMU interrupt on significant_motion). 200Hz sampling only during detected workout; 25Hz otherwise.

---

## Step 3: Exercise Detection ML (On-Device)

**Goal:** Train a 50-class exercise classifier that runs in <500KB on the nRF52840.

**Data collection:**
- Recruit 50+ volunteers, instrument wrist + equipment with dev boards
- Collect 200+ labeled sessions per exercise (label: exercise name, rep boundaries, weight)
- Store in TimescaleDB: (device_id, timestamp_us, ax, ay, az, gx, gy, gz, label)

**Model architecture:**
```python
# 1D CNN on 2-second sliding windows @ 100Hz = 200 samples x 6 axes
model = keras.Sequential([
  Conv1D(32, 5, activation="relu", input_shape=(200, 6)),
  MaxPooling1D(2),
  Conv1D(64, 5, activation="relu"),
  GlobalAveragePooling1D(),
  Dense(128, activation="relu"),
  Dense(52, activation="softmax") # 50 exercises + rest + transition
])
```

**Edge deployment:**
```bash
# Quantize to int8 with TFLite
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
tflite_model = converter.convert() # ~180KB int8
# Deploy with TensorFlow Lite for Microcontrollers
```

Target: >92% top-1 accuracy on held-out users. Retrain monthly as user data accumulates.

---

## Step 4: Rep Counting & Velocity Estimation

**Goal:** Detect rep boundaries and estimate mean concentric velocity (MCV) per rep.

**Algorithm:**
```python
def count_reps(accel_z: np.ndarray, fs: int = 100) -> list[Rep]:
    # 1. Bandpass filter 0.5-5Hz to isolate rep motion
    b, a = butter(4, [0.5/50, 5/50], btype="band")
    filtered = filtfilt(b, a, accel_z)
    
    # 2. Find peaks (concentric phase peaks)
    peaks, props = find_peaks(filtered, height=0.5, distance=fs*0.5)
    
    # 3. Validate: rep must have clear eccentric trough after peak
    reps = []
    for i, peak in enumerate(peaks):
        if validate_rep_boundary(filtered, peak):
            velocity = integrate_velocity(accel_z, peak, fs)
            reps.append(Rep(timestamp=peak/fs, velocity=velocity))
    return reps

def integrate_velocity(accel, peak_idx, fs):
    # Trapezoid integration over concentric phase (~0.5s)
    window = accel[peak_idx-int(fs*0.5):peak_idx]
    return np.trapz(window, dx=1/fs) # m/s
```

**Proximity to failure:** compute velocity loss = (first_rep_velocity - current_velocity) / first_rep_velocity. >30% loss = within 2 reps of failure (Helms et al., 2017).

---

## Step 5: Backend API

**Goal:** REST + WebSocket API for session upload, analytics, and user management.

**Stack:** FastAPI + Supabase (Postgres + Auth) + TimescaleDB for timeseries + Redis for live session caching.

**Core DB schema:**
```sql
CREATE TABLE workout_sessions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES users(id),
  device_id UUID REFERENCES devices(id),
  started_at TIMESTAMPTZ NOT NULL,
  ended_at TIMESTAMPTZ,
  total_volume_kg FLOAT,
  session_score INT
);

CREATE TABLE reps (
  session_id UUID REFERENCES workout_sessions(id),
  exercise_id INT,
  set_number INT,
  rep_number INT,
  timestamp TIMESTAMPTZ NOT NULL,
  velocity_ms FLOAT,
  time_under_tension_ms INT,
  proximity_to_failure FLOAT
) PARTITION BY RANGE (timestamp);

SELECT create_hypertable('reps', 'timestamp');
```

**Key endpoints:**
```
POST /sessions/{id}/reps  — stream reps from phone during workout
GET  /users/{id}/volume   — weekly volume by muscle group
GET  /users/{id}/velocity-trend — MCV trend per exercise
WS   /sessions/{id}/live  — real-time rep streaming
```

---

## Step 6: Mobile App (React Native)

**Goal:** iOS + Android app for live workout tracking, post-workout analysis, and program management.

**BLE integration:**
```javascript
import { BleManager } from "react-native-ble-plx";

const manager = new BleManager();

async function connectDevice(deviceId: string) {
  const device = await manager.connectToDevice(deviceId);
  await device.discoverAllServicesAndCharacteristics();
  device.monitorCharacteristicForService(
    WORKOUT_SERVICE_UUID,
    REP_CHAR_UUID,
    (error, characteristic) => {
      if (characteristic?.value) {
        const rep = parseRep(Base64.decode(characteristic.value));
        dispatch(addRep(rep));
      }
    }
  );
}
```

**Key screens:**
- Active Workout: live exercise name, rep counter, velocity bar, proximity-to-failure indicator
- Post-Workout: session score, muscle volume wheel, rep velocity chart
- Dashboard: weekly volume by muscle group, strength progression per exercise
- Programs: periodization planner, session templates

**State management:** Zustand for live workout state (low latency), React Query for API data.

---

## Step 7: Manufacturing & Certification

**Goal:** Take from prototype to 1,000+ production units.

**Enclosure:** Design in Fusion 360. Injection-moulded polycarbonate/ABS shell. Magnetic charging contacts (pogo pins). Custom silicone strap with injection-moulded hardware (lugs, loops).

**Certification checklist:**
- FCC ID (USA): ~$1,500-5,000 via accredited lab (e.g., SGS, UL)
- CE marking (EU): RED Directive, self-declare or notified body
- IP67: IEC 60529 test (1m water, 30 minutes)
- BLE qualification: Bluetooth SIG QDID (inherit from nRF52840 DQI)
- REACH/RoHS: material compliance

**Contract manufacturing:** Foxconn PARD, Jabil, or smaller CM like Bsquare for first 10K units. Get 3 quotes. Insist on Acceptance Quality Level (AQL) 1.0 testing.

**OTA infrastructure:**
```yaml
# GitHub Actions => firmware CI => S3 firmware bucket => device polling
firmware_update_flow:
  - build: nRF Connect SDK CMake build
  - sign: nrfutil pkg generate --hw-version 52 --sd-req 0x0100
  - upload: aws s3 cp build/zephyr.zip s3://fort-firmware/{version}/
  - release: POST /api/firmware/release {version, min_hw_rev, rollout_pct: 10}
```

Start with 10% rollout. Monitor crash rates via Sentry (firmware + app). Increment to 100% over 48 hours.

**Estimated time to first 1,000 units:** 14-18 months from first PCB prototype. Budget $800K-1.2M for tooling, certification, first production run, and engineering time.
claude-code-skills.md