Own your coaching software. So an update can never switch your business off.

On November 10, 2026, a platform update left a lot of online coaches with clients who couldn't log in. No programs, no check-ins, no meal plans, no messages. If that was you, this guide is for you. I'm a coach too, I've switched platforms three times, and I know exactly how that morning feels.

This guide gives you three ways forward. Pick the one that fits your time, budget and skills. All three end in the same place: you own your clients, your data and your platform.

The first 24 hours. Protect the relationship first.

An outage doesn't lose you clients. Silence does. Your clients don't care whose software broke. They care whether their coach has it handled.

1. Message every client outside the app, now

Use whatever you still control: email, text, an Instagram broadcast channel, WhatsApp, Telegram. Keep it short, calm and specific. Here's a template you can copy:

2. Export everything you can, today

Whether or not the platform comes back, assume this happens again. Pull out whatever the platform lets you: client names and emails, active programs, nutrition plans, check-in history, progress photos and payment status. If there's no export button, screenshots and copy-paste are better than nothing. Store it somewhere you own (a private drive, encrypted if it includes health information).

3. Give clients a fallback for this week

The Google Sheet coaches had a normal day today for one reason: they owned their files. Borrow that. A shared doc or sheet per client with this week's training, nutrition targets and check-in questions keeps everyone moving until you're back up. It's a stopgap, not a business model, but it works today.

4. Don't make permanent decisions in a panic

Don't cancel, migrate or sign up for anything new today. Stabilize clients, secure your data, then make the decision with a clear head this week using the rest of this guide.

The ownership audit. Ten minutes, five layers.

"Owning your software" doesn't have to mean writing code. It means no single company can switch off a layer of your business without you having a way around it. Score yourself honestly.

How to read your score

• 0 to 2 owned: Start with Part 3 this week. That alone removes most of the risk.
• 3 to 4 owned: You're close. Decide between DIY, DWY and DFY for the app layer.
• 5 owned: You're already ahead of most coaches. Use the DIY section to harden it.

Own your data, even if you keep renting the app.

Not everyone needs their own app. Everyone needs to be able to leave. Do these this week and the next outage becomes an inconvenience, not a crisis.

1. Move billing into your own name. A payment account your business owns, with subscriptions you can see and manage. If the platform handles payments today, plan a move at your next renewal cycle so clients only re-enter their card once.
2. Build a client list you control. A simple CRM or even a private spreadsheet: name, email, phone, start date, package, renewal date, goal. Update it every week.
3. Keep your content as files. Every program, lesson and template saved as a document or spreadsheet you own. Your platform becomes the delivery truck, not the warehouse.
4. Schedule a weekly export. Same time every week: export or copy check-ins and key metrics for active clients. Put it in your calendar like a client call.
5. Check the contract. Read your platform's terms for data ownership, export rights and notice of changes. If exports aren't guaranteed, ask in writing.
6. Write a one-page outage plan. Who you message, how, and what clients do in the meantime. You already have the template from Part 1.
7. Test your exit once. Pick one test client and try to move them, start to finish. You'll find the gaps before a real outage does.

The technical blueprint. Build your own coaching app.

This is the honest version. Building and running your own coaching software is a serious project. This section shows you every moving part so you can decide with your eyes open, and so you know exactly what to ask for if you hire it out.

4.1 The architecture at a glance

4.2 The data model

Get this right and everything else is easier. A coaching app at minimum needs these tables. Every row that belongs to a client also carries the coach (or organization) it belongs to, so access rules stay simple.

A starting point in Postgres, with row-level security so a client can only ever read their own data and a coach only their own clients:

create table clients (
  id uuid primary key default gen_random_uuid(),
  coach_id uuid not null references coaches(id),
  user_id uuid unique references auth.users(id),
  status text not null default 'active',
  package text,
  start_date date default current_date,
  renewal_date date,
  timezone text default 'America/New_York'
);

create table check_ins (
  id uuid primary key default gen_random_uuid(),
  client_id uuid not null references clients(id) on delete cascade,
  coach_id uuid not null references coaches(id),
  week_of date not null,
  bodyweight numeric(5,1),
  answers jsonb not null default '{}',
  photo_keys text[] default '{}',
  coach_feedback text,
  created_at timestamptz default now()
);

