You probably already have a library of technique videos and handouts, and your clients already ask what they should do when their block ends. This puts both a tap away, without a message from you each time, and without a second app or a Drive link.

The dashboard side is live now at trainer.hiignite.com. The phone side comes with app 1.2, which I submitted to the App Store and Google Play today. Your clients see the new screens once their app updates, in the coming days.

Share from your library

It all starts in Library, where your uploads already are. You can share a file (a video, an image or a PDF), a whole folder, or a link. A shared folder stays shared: files you add to it later go out with it.

A share reaches every client you have, now and in future, or one client you pick. Give it a title and, if you like, a short note, such as "Do one before every session. Five minutes is enough." The note shows under the item on their phone.

PDFs can now be uploaded to the library too, so your handouts sit next to your videos. Only your own uploads can be shared: form-check videos, progress photos and clients' private folders never can.

What clients see

In app 1.2, Home has a From your coach card with the newest items. The whole shelf is under Resources in their Profile, grouped by your folders, with your note under each item.

Everything opens inside the app. A video plays in the app, an image opens in a viewer, a PDF opens in a reader with a share button, and a link opens in the in-app browser. Opening an item is recorded, so you see "Opened twice, last today" or "Not opened yet" against it.

Programs clients can start themselves

On Programs, mark a published library program Clients can start this. Clients find it under Browse programs: in their Profile, and on Home when their block has ended or they have no program.

Each card shows the weeks, days per week and sessions, the equipment it needs, and your description. They pick one and tap Start today.

Starting gives the client their own copy, just like when you assign a program, so your library program never changes. They can switch to another program you offer, and a sheet tells them what stops and that their logged sessions are kept. Or they can stop it.

While you have a client on a block, Browse programs tells them so and nothing starts. That stays your call.

What you see

Shared with clients, at the bottom of the library's folder list, lists every share: who it reaches, how often it was opened and when. Each one has Unshare, and Add a link sits at the top. In the library itself, shared tiles carry a Shared tag and their open counts.

Each self-serve card on Programs counts how many clients started, finished and stopped it. A client who started on their own shows as Self-started on the roster and on their page, and their page has a Resources card with what they opened.

Already coaching on hiignite? Open your Library and share one handout with every client. New here? Start free, upload a video, and share it with your first client.

Everything sends as you. An automatic message is an ordinary chat message in your thread with that client, so they just see their coach writing, and their app needs no update. It all lives under Automations, the lightning bolt in the dashboard's left rail.

When a client joins

Set it once: a starter program, an intake form, a welcome message (it can fill in {first_name} and {program}) and a few starter habits. When a client accepts your invite, all of it is applied straight away, so their first look at the app already has their program and your welcome. The program starts the day they join or the next Monday.

Day items in the program builder

A program day can now carry more than the workout: a message, a form (a one-off check-in), a habit that runs for as many weeks as you set, or a note (for now, a note arrives as a chat message too). So "Day 1: welcome", "Day 3: how did the first sessions feel?" and "Week 4: progress form" are written once in the library program, and every client gets them on their own day, at the time you set, on their own clock.

Programs are copied when you assign them, so editing the library never changes a client who is mid-block. If a client is paused, or you switched automations off for them, nothing piles up: an item that's too late is skipped and logged, not sent in a burst later.

Rules for what clients don't do

A rule is one trigger, one wait and one action. There's no flowchart, on purpose: you can read a rule six months later and still know what it does.

• Triggers: gone quiet (no session for a number of days), block ending soon, block ended, check-in overdue, habit streak reached, and joined.
• Actions: send a message, give a form, add a habit, or start the next program, so "block ended" can queue the next block.

A few presets are there when you first open the page. A rule stays quiet if you wrote to that client in the last few days, and it never acts in their evening or night: only from its send time until 21:00, their time.

Rules start in Email me first: they only report what they would do, in your Monday email, and nothing is sent. When you trust them, switch the page to Automatically, as me. Each rule's "Would run today" preview shows which clients it would reach, and when.

