SASS-E

The thesis

Personal AI assistants today are a collection of disconnected apps. You have one app for money, another for fitness, a third for language learning, a fourth for your smart home. Each one knows a slice of you. None of them know how those slices fit together.

SASS-E is built on a simple bet: the connections between hubs are the product. Not the hubs themselves.

Money tracking that notices when your spending spike correlates with stress data from the wellness hub. A learning hub that picks language conversation partners based on which countries your IoT activity says you're planning to visit. A wellness hub that flags patterns the user can act on, by correlating signals across the whole platform.

The architecture problem

This thesis creates an immediate engineering challenge: to make cross-hub insights work, you need a lot of data. To get users to trust you with that data, you need to prove the data is safe. Those two goals fight each other.

I solved it with a dual-database architecture and zero-knowledge envelope encryption on the sensitive hubs.

Two databases: a Railway MySQL instance for admin and shared metadata, a Supabase instance for user data with row-level security from day one. Vault unlock happens client-side, with a bridge that captures the user's password during login and re-wraps the DEK on password changes.

The five hubs

Voice Assistant

The hard part isn't streaming responses. It's keeping the per-message cost low without making the assistant feel stateless. My Skills Manager injects only the context relevant to what you actually said, so the prompt stays small but the assistant still feels like it knows you.

Money

Budget tracking, expense categorisation, financial insights. Vault-protected. The server sees nothing but ciphertext, but the cross-hub correlation engine can still do its work, because the decryption happens client-side before any analytics run.

Wellness

Health metrics tracking and pattern recognition. The same vault encryption as Money. Wellness data is some of the most sensitive a user can give a platform, and putting it behind a vault the operator literally can't open is the only way to do it ethically.

Learning + Translation

Two hubs that explicitly talk to each other. The system notices which phrases you stumble on in real-time translation calls, then routes them back into your learning queue for the next session. The translation hub also feeds into the wellness hub when stress markers appear in someone's voice patterns.

IoT

Unified device control across whatever smart home gear you've accumulated. The interesting work isn't the protocol bridging, it's the cross-hub logic. One action that's good for your comfort, your sleep, and your bill.

The trust-building problem

SASS-E's biggest design challenge isn't technical. It's psychological. Cross-hub insights only work if users actually give the platform enough data, which requires trust. Trust requires a "wow moment" where the platform tells you something you didn't know you knew. That wow moment requires data the user hasn't given yet.

The onboarding is built around this loop. The first vault setup is the "this is why your data is safe" moment. The first cross-hub correlation is the "this is why it's worth giving" moment. Both have to land in the first session, or the user bounces.

What I learned

I started SASS-E with a list of hub features and ended up with a list of hub connections. The features turned out to be the easy part. The hard part was making the platform feel like a coherent nervous system rather than a dashboard.

Also: vault architecture is a privacy feature, but it's also a forcing function. Once you've committed to never seeing user data, you stop building features that depend on you having it. That ends up improving the product, not constraining it.