alter table check_ins enable row level security;

-- clients see only their own check-ins
create policy client_reads_own on check_ins for select
  using (client_id in (select id from clients where user_id = auth.uid()));

-- coaches see only check-ins from their own clients
create policy coach_reads_clients on check_ins for select
  using (coach_id in (select id from coaches where owner_id = auth.uid()));

4.3 Offline first: the feature clients notice

Gyms have bad signal. If logging a set needs a connection, clients lose work and blame you. Build it so the app saves locally first and syncs later:

• A service worker caches the app shell, so it opens with no signal.
• Every write (a set, a food entry, a check-in) goes into a local queue in IndexedDB with a unique id.
• When the connection comes back, the queue syncs to the server. The unique id means a retry never creates a duplicate.
• Conflicts (coach edited the plan while the client was offline) resolve by a clear rule, usually "latest change wins, keep both in the history".

// queue a set log locally, sync when online (simplified)
async function logSet(entry) {
  entry.id = crypto.randomUUID();          // idempotency key
  entry.queuedAt = Date.now();
  await db.put('outbox', entry);           // IndexedDB store
  if (navigator.onLine) flushOutbox();
}

async function flushOutbox() {
  for (const item of await db.getAll('outbox')) {
    const res = await fetch('/api/set-logs', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json', 'Idempotency-Key': item.id },
      body: JSON.stringify(item)
    });
    if (res.ok) await db.delete('outbox', item.id);   // keep it if the server said no
  }
}
window.addEventListener('online', flushOutbox);

4.4 Payments that don't break

Keep billing in your own Stripe account from day one. Then the app is just a view on top of it, and you can change apps without touching anyone's card.

• Use Stripe Billing for subscriptions and the hosted Customer Portal so clients can update cards and cancel without emailing you.
• Listen for webhooks and treat them as the source of truth: invoice.paid (grant access), invoice.payment_failed (start a grace period and a friendly reminder), customer.subscription.updated and customer.subscription.deleted.
• Always verify the webhook signature and make the handler safe to run twice.
• Never store card numbers yourself. Stripe holds them; you store ids.

// webhook skeleton (Node / Express)
app.post('/stripe/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], WEBHOOK_SECRET);
  } catch { return res.status(400).end(); }

  if (await alreadyProcessed(event.id)) return res.json({ ok: true });

  switch (event.type) {
    case 'invoice.paid':            await grantAccess(event.data.object.customer); break;
    case 'invoice.payment_failed':  await startGracePeriod(event.data.object.customer); break;
    case 'customer.subscription.deleted': await endAccess(event.data.object.customer); break;
  }
  await markProcessed(event.id);
  res.json({ ok: true });
});

4.5 Security and privacy: non-negotiable

You're holding body weights, photos, sometimes health history. Treat it like it matters, because it does, and because your clients' trust is the business.

• Two-factor login for coaches always, and offered to clients.
• Encryption in transit (HTTPS everywhere) and at rest (your database and storage provider should do this by default; check).
• Least access: row-level security as above, private storage buckets, signed URLs that expire for progress photos.
• Secrets out of the code: API keys in environment variables or a secrets manager, never in the app bundle.
• Audit log for sensitive changes, so you can always answer "who changed this, and when".
• Consent and privacy policy that says what you collect, why, where it's stored and how a client can have it deleted. Health information is treated as sensitive under privacy laws in Canada, the US and elsewhere. Get express consent and talk to a privacy lawyer for your situation. This guide isn't legal advice.

4.6 Backups: the 3-2-1 rule

Three copies of your data, on two different kinds of storage, with one copy off-site. For a coaching app that looks like:

• Your live database (copy 1) with your provider's automatic backups and point-in-time recovery turned on.
• A nightly encrypted database dump to separate object storage (copy 2).
• A weekly copy to a different provider or an offline drive you control (copy 3).
• Test a restore every month. A backup you've never restored is a hope, not a backup.

