Sparklift: A Training Log Built as a Card Deck

A workout log you run with one thumb. One exercise per card, reps and weight in two taps, rest countdowns between sets, and a trainer summary a coach can read in ten seconds. My own product at sparklift.si: product owner, designer, and full-stack builder.
Year
2026
Scope
Product strategy, Data architecture, Full-stack development, Brand identity, Exercise illustration system, Pricing and go-to-market
Timeline
MVP in one day, then weekly releases
Prototype Snippit
Preview
Plus icon
Sparklift landing page: Lift like you scroll. So you can sparkle. With the workout card player and rest countdown

Make or Break:

The Card Is the Product

I coached competitive gymnastics for years and I lift with a trainer now. Every workout app I tried was built for a desk, not a gym floor. Small text, spreadsheet rows with tap targets the size of a grain of rice, and a flow that assumes you have both hands free and a strong signal.

In the gym you have one thumb, sweaty hands, and about forty seconds between sets. That is the constraint. So the product is a deck of cards. One exercise per card. The move is drawn, the amount is large, and the next action is one tap. Rest is its own card with a countdown. If you stop at card six, card six is saved.

Sparklift is my own product, built on the same stack I build for clients: Lovable, React, and Supabase, with a Notion spec of record and every decision logged as it was made.

Sparklift sign-in screen with Continue with Google and the pink and orange gradient button
Mechanism 1:
A Schema That Will Outlive the MVP

Problem. Most vibe-coded apps get the data model wrong on day one and spend every later week paying for it. A workout log looks simple until you need history by exercise, personal records, partial sessions, and a food diary that shares the same user.

Mechanism. The schema came before the screens. Workouts hold ordered cards. Cards reference exercises. A session is a timestamped run through a workout, and every set is its own row tied to that session, so a run that ends early is still complete data. Row-level security keeps each account's data to itself from the first commit.

Product expression.

  • Workouts, cards, exercises, sessions, and session sets as separate tables with clear ownership
  • Partial sessions saved as first-class records, with an End workout action instead of an abandoned state
  • Personal records computed from history and surfaced as a badge on the card the moment you beat one
  • Google sign-in and email auth on Supabase, with per-user row-level security
  • Room in the schema already for the food diary, progress photos, and Oura data
Mechanism 2:
Designed for the Floor, Not the Desk

Problem. Gym conditions are hostile to interfaces. Bright lights, slow Wi-Fi, one free hand, and a user whose attention is on the bar.

Mechanism. Every decision on the card was made for that moment. A dark screen with the pink and orange brand gradient reserved for the one action that matters. Numbers at 30px with plus and minus steppers so the keyboard never opens. Anatomical illustrations in a matte 3D style on black, with more than one frame where a move needs it and bare feet so loading through the heels is visible. Branding kept to a short splash and a mark, because the video that looks good on fiber does not load on gym Wi-Fi.

Product expression.

  • One card per exercise with the illustration, the prescription, and last session's weight
  • Rest cards with a countdown ring between exercises
  • A trainer summary in coach shorthand: sets, top weight, PRs, workouts this week
  • Export to Notion as a clean text block, plus a log for walks and other activity
  • Monthly, yearly, and lifetime plans from $9 a month with Google sign-up, priced against Hevy, Strong, MacroFactor, and Fitbod
Mechanism 3:

Outcomes & Signals

What Changed

  • A working product at sparklift.si, from spec to first logged workout in one day.
  • A data model that supports history, personal records, and partial sessions without a rewrite.
  • A brand system built in the same session as the product: the eye mark, the gradient, the silver type, and the illustration style.
  • A pricing decision grounded in the current market, published on a landing page with sign-up live.
  • A repeatable pattern for shipping a client's software product in the same stack, with the same spec and decision log.
No items found.

This system reflects real operational constraints, tradeoffs, and scale decisions. I’m always open to discussing the thinking behind it.

More projects.