How a Solo Developer Built a $8K/Month Fitness SaaS in One Weekend Using Kimi K2.6

The breakdown (stack, schema, prompts, and the one psychological trick that actually converts users)

Photo by Arian Darvishi on Unsplash

A solo developer laid out exactly how they shipped a subscription fitness app in a weekend and got it to $8K/month net.

No co-founder.

No team.

One API they’d never used before.

I’ve been building micro-SaaS products under aibucket.org (boutpredict.aibucket.org being the famous one) for a while now, so I talk to/read these breakdowns thing carefully.

Most “I made $X/month” posts skip the part that actually matters , the decisions behind the decisions.

This one won’t.

Free to read for non members

The model they used

The developer built around Kimi K2.6.

If you haven’t heard of it, it’s been sitting at the top of OpenRouter’s weekly usage charts, apparently over 1.5 trillion tokens processed last week, which is more than Claude and DeepSeek combined.

The context window is large enough to hold an entire codebase in one shot.

The other thing worth noting:

it’s fully compatible with the OpenAI SDK.

You just change baseURL and model. That's it.

Any existing code written for GPT or similar works without modification.

For someone building fast and iterating in the same week, that matters.

What they actually built

Not a generic workout tracker.

The product is called Summer Body Coach, and the core mechanic is adaptive planning.

If a user completes 80% of their workouts that week, the plan gets harder next week.

If they complete 50%, it gets easier.

The AI adjusts based on actual behavior logged in the database, not based on what the user says they want.

This is a small product decision that changes everything about retention.

Most fitness apps treat all users the same after onboarding.

This one treats the app like a feedback loop.

The MVP features:

Onboarding quiz collecting goal, equipment, fitness level, and available time

AI-generated 7-day workout plan from that data

Calorie tracking via photo upload (the AI identifies food and estimates macros)

Daily check-ins with a personalized message based on recent behavior

Streak tracking

A progress dashboard

A coach chat interface

Stripe subscriptions with a 7-day free trial

That’s a full product.

Built in a weekend because of how they scoped the AI’s role, not as a chatbot layer on top of a regular app, but as the engine that runs the adaptation logic.

Photo by La-Rel Easter on Unsplash

The technical stack

Web-first, not mobile.

This was a deliberate call.

Faster to build, faster to validate, and Stripe integrates in an hour on web.

Mobile comes after the product is already making money and you know what users actually need.

The stack:

• Next.js 14 with TypeScript
• Tailwind + shadcn/ui for UI
• Supabase for auth and database
• Stripe for subscriptions
• Resend for email reminders
• Vercel for deployment
• Kimi API for the AI layer

Nothing exotic.

Every piece of this has good documentation, a large community, and existing open-source projects you can reference.

How they used AI to build the AI product

The approach here is the part most write-ups skip.

Instead of prompting the model to write everything from scratch, they fed it five existing open-source GitHub repos as reference material simultaneously.

The context window let Kimi K2 hold all of them in memory at once.

The repos were:

• A Next.js SaaS starter for auth and billing architecture
• A Supabase + Stripe + Resend boilerplate for the subscription layer
• An open-source workout tracker for the exercise database and plan logic
• A separate fitness logging app for progress charts and routine management
• An AI calorie tracker that already handled photo-based food analysis

The prompt they used was essentially: read all five, then build me this specific product in this specific order, write complete TypeScript for each component, and fix errors before moving to the next.

That’s a different workflow from “write me a fitness app.”

You’re not generating from nothing.

You’re orchestrating across existing, tested implementations.

The result is code that’s less brittle because it’s based on patterns that already work in production.

The API integration

The actual integration is about 20 lines:

import OpenAI from "openai";
const client = new OpenAI({
  apiKey: process.env.MOONSHOT_API_KEY,
  baseURL: "https://api.moonshot.ai/v1",
});
export async function POST(req: Request) {
  const { profile, meals, workouts, message } = await req.json();
  const completion = await client.chat.completions.create({
    model: "kimi-k2-0711-preview",
    messages: [
      {
        role: "system",
        content: `You are Summer Body Coach, an AI fitness trainer.
Give safe, practical, motivating advice based on what the user has actually done.
Keep responses under 150 words. Be specific.`
      },
      {
        role: "user",
        content: JSON.stringify({ profile, meals, workouts, message })
      }
    ],
  });
  return Response.json({
    reply: completion.choices[0]?.message?.content,
  });
}

