A New Beginning: Why We're Building Xircuit

A blueprint as a symbol of a new foundation Photo: Rawpixel (CC0 1.0), via Openverse

There's a kind of software that looks simple from the outside and turns out to be surprisingly complex on the inside: managing people. A gym keeps membership lists, a club tracks dues, a medical practice keeps appointments and findings. On paper, that sounds like the same problem — until you notice that each of these industries brings its own language, its own rules, and its own privacy requirements. That's exactly where Xircuit comes in.

This first post in our dev-log series explains the why. Not the how in detail — that's coming in the following weeks. Rather, the motivation behind it and the foundational technical decisions that come first and shape everything that follows.

Over the years I've seen the same scene play out again and again. A small business — a studio, a practice, a salon — juggles a spreadsheet for members, a separate calendar for appointments, a card terminal for payments, and in the worst case a sheet of paper taped to the door for check-in. Each tool works fine on its own, but gaps yawn open between them, where data gets maintained twice and mistakes creep in.

Xircuit is designed as an all-in-one platform for membership and health data that closes these gaps. And not for one industry, but for seven: gyms, personal trainers, medical practices, clubs, spas, and hair and beauty salons. That's a deliberately broad ambition, and it comes with an uncomfortable question — can a single platform serve such different businesses well, without being half-baked for each of them?

Why Seven Industries and Not One

The obvious answer would have been to focus on gyms and look at everything else later. I deliberately decided against that, because the shared core of these businesses is much larger than it first appears. Look closely, and you'll find the same five building blocks across all seven industries.

Manage members — from first contact through core data to history.
Book appointments — whether a training session, a consultation, a treatment, or a club event.
Securely incorporate health data — wherever the industry requires and allows it.
Bill — dues, packages, individual services.
Control access — the door, the turnstile, check-in.

The difference between a gym and a medical practice isn't in these building blocks themselves, but in how they're weighted and combined. A gym needs access control and billing right up front; a practice puts appointments and the sensitive handling of health data at the center. If you build the core right, the industry ultimately becomes a question of configuration — not a question of seven separate products.

One Codebase, Six Platforms

The second foundational decision concerns the technology under the surface, and it's just as far-reaching. Xircuit runs on a single .NET 10 Blazor Hybrid codebase with MAUI. From this one foundation, we ship Web, Windows, macOS, iOS, iPadOS, and Android.

This isn't a compromise made for convenience. Blazor Hybrid with MAUI is mature enough by now that we achieve good performance and a native feel across all six platforms without writing the logic multiple times. We deliberately don't use React Native, no Flutter, no separate Swift for Apple devices. The reception desk at the studio, the iPad at the front desk, and the member's smartphone all draw on the same codebase. A rule that applies to appointment booking applies everywhere — because it exists in exactly one place.

Especially with health data, this property is more than a development advantage. A single codebase means a single place where access rules and privacy are enforced. There's no second, slightly different implementation on the phone that someone forgets to keep in sync.

People training in a modern studio Photo: Khusen Rustamov · StockSnap (CC0 1.0), via Openverse

The Local Engine: .NET Aspire

A platform that connects members, appointments, payments, search, and access control consists of many moving parts. In operation, that means an API, a database, a message bus for asynchronous workflows, blob storage for files, and a search index. Distributed systems like this are notorious for turning even the local startup into a test of patience.

.NET Aspire is exactly what takes this problem off our hands. Aspire orchestrates the entire local development environment: API, database, service bus, blob storage, and search all start with a single command, cleanly wired together, with a dashboard that shows what's happening right now. That sounds like a detail for developers, but it's actually a lever for the speed of the whole project. Anyone who can try out an idea in minutes instead of half an hour tries out more things — and ends up making better decisions.

What works well locally has to run reliably in production. For operations, we rely on Azure Container Apps. That gives us an environment that scales with load without us having to maintain servers by hand, and one that fits the container-based structure Aspire already encourages.

For two building blocks, I didn't want to invent anything myself from the start, because mistakes here are especially costly. Auth0 handles authentication — the question of who someone is and what they're allowed to access is the most delicate one of all when it comes to health data, and it belongs in the hands of a specialized provider. All secrets, from database connections to API keys, live in Azure Key Vault instead of configuration files. No credentials in code, no password in a repository. Both of these decisions are unspectacular, and that's exactly the point: security should be boring and taken for granted.

What This Foundation Is Meant to Carry

When I put the pieces together, a clear picture emerges. A shared core of five building blocks — managing members, booking appointments, securely incorporating health data, billing, controlling access — gets assembled differently depending on the industry. Underneath it all, a single codebase serves six platforms, orchestrated locally by Aspire and run in the cloud on Azure Container Apps, secured by Auth0 and Key Vault.

None of this is revolutionary on its own. The bet lies in the combination, and in the discipline to keep the core clean instead of building in a shortcut for every new industry. Whether this bet pays off will become clear over the coming months — and this dev log will follow that path honestly, with the decisions, the trade-offs, and the places where we're not yet sure.