Zeddius

2026 to present. A solo project, in progress, with the source public on GitHub.

What it is

Zeddius is personal life software that I am building for myself. It tracks the parts of my life I want to understand better, starting with health and moving on to money and family, and it pulls in as much of that data automatically as it can.

Why I am building it solo

I have wanted to build software that helps people understand their lives and become who they want to be since I was a teenager. In 2023 I co-founded a startup with a friend, where we built an identity platform and a design system, and I learned a great deal doing it. I left in 2026 because I was not sure the direction matched what I wanted to build. The honest part is that I did not yet know what that was either, and it was not fair to expect a co-founder to build toward something I could not describe yet.

I needed time to explore and build, to find the right questions and work out what the real vision looks like. That is what Zeddius is. I am doing that exploration now, on my own, and watching the picture unfold.

The long-term vision

Zeddius is meant to become a socially-backed, identity-based behavior management platform. Most feeds show you who you scroll past. I want something that helps you decide who you want to be, and then keeps you honest about it.

You would describe yourself as a set of recurring behaviors: the person who sleeps well, trains three times a week, spends within a budget and shows up for their family. Zeddius would track your real effort toward that, reading from the same domains I am building now. A habit would not be another table to fill in. It would be a question asked of data that already exists.

The first obstacle in any self-improvement software is manual entry. It gets tiresome, it drifts out of sync, and it reflects reality poorly. So the first answer is automatic tracking: sleep and workouts from Apple Health, weight from a scale, and more sources over time. That is what I am building first, and it is useful on its own.

Making it social adds something new: incentives. When other people can see your record, or when something like financial backing depends on it, there is a pull to look a certain way whether or not the behavior happened. That says nothing about people being dishonest in their own tracking. It is what any shared scoreboard does. This is where verification matters. Automatic tracking does not need it, but once the data is worth gaming, it should not allow gaming.

The long-term answer is attestation: the device that observes the behavior takes responsibility for proving it. Picture a small sensor with a computer inside, running a local AI model to infer what happened, such as a workout or a meal. A hardware security module or secure element in the device signs the result. Those chips cannot be tampered with, so a valid signed payload can be trusted to have come from that device. How the device works out what happened is up to it. If the model is accurate enough, the data is hard to spoof.

It would be private by default. Visibility would be decided field by field, and nothing is public until you choose to share it. Friends and family would see the effort you chose to show, and their encouragement would push toward your goals rather than toward time spent in the app, which is the failure I am building in reaction to. Verified data is also what would let outside parties, such as insurers, attach real incentives to healthy behavior, though that is far down the road.

None of this exists yet, and none of it is on a schedule. Everything below is the foundation: the tools I use myself, built so that data can later be proven, queried and shared.

What exists today

• A Rust API (Axum, Tokio, sqlx, Postgres), live on Cloud Run in separate development and production environments, with interactive docs at api.zeddius.com/docs.
• Authentication written from scratch, with no third-party auth service: Argon2id password hashing, opaque bearer tokens (32 bytes of entropy, only the hash stored), refresh tokens that rotate on use, session listing and revocation, rate limiting, email verification, password reset, and Sign in with Apple.
• Authorization checked by the compiler: two request types, one that proves identity and one that also requires a verified email. Touching domain data as an unverified user does not compile.
• CI/CD with no long-lived keys: GitHub Actions with OIDC and Workload Identity Federation, and a three-workflow deploy pattern from development to production. The iOS app ships to TestFlight the same way, through fastlane.
• An iOS app in TestFlight, which is a first version that I am rebuilding, and a web app with sign-in and registration that I am bringing up to match the API.

How it fits together

Two clients talk to one API. The API is the only thing that touches the database, and it is the only authority on who a user is. Everything it needs to run, from the database address to the email key, comes from Secret Manager.

How sign-in works

I wrote authentication from primitives instead of adopting a framework, partly to learn it and partly so that every decision would be visible in the code. A few details I am glad I got right:

• Verifying Sign in with Apple means fetching Apple's public keys. The API caches them for an hour, and when several requests miss the cache at once they share a single fetch.
• Email addresses are unique only once verified. Registering with someone else's address does not lock them out of it.
• Forgot password always answers 204, so it cannot be used to find out who has an account. A reset revokes every session on the account in the same transaction.

Step through the life of a session below.

Roadmap

The order follows my own needs, so it will shift as they do. Health comes first, then money and family. The rest comes later.

Repository map

Every public repository behind Zeddius, all in the zeddiushq organization.

• zeddius-apiBackend for the zeddius project: the Rust and Axum API, with authentication written from scratch.
• zeddius-appleThe SwiftUI iOS app, shipped to TestFlight.
• zeddius-webThe Next.js web app: sign-in, registration and, next, the password and email flows.
• github-actionsComposite GitHub Actions, including the Workload Identity Federation setup.
• zeddius-landingThe zeddius.com landing page.