This route lives at app/api/coach/route.ts.

The key is passing the full user context (profile, recent meals, recent workouts), every time.

This is what makes the responses feel personal instead of generic.

The system prompt they used for the trainer

Instead of writing a long prompt every time, they created a single skill file that defined the coach’s behavior onc

You are a motivational but realistic fitness coach.

Your job:
- Help users build consistent habits, not perfect ones
- Create 45-minute workout plans that fit the user's current level
- Analyze food photos and estimate calories and macros
- Adapt plans weekly based on what the user actually completed
- Keep daily check-ins under 120 words

Rules:
- Never give medical diagnoses
- Start with beginner-friendly defaults
- If a user missed 2 or more days in a row, simplify the plan — do not guilt trip them
- If a user hit 90% completion or more, increase intensity next week
- Always reference specific data from the user's profile and logs
- Never use generic phrases

The last two rules are what separate this from a generic AI wrapper.

The behavior adapts based on logged data, and the instructions explicitly prevent the AI from doing the thing that destroys retention in most habit apps that is making users feel bad for missing days.

The database schema

create table profiles (
  id uuid references auth.users primary key,
  goal text,
  height_cm int,
  weight_kg decimal,
  activity_level text,
  equipment text[],
  weekly_days int,
  session_minutes int,
  created_at timestamp default now()
);
create table meal_logs (
  id uuid default gen_random_uuid() primary key,
  user_id uuid references profiles,
  photo_url text,
  ai_analysis jsonb,
  logged_at timestamp default now()
);
create table workout_logs (
  id uuid default gen_random_uuid() primary key,
  user_id uuid references profiles,
  plan_id uuid,
  completed boolean default false,
  completed_at timestamp
);
create table streaks (
  user_id uuid references profiles primary key,
  current_streak int default 0,
  longest_streak int default 0,
  last_active_date date
);
create table subscriptions (
  user_id uuid references profiles primary key,
  stripe_customer_id text,
  status text,
  trial_ends_at timestamp,
  current_period_end timestamp
);

The ai_analysis field as JSONB is a good call.

You don't know upfront exactly what structure the model will return for food analysis, and JSONB lets you query into it later without a schema migration.

The trial model

7 days free, no credit card required upfront.

This sounds like it would tank conversions.

It actually improves them, and the psychology is documented enough that it’s not really debatable for habit-based products.

The user builds a streak during the trial.

By day 7, they have 6 or 7 days of completed workouts logged.

The payment screen appears and they’re not being asked to pay for a product they haven’t tried.

They’re being asked to not lose something they’ve already built.

The Stripe setup:

const session = await stripe.checkout.sessions.create({
  customer_email: email,
  mode: "subscription",
  payment_method_types: ["card"],
  line_items: [{
    price: process.env.STRIPE_PRICE_ID,
    quantity: 1,
  }],
  subscription_data: {
    trial_period_days: 7,
    metadata: { userId }
  },
  success_url: `${process.env.NEXT_PUBLIC_URL}/dashboard?success=true`,
  cancel_url: `${process.env.NEXT_PUBLIC_URL}/pricing`,
});

Nothing special in the code.

The conversion happens because of what the user experienced before they got to this screen.

The numbers

At $9.99/month, after his marketing it was roughly 850 paying users.

Monthly revenue: ~$8,492 Costs at that scale: ~$400–500/month (Supabase free or pro, Vercel hobby/pro, API tokens are low at this volume) Net: ~$8,000

The build cost was $30–50 in API tokens over a weekend.

Photo by Jacob Padilla on Unsplash

If you’re building anything subscription-based, the trial-first model and the adaptive behavior loop are worth studying regardless of what you’re building.

The fitness vertical just makes the psychology obvious.

In case we are meeting for the first time, come over *here, it’ll be worth the roller coaster of articles that are gonna come up in the next few weeks.*

I swear tracking these updates is a job in itself, lately.

Here’s the *list which I’ve built and keep adding on*.

And If you need help for analyzing UFC fights, please check out *BoutPredict :)*