The Monday email

One email on Monday morning, from 07:00 your time, with your roster in one read: who is slipping, who has gone quiet, whose block ends, and what your rules would do or did. It goes to coaches with a live plan and at least one active client.

Broadcasts, cohorts and pauses

Broadcasts send one message to many clients: all of them, a roster group, or everyone on one program. Each client gets it as a normal one-to-one message in their own thread, never a group chat, at the local time you picked in their own zone.

Cohorts are the group block where everyone starts together. Pick several clients on the roster, assign one program, and give them a shared start: the same day, next Monday, or a day you choose.

Pausing now shifts the plan. When you resume a paused client, their training and every day item move by the days they were paused, so nothing is lost or doubled. After a pause of 14 days or more, you're asked whether to continue where they left off or restart the block.

A log and a switch on every client

Each client's page has an Automations card: a log of what went out, when, and from which day item or rule, and a switch for On, Snooze 7 days or Off.

Already coaching on hiignite? Open Automations and start with "When a client joins". New here? Start free, invite one client, and see what they get on day one.

That also removes the catch from my last post: you can do it in the phone app now, not only on a computer. A free ChatGPT account is enough, and you don't need a hiignite account until the first time you save a program.

What it can do hasn't changed. It saves programs and adds exercises that are not in your library yet. It still cannot see your clients, messages, form checks or billing, and nothing reaches a client until you assign it yourself.

Claude isn't part of this. There you still add it by hand, as a custom connector. The steps for both are here.

A lot of coaches already draft programs in ChatGPT. Then they retype the whole thing into their coaching platform, exercise by exercise.

So I built a connector that skips that part. Write the program in chat the way you already do, say "save it to Hiignite", and it lands in your library, ready to edit and assign. Each exercise gets matched to the catalogue, so your client gets its demo video, and anything it can't match comes through as your own custom exercise. It works with Claude too.

Setting it up

Setup is about two minutes, once, on a computer. Then you describe the client like you would to a colleague and end with "draft it in Hiignite".

What it can and can't do

In your account it can do two things: save programs, and add exercises that are not in the library yet. That is the whole list. It cannot see your clients, messages, form checks or billing, and it cannot assign anything.

A program from ChatGPT doesn't reach a client until you read it and assign it, same as one you wrote by hand.

Two honest notes

hiignite is not in ChatGPT's plugin directory yet, so you add it by hand. And it has to be added on a computer, not the phone app.

No idea yet if it will work. But watching a six week program go from one sentence to something sitting in the builder is the first time the migration problem felt solvable.

The steps with screenshots are here.

Apple's review

First, Apple came back with a few things they wanted changed before approval.

Trader status

Second, trader status. Under the EU's Digital Services Act you have to verify yourself as a trader before your app is visible in EU storefronts at all. Not a soft warning either: the app just does not show up. Since I am based in the EU and most of my early coaches will be too, this was not something I could leave for later. If you are shipping anywhere in the EU, do this before you submit, not after.

What clients get

Today's session, one tap to mark sets complete, form check video recording, and chat with their coach. What coaches get stays on the web dashboard: programming, review queue, roster.

Get the app

Clients join by their coach's invite, then download it like any other app.

App Store: hiignite on the App Store
Google Play: hiignite on Google Play

If you coach, the app is for your clients, not you. You program and review from the web dashboard. Start free, build a session, and send your first invite.

I expected the answer to be data. Exporting his client records and programmes out of a system that would rather he didn't. That's a real problem, and some platforms do make leaving deliberately awkward.

That wasn't his answer.

It's the videos

His biggest hurdle is finding exercise videos. Not bench press: every stock library has bench press. It's the uncommon movements he actually programmes: handstand plate walks, handstand shoulder taps, the things that make his coaching his rather than generic.

Those aren't in the standard libraries. Rebuilding that collection on a new platform takes hours he doesn't have, and until it's rebuilt, the new platform is worse than the old one at precisely the thing he's known for.