# nightly encrypted backup (cron, 3 a.m.)
0 3 * * * pg_dump "$DATABASE_URL" --format=custom \
  | gpg --encrypt --recipient [email protected] \
  > /backups/coach-$(date +\%F).dump.gpg \
  && rclone copy /backups remote:coach-backups --max-age 25h

4.7 Release discipline: today's actual lesson

Most outages aren't hacks. They're updates. Owning your software means you decide how changes reach clients:

• Staging first. Every change runs on a copy of the app with test data before real clients see it.
• Feature flags. Turn new features on for yourself, then a few clients, then everyone.
• Never on a Monday morning. Ship when you can watch it, and never right before check-in day.
• One-click rollback. If something breaks, going back to yesterday's version should take minutes.
• Tell clients before big changes. A short heads-up message beats a hundred confused DMs.

4.8 Getting into the App Store

A home-screen web app gets you most of the way, and you control every update. A store app adds native push, Apple Health and Google Health Connect access, and that "real app" feeling.

• Apple Health (HealthKit) data is only available to native iOS apps. A web app can't read it.
• Apple's developer program has an annual fee; Google Play has a one-time fee. Check both sites for current pricing.
• Read Apple's App Review Guidelines on payments before you launch. Real-time one-to-one services (like personal training) have different payment rules from digital content sold inside the app, and the rules change. Check the current version.
• Plan for review time and the occasional rejection. Keep your web app live so clients are never waiting on Apple.

4.9 Moving clients over without losing them

1. Map the data. List every field in your old platform and where it lands in your new tables.
2. Import a test batch. Two or three clients. Check every program, log and photo landed correctly.
3. Run both side by side. New app live for a small group while everyone else stays put.
4. Set a cutover date and tell clients two weeks ahead, with a short video showing the new app.
5. Move billing last, and only once the new app has been stable for a full check-in cycle.
6. Keep read-only access to the old platform for a month if you can, in case something's missing.

4.10 Realistic costs and time

Prices change. Check each provider's current pricing before you budget.

Build it with me. Payment: a follow.

Real talk: if you were stressed this week, I was too. I've been on the coach side of this three times. So if you want to build your own platform yourself, I'll help you do it. No invoice.

Here's the deal

• Follow @anthoniefallone on Instagram and engage with my content. That's payment enough for me.
• Send me your questions by DM. Stuck on the data model, payments, what to build first, which tools to pick? Ask. I'll answer as many as I can and point you in the right direction.
• Share what you're building. I'll give you honest feedback on your plan and flag the mistakes I made so you don't repeat them.
• I'll post the common answers as content, so everyone building alongside you benefits.

I'll help where I can, around coaching my own clients. It's guidance, not a done-for-you service, and I can't promise a reply time.

We build it for you. You go back to coaching.

This is what we do at Adapted Industries. We build and run software for brands, including our own coaching app. If you'd rather never think about servers, backups or app store reviews, we'll build your branded coaching platform and look after it.

Pricing

Every coaching business is different, so every build is custom-quoted. It's a serious investment, priced for coaches who see their platform as the core of their business. Book a free call, tell us how you coach, and we'll tell you what it takes.

Book a free call

Your 30-day plan. Whichever path you pick.

FAQ.

Should I leave my current platform right now?

Not today. Stabilize your clients, secure your data, then decide with a clear head. Plenty of coaches will stay where they are and simply own their data. That's a valid choice.

Can I really build my own app without a tech background?

You can learn it, but it's a big project and running it is ongoing work. Be honest about your time. The middle road in Part 3 removes most of the risk without writing code.

Will I lose clients if I switch?

Not if you plan it. Run both side by side, tell clients early, show them the new app, and move billing last.

Is a web app good enough, or do I need the App Store?

A good web app installed on the home screen covers most of what clients need, and you control every update. Add a store app when you want Apple Health, native push and that extra polish.

What about the Google Sheet coaches?

They had the right instinct: own your files. A sheet is a great backup. It's just not the experience most clients will pay premium prices for. The goal is both.

How much does the done-for-you build cost?

It's custom-quoted, because it depends on how you coach and what you need. Book a free call and we'll give you a straight answer.