Updates and stories from The Hub Ecosystems.
Blog Day Sunday
By The Developer, co-authored with AI — 2026-07-06
Here's what one week of building The Hub Ecosystems looked like.
The short version
In seven days, across 67 sessions, we:
- Shipped a full mobile overhaul for Hub People — our communication app (still in development, but usable on a phone now)
- Built a brand new app from scratch in under a week, dev-tested like every app is — because they're all built for The Developer first
- Overhauled the authentication system — how people sign in, how sessions work, how trust is established
- Designed an encryption model for Hub People where your relationships are protected at the mathematical level — not just a setting you toggle, but how the system works at its core
- Shipped work across 7 apps — communication, telephony, email, push notifications, location sharing, notes, and the core platform
- Ran a deep, every-file audit of the codebase (we do these regularly, for many reasons, and keep them)
- Planned the company structure across multiple countries
- Wrote 12+ architecture plans for what comes next
All directed by one person. Co-authored with AI. Honestly.
How this works
The Developer has always had a knack for system-level thinking and working with computers — better than your average person for sure. AI doesn't replace that. It amplifies it.
The Developer decides what gets built, why it matters, and how it should work. The AI writes the code, runs the checks, and handles the volume that one person physically couldn't type fast enough to do alone. The judgment is human. The execution is assisted.
That's the whole arrangement. Nothing hidden about it.
Why this pace matters
Because it means one person can build something that would normally take a team of twenty and two years of runway. No investors breathing down anyone's neck. No feature being built because a board demanded it. Every app exists because it solves a real problem for the person who built it — and that person uses it every day.
When it's ready for others, it'll be ready because it actually works. Not because a deadline said so.
Blog Day Sunday
This post updates on Sundays — but only when there's something worth sharing. If it was a quiet week or the work wasn't significant enough to write about, there's no update. No filler, no padding, no post for the sake of posting.
When there is an update, it replaces this section with what happened that week. Major releases, meaningful progress, or decisions that shape what The Hub Ecosystems becomes — those earn a Sunday post. Routine maintenance doesn't.
Previous weeks' posts move to the archive — nothing gets deleted, just rotated out so this page stays current.
This section adds context for readers who want to understand the scope better.
Hub People — mobile overhaul + coordination system
Hub People is the communication app in the ecosystem. This week it went from desktop-only to properly mobile-friendly — 15+ layout and interaction fixes, rebuilt navigation for touch, and a system that preserves where you are even when the app refreshes. Open-in-new-tab support was added for servers and channels.
A built-in coordination system (AI Questions) was shipped — a card-based interface for tracking development questions, bugs, and ideas across every app in the ecosystem. The blog and docs channels were rebuilt as responsive card grids.
A root-cause bug was found and fixed: renaming a channel was silently orphaning every message in it because the backend didn't migrate name-keyed tables. Now it does. The notification system was overhauled to be event-driven instead of timer-based, saving battery.
Hub Core — identity + public presence
The system that handles identity, sessions, and trust got significant work. Multiple ways to sign in. Email verification before an account even exists. Fast re-entry on trusted devices. A new landing page went live with a waitlist and brand theming. The blog you're reading was built and launched, along with a double opt-in newsletter.
Shareable preview links let the owner share unreleased landing pages for 24 hours — they auto-expire with a visible countdown. A PIN-gated downloads page was built for managing app releases.
Hub Cell — reliability + cost visibility
The telephony app had an outbound call reliability fix — calls were being marked as "answered" before anyone actually picked up, causing audio to be armed too early. A provider cost tracker now shows exactly what the service costs month-to-month.
Hub Notify, Hub Mail, Hub360, Hub Notes
The push notification service went live as a standalone system with its own authentication. Hub Mail received a raw email webhook that decouples the email pipeline from any AI dependency — email is pure transport, no AI in the loop. Hub360's backend shipped real-time location sharing with live server-sent events. Hub Notes began accepting single sign-on from the core identity system.
Architecture + planning
12+ planning documents were written covering: succession planning, sovereign authentication (public-key identity where the private key never leaves the browser), agent authentication, repository restructuring, licensing, and more. A 48-item follow-up bucket was documented for the next phase of work.
A company structure was planned spanning three countries with a trust-based ownership model designed to separate personal liability from company assets while maintaining full control.
A new app in 7 days
A brand new app was scoped, designed, built, and deployed in under a week. Like every app in the ecosystem, it was built for The Developer first — tested in real use before anyone else ever touches it. That's the standard: nothing ships that The Developer doesn't use themselves.
For readers who want to understand the engineering decisions.
Mobile-first architecture (Hub People)
The communication app received a complete mobile pass — z-index stacking corrections for the server rail and channel list panels, flex-wrap solutions for message reply references, viewport-aware keyboard handling (scrollIntoView on focus with visualViewport resize detection), and state preservation across refreshes using per-tab session storage. The app is a progressive web app with a network-first service worker, push event listener, and install support.
A channel-rename migration bug was root-caused: five name-keyed tables (messages, threads, read state, read receipts, onboarding) weren't being updated on rename, orphaning all content. The fix migrates every table in a single transaction.
App architecture
Every app in the ecosystem is a standalone module. Nothing is pre-installed on a hub instance — the instance owner adds the apps they want via a management interface. Each app is independent: its own database, its own auth integration, its own deploy pipeline. This week proved that pattern holds — new app, one week, deployed and running.
Authentication
The auth system supports multiple entry paths — email-verified accounts, username-only accounts with recovery phrases, fast PIN-based re-entry on known devices, and challenge-response for new devices. Sessions are httpOnly cookies with strict same-site policy. The server never stores plaintext credentials — only hashed derivatives.
Apps accept single sign-on from the core identity system — the gateway forwards the session cookie, and each app validates it against the core's verify endpoint with a short in-memory cache. Fail-closed: if the core is unreachable and the token isn't cached, the session is denied.
Per-relationship encryption model (Hub People)
The encryption architecture for Hub People operates at the relationship level, not the application level. Each relationship context (a DM, a server membership, a friend connection) generates its own cryptographic key. Consequences:
- Blocking = key revocation (the blocked party's existing key decrypts nothing going forward)
- Server kick/ban = server key rotation (all remaining members get the new key, the removed user is locked out mathematically)
- Role changes = key tier changes (promote to admin = new key tier, demote = rotation back to member tier)
- Compromise containment: one leaked key exposes one relationship, not the system
Local-first data model
The system is designed local-first. Messages write to a local queue (durable, survives crashes), broadcast instantly via real-time connections for speed, and sync to the server asynchronously via a single-writer thread. The database engine handles sequential writes efficiently with write-ahead logging — no contention, no batching delay for the user.
If the server goes offline, the local queue holds everything. When it comes back, the sync resumes from where it left off. No messages lost, no duplicates, no user-visible interruption.
Email pipeline — zero AI dependency
The email transport chain was confirmed to have zero AI/LLM involvement at any point. A raw MIME webhook was shipped that receives email directly, bypassing the AI agent entirely. Email is pure plumbing — send, receive, store, display. AI features for email (classification, summarisation) are planned as opt-in bolt-ons, never baked into the transport.
Push notification consolidation
All apps' background notifications are being routed through a single push notification service. The service runs its own auth (not dependent on any other app), supports Web Push with VAPID keys, and is designed so mobile apps can go fully dormant except for real events. Priority-based delivery ensures calls are prioritised over general messages.
Audit methodology
Every file in the codebase is being scoped for a deep audit — per-app reports, cross-app synthesis, and research into reference implementations. The audit produces ranked findings: what costs the most time, what causes the most bugs, what's duplicated across apps, what's missing for multi-user readiness. It's not a pass/fail — it's a prioritised refactor map that informs the next phase of development.
Directed by The Developer. Co-authored with AI.
What's new — July 2026
By The Hub Ecosystems — 2026-07-03
Here's what we've been shipping recently.
A new front door for accounts
The biggest piece: we rebuilt how you create an account and sign in to The Hub. The goal was to make it flexible and genuinely secure, without forcing everyone down the same path. A few of the ways you'll be able to get in:
- Email and password — with a twist: we verify your email before the account is created, so there's no such thing as a half-made, unverified account sitting around. Throwaway and disposable email addresses are turned away at the door.
- No email? No problem. You can create an account with just a username and password, secured by a recovery phrase — a set of words that acts as your personal backup key. Nothing to leak, no inbox required.
- Fast sign-in on a device you trust — once you've used a device before, getting back in can be as quick as your username and a PIN.
- A new device gets an extra check — signing in somewhere we haven't seen before asks for one more step, so a stolen password alone isn't enough.
This is rolling out carefully rather than thrown open all at once — but the foundation is built, and it's a big step toward The Hub being something anyone can pick up.
One sign-in across the ecosystem
The Hub is a set of apps, and it never made sense to sign in to each of them separately. Now you don't have to: one account signs you in across the ecosystem. Sign in once, and the apps recognise you.
This blog and newsletter
You're looking at one of them. We wanted a straightforward place to share what we're building and why — so we made this blog, split into Stories (the thinking behind The Hub) and Updates (what's new, like this one).
The newsletter is the other half. Subscribe and we'll email you when we ship something worth telling you about — nothing else. You confirm your email first, and every message has a one-click unsubscribe. No noise, no games.
Coming up
There's a lot in flight. We'll keep posting here as it lands. If you'd rather it came to your inbox, subscribe below.
One person, with a little help from AI
By The Developer — 2026-07-02
Let me be upfront about how The Hub gets made: it's built by one person — me — with code assistance from an Artificial Intelligence.
That's worth saying plainly, because it's becoming normal to hide it. AI helps me write and review code faster than one person otherwise could, and it lets a solo developer take on something this broad. But the direction, the decisions, and the judgment about what The Hub should be are mine. The AI is a very capable tool; it isn't the one deciding what gets built or why.
A tool for the builder is not a feature in your Hub
Here's the important distinction, and it's one I take seriously.
Me using AI to build The Hub is completely separate from AI being in the product you use. Those are two different things, and I refuse to let the first quietly become the second.
In The Hub, you are never forced into AI. Ever.
- Anything AI-powered is optional and off by default. You turn it on if you want it, and not otherwise.
- No essential function depends on it. The things that have to work — your messages, your calendar, your email — work with no AI in the loop at all.
- Where AI features do exist, they're designed to be a bolt-on you control, not a condition of using your Hub.
- Your content isn't quietly handed to an AI to use. Opting in is a decision you make, not a default you have to discover and switch off.
Why I'm telling you
Because trust is the whole point. If I'm going to ask you to keep your life in one place, you deserve to know how that place is built — and to know that "the developer uses AI" never turns into "your private data feeds an AI you didn't ask for."
One person can build a lot with the right tools. Making sure those tools serve you, and only when you want them, is the job.
Why we built The Hub Ecosystems
By The Developer — 2026-07-01
I didn't set out to build a product. I built The Hub for myself.
My life was chaotic, and the tools I was supposed to use to manage it were scattered across a dozen apps, each with its own login, its own subscription, and its own quiet claim on my data. None of them talked to each other. So I built one system that did — a single place I actually controlled.
For the first twelve weeks it had no domain and no landing page. It wasn't for anyone but me. To be clear about where things stand today: it's still in active development, and I'm currently the only person using it. This isn't a finished product you can sign up for yet.
Why it's growing beyond me
As I built, I started telling the people around me what I was working on. They were interested — some of them said they'd want to use it too. And I realised I needed parts of it to support my own people, which is exactly why something like Hub People exists.
That interest, and that need, is why I'm beefing it up. What began as a private system is turning into something that could work for other people — carefully, and on my own terms.
There's something I genuinely appreciate in that: building a thing for yourself, first and foremost, and finding that others want to lean on it in their own lives too.
Building for the worker, not off them
Once the idea of a wider Hub started to feel real, I began to think bigger. Why not build the other everyday apps people depend on — the ride-share, the food-delivery — but built around the worker instead of around how much can be squeezed out of them?
I hate ads. I hate apps that phone home. And I didn't want to build something that depended on other companies' services — services that can change their minds, cost a fortune, or simply disappear and take your work with them. I wanted one system that was fully, genuinely mine, top to bottom.
The free-for-life idea
Here's a promise I care about, the one you'll see on the landing page: where I reasonably can, the essentials should be free for life for people who need them.
I understand struggle. If someone's doing it tough and they meet the criteria, the last thing I want is for the tools they rely on to add to the weight. Keeping the basics genuinely accessible for those people matters to me more than squeezing them.
How it stays honest
That only works if the money comes from somewhere fair. So here's the model, plainly: I don't make money by selling your data, and I don't make money by burying you in ads. When there's money to be made, it comes from people who choose to pay for more — more capacity, more reach — not from the people who just need the basics to work.
That's the whole idea. A system that answers to you, built by someone who needed it to answer to them first — and still the only one using it, for now.
How The Hub Ecosystems is built
By The Hub Ecosystems — 2026-06-28
We get asked how The Hub actually works. Here's an honest, non-technical-where-possible look at what's under the hood — and, just as importantly, why. (It's early days: The Hub is in active development, so some of this describes how it's designed to work as it opens up to more people.)
Run it where you want
This is the part that matters most, so let's be clear about it.
You'll be able to run your Hub on your own hardware — a Raspberry Pi, an old computer, a laptop, whatever you've got — as a fully self-managed, self-hosted system. In that case your data lives on your device, and nobody else is in the loop.
Or, if you'd rather not run anything yourself, you'll be able to have your Hub run as a managed service on our infrastructure. Today that's a VPS; as things grow it'll move into proper data-centre hosting. Either way, a Hub is designed to be locked to the person it belongs to — even when we host it, we're deliberately kept out of your content, to the point that we'd barely see so much as your email address.
Self-hosted or managed, it's your Hub. That's the whole point.
Built in Rust
The core of The Hub is written in Rust — a modern language known for two things that matter a lot when you're handling people's private data: safety and speed.
Whole categories of the bugs that cause crashes and security holes in other software simply can't happen in well-written Rust; the language refuses to compile them. That's a solid foundation to build trust on. And it's fast, so a Hub stays responsive without needing a wall of expensive servers behind it.
A lightweight, durable data store
We use SQLite to store data — one of the most widely deployed and thoroughly tested pieces of software in the world, the same engine that runs inside billions of phones. It's simple, rock-solid, and keeps your data in a form that's easy to back up and reason about.
Native apps where they count
For mobile we build proper native apps rather than wrapping a website in an icon. Native apps are faster, kinder to your battery, and can do things a webpage can't — background updates, notifications, real integration with the phone. Where a browser is the right tool we use the browser; where a native app is better, we build the native app.
Privacy is an architecture decision, not a checkbox
The promises we make about your privacy — set out plainly in our Privacy Policy — aren't marketing. They're baked into how the system is put together:
- There are no third-party ad or tracking scripts in the core apps. Nothing phones home to an ad network.
- Your data is designed to stay with you — on your device if you self-host, and locked to you if we host it.
- We don't intend to make money from your data or your attention. (And longer term, because you own your Hub, we may let you run your own ads inside your own Hub if you ever want to — with 100% of that money going to you, and only if you choose it.)
Built to be understood
None of this is meant to be a black box. We'd rather explain how things work than ask you to just trust us — which is exactly why this post exists.
Naturally, some details we keep private — the specifics of how accounts are secured, for example, aren't spelled out here. Good security doesn't depend on secrecy, but there's no reason to hand out a map either. What we can share, we will.
Want to follow along as it grows? Subscribe below.