Which reframes the whole migration problem for me. I'd been thinking about switching costs as a data problem. For him it's a content problem, and content is a lot harder to export than a spreadsheet of client records.

So I have a decision to make

I could film them myself. Unique, premium, mine. And slow. I'm also not confident I'd get the demonstration quality right for every movement, and a badly demonstrated handstand progression is worse than no video at all. I'll probably go this route once the app is making revenue and I can work with real professionals on it.

Or I could use free and open resources. Much faster, but it comes with real risks I'd need to work through first: licensing, attribution, inconsistent quality, and what happens when a source disappears and takes part of the library with it.

I'm still thinking on this one. If you've solved exercise video libraries before, I'd genuinely like to hear how.

Meanwhile: the import wizard

This week I'm building the part I can solve. Coaches screenshot their programmes from their old platform, and AI reconstructs them inside hiignite, so migration stops being a weekend of manual retyping.

It doesn't fix the video library. But it does mean the rest of the move is no longer a reason to stay put.

All three do the same job as the thing they replaced. None of them send visitor data to Google.

Three swaps

Altcha runs its challenge locally: proof-of-work in the visitor's own browser, rather than a call out to a third party to grade whether someone looks human enough.

Umami runs on my own infrastructure. It still tells me which pages get read and roughly where readers are, without setting a cookie and without an analytics company sitting in the middle of it.

Fonts are now served from my own domain, so there's no request to fonts.googleapis.com handing over a visitor's IP on every page load.

The font one is the easiest to miss

That last one slips past people, and I think I know why: it arrives through a CSS import, not a script tag.

When you audit what a page loads, you look at scripts. Scripts are where tracking lives, so scripts are what you check. A stylesheet link doesn't read as a third party. It reads as styling. But a font request is still a request, with an IP attached, made by every visitor on every page, to a server that isn't yours.

The performance argument flipped

The old defence of Google Fonts was the shared cache: enough sites use the same CDN copy that visitors turn up with it already cached, so you get the font for free.

That argument is dead. Browser cache partitioning gives each site its own cache entry, so nobody arrives at your site with your font pre-cached from somebody else's. What's left of the CDN is a DNS lookup and a connection to a third-party origin that has to complete before the font can even begin downloading.

Self-hosting removes both. It's usually the faster option now. The tradeoff people were accepting on privacy grounds doesn't really exist any more.

The actual reason

Same pattern I've been following elsewhere: self-hosted mail, self-hosted infrastructure. Not because Google's tools are bad. They're mostly excellent, mostly free, and better engineered than what I'd build. It's that I'd rather not hand more of the stack to companies whose incentives aren't mine.

And it might turn out to be a real selling point. Trainers handle client health and fitness data: weights, measurements, progress photos, injury history. My guess is they care about where that ends up rather more than they tend to say out loud.

The honest reason

I kept seeing it everywhere. It read as a next-generation language, the one that keeps turning up in the places I pay attention to, and I wanted to build something real with it rather than work through another tutorial. That's the origin of the decision. Not benchmarks, not a requirements matrix. Curiosity, plus a project I actually wanted to exist.

I think that's a more common reason than people admit, and I'd rather own it than reverse-engineer a business case after the fact.

What it costs

Development is a lot slower than in any language I already knew. Not slightly slower, a lot. Things I could have written on autopilot elsewhere became genuine problems to sit with.

And the compiler does not let you cut corners. There's no "I'll handle that case later," no leaving a value in a shape you haven't thought through. It refuses, and it refuses in detail, and you don't move until you've answered it. I have a love-hate relationship with it: it's the most irritating part of the day and the reason I trust the result.

On a project built in free time, that cost is real. Slower progress on a side project isn't an abstraction. It's the difference between shipping something and losing interest.

The bet

