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, 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.