The thought was that it would mould me into a better programmer. Not "better at Rust", better generally. A language that forces you to be explicit about ownership, about what can fail, about what might be absent, is a language that makes you notice how much you'd been leaving to luck everywhere else.

That part I already believe has paid off, and I don't think you need the project to launch to see it.

Fewer production surprises? Ask me later

The other thing you read constantly is that Rust means fewer surprises in production. I'd like it to be true. I genuinely don't know yet, because we're not live.

So I'm not going to claim it. Anyone telling you about their production Rust experience before they have production is describing a hope, not a result. Ask me again after launch and I'll have an actual answer, including if the answer is that it made no difference.

Would I recommend it?

For every project? No. If you're on a deadline, or validating an idea that might not survive the month, use what you know. Rust will slow you down, and being slow to find out an idea was wrong is the expensive kind of slow.

But if you want to learn something that will matter, and you've got a project you're already turning over in the back of your mind anyway, then yes. A big yes. Learning a language in the abstract teaches you syntax. Learning it while building something you care about teaches you the language.

That combination is the only reason this was a good decision. On its own, "Rust for a new solo project" isn't one.

I touched on this in the stack overview, but it deserves its own post, because it's the piece I'd keep if I had to throw the rest away.

The problem it solves: drift

In past projects, the mobile app and the web client would slowly drift out of sync with the API. Someone renames a field on the backend. The clients carry on referencing the old name. Nothing complains: TypeScript is perfectly happy, because the type it's checking against is one a person wrote by hand, not the one the API actually returns.

So you find out at runtime. Usually on a device. Usually after it shipped.

The insidious part is that hand-written client types look like type safety. You get the autocomplete, the red squiggles, the whole experience. What you don't get is any guarantee that the description still matches the thing being described.

What Specta changes

Specta generates the TypeScript straight from the Rust structs, so there's one source of truth and it's the one the API actually serialises:

#[derive(Serialize, Type)]
pub struct Client {
    pub id: Uuid,
    pub name: String,
    pub active: bool,
}

…becomes:

export type Client = { id: string; name: string; active: boolean }

The mobile app and the web dashboard both consume that generated file. Neither can drift from what the API returns, because neither holds an independent opinion about what the API returns.

Rename name to full_name in the Rust, regenerate, and both clients stop compiling, in exactly the places that reference it. The bug that used to surface as a blank field on somebody's phone now surfaces as a build error on my laptop, before I've pushed anything.

The tradeoff: no free lunch

Every time the Rust structs change, I have to rebind and regenerate. That's a real step in the workflow, and it's a step I can forget. Forget it and the generated types are stale, which puts you back in drift territory, just with a shorter fuse, because the next regeneration surfaces everything at once.

I won't pretend that's free. It's friction, it's mine to remember, and anyone who tells you code generation costs nothing hasn't run it on a Friday evening.

Still worth it, every time

Catching a type mismatch at compile time instead of in production is worth an extra step in the workflow. Every time.

The asymmetry is what makes it easy. Forgetting to regenerate costs me a confusing minute and a rebuild. Not having the generated contract costs a runtime bug on someone else's device, found by them, reported through a channel that may not exist yet, debugged without the stack trace I'd want. One of those is an inconvenience. The other is the kind of bug that erodes trust in the whole app.

For a solo build in evenings and weekends, that trade is not close.

Here's what I picked, and why.

One system, not three stacks

The obvious way to build this is three repositories: an app, a dashboard, and a backend. Three CI setups, three dependency trees, three places where the definition of "a client" can quietly drift apart.

I went with a monorepo instead. Not for the tooling fashion, for the seam. When the app, the dashboard and the API live in one tree, a change to a data shape is one commit that touches every consumer of it, and the thing either builds or it doesn't. Working solo, in evenings, that feedback is worth more than any amount of separation-of-concerns purity. The failure mode I was designing against isn't "the code is messy." It's "I shipped a field rename on Tuesday and found out on Sunday that the app never got the memo."

Expo for mobile and the web dashboard

Coaches work from a laptop. Their clients work from a phone. That's two products with a lot of shared vocabulary (the same programs, the same sessions, the same clients) and I didn't want to write that vocabulary twice.

Expo covers both from one codebase. iOS, Android and the web dashboard come out of the same components, the same navigation, the same state. Where the platforms genuinely diverge they diverge deliberately, in a file I had to open on purpose, rather than by accident across two codebases that slowly stop agreeing with each other.

Rust and Axum for the API

This one I'll be honest about: I was learning Rust and I wanted to use it on something real. Toy projects teach you syntax. They don't teach you what the borrow checker feels like at 11pm when you're four layers into a request handler and something doesn't live long enough.

Axum turned out to be a good fit for exactly that reason: handlers are plain async functions, extractors are types, and most of what would be framework magic elsewhere is just the type system doing its job. The learning curve was real. What I got in return is an API where a whole category of "what if this is null" questions is answered at compile time rather than in production.

Would a solo builder ship faster in something they already know? Yes, and not by a little. Development in Rust is slower than in any language I'd already learned, and I took that trade deliberately. The typed contract further down is a big part of what I got back for it.

SeaORM, because I came from Laravel

Most of my background is Laravel, and the thing I missed most when I moved to Rust wasn't the syntax. It was migrations. Having a versioned, ordered, reversible history of the schema is not a nice-to-have; it's how you stay sane when the schema changes weekly.

SeaORM is the option that felt most familiar coming from that world. Entities, relations, and a migration story that maps closely onto how I already thought about the database. It's not a one-to-one Eloquent port and it doesn't pretend to be, but the mental model transferred, which meant I spent my learning budget on Rust itself instead of on re-learning how to add a column.

Specta: the decision that paid off most

Here's the seam that would have hurt: the API is Rust, and both clients are TypeScript. Every endpoint is a place where a Rust struct becomes JSON and a TypeScript type has to agree with it. Hand-write those types on the client and you've built a bug generator, one that only fires at runtime, on a device, usually after you've shipped.

Specta generates the TypeScript from the Rust. The struct is the source of truth:

#[derive(Serialize, Type)]
pub struct Client {
    pub id: Uuid,
    pub name: String,
    pub active: bool,
}

…and the client-side type falls out of it:

export type Client = { id: string; name: string; active: boolean }

Which sounds like a small convenience and isn't. Rename a field in Rust, regenerate, and the app and the dashboard both stop compiling in exactly the places that need attention. The classic mobile/web type-mismatch bug, where one client was updated and the other wasn't, stops being a bug you find and starts being a build you can't finish. It got caught before it happened, which is the only kind of catching that's actually cheap.

If I had to keep one decision from this whole list, it would be this one.

Bruno, so the API explains itself

API collections in Bruno, checked into the repo alongside the code. The point is that the API is explorable without digging through handler source to work out what a request is supposed to look like.

Right now the person that helps most is me: future me, coming back to an endpoint I wrote in March. But it's also the difference between "here's the API" and "here's the API, and here's a folder of working requests you can fire at it." Bruno keeps those requests as plain files in git rather than trapped in someone's account, which is the part that made me pick it.

And Docker, because why not

Docker for the environment. Postgres and the API come up with one command, the same way on any machine I sit down at. It costs almost nothing to set up early and it's genuinely painful to retrofit later, so it went in early.

Six months in

The stack, in one line: Expo for mobile and the web dashboard, Rust + Axum for the API, SeaORM for the schema, Specta for the type contract between them, Bruno for exploring the API, and Docker for the environment, all in one monorepo.

None of it is exotic. What's held up is the theme running through it: put the seams where a machine can check them. The monorepo makes a cross-cutting change one commit. Expo makes the app and the dashboard one vocabulary. Specta makes the Rust/TypeScript boundary a compile error instead of a support ticket. For someone building in their free time, the compiler is the only teammate reviewing my work, so I've tried to give it as much to review as possible.

Still building. More notes as things break.