Una: The Family Organizer I Never Meant to Build

Una was never supposed to become a product. It was meant to be a small app that made one demo work.

After building Deus Ex Machina, I wanted to see how much of my normal life I could hand over to an agent. Not just writing code or managing infrastructure. I wanted it to take care of something genuinely useful, so I started with our weekly grocery shopping.

I built a command-line interface for Oda that my agent could use to search for products, fill the basket, and even go through checkout. The problem was that the agent could do the shopping, but it did not know what we needed. That information was scattered across our family organizer, shopping lists, Signal messages, conversations, and the unreliable system commonly known as my brain.

Our organizer did not have an API or an MCP integration. And for the sake of the demo, I thought I would just build a small app that did.

Famous last words.

This was meant to be the supporting actor

The plan was simple: build a calendar, add some lists, expose a few tools to the agent, and return to the main experiment. Instead, my partner started using the first version.

Then our Signal conversation slowly turned into an issue tracker, except every ticket started with “Can we add this?” and was automatically assigned to me.

She became the designer and started shaping which features actually made sense. I would build something, she would try to use it in an actual household, and within a few minutes we would discover that my perfectly logical developer brain made absolutely no sense to a normal person.

The app started changing around how we really organize our home. A calendar event is rarely just a title and a time. A weekend trip needs a packing list. A school event has a document attached. A dinner plan creates shopping items. A birthday might have a gift idea, a reminder, and a person who does not even live in the household.

In real life, all of this belongs together. In most organizer apps, it lives in five different places.

So the little demo kept growing. Calendar, lists, notes, reminders, birthdays, attachments, and people became parts of the same plan. The name followed that idea: Ūna, from the Latin for one, together, as a single thing.

At some point I had to admit that I was no longer building a supporting tool for an agent demo. We were building the family organizer we actually wanted to use.

The problem was not really organization

While building Una, I spent time looking at how other households organize themselves. Everyone does it differently.

Some families live by the calendar. Some use enormous to-do lists. Some plan every dinner for the week, while others begin planning at 16:45. Some need school forms, shared custody schedules, or medication reminders. Others mainly want to avoid buying milk twice.

There is probably no universal system that works perfectly for every household, but nearly everyone has the same communication problem.

An appointment is mentioned during a phone call. A shopping item lands in the middle of a text thread. A school form is sent as a photo and disappears below three days of messages. One person thinks something was agreed. The other has no memory of the conversation.

The information exists. It just does not stay connected to the plan. That became the real purpose of Una: not simply to store more family information, but to stop the context around that information from getting lost.

Launching an app and then not marketing it

Una launched in June, which introduced the next technical challenge: marketing.

I am by no means a marketer, and I do not enjoy pushing apps into people's faces while telling them that this one will definitely change their life. So I used my finely tuned growth strategy and mostly did nothing.

I took the summer slowly, spent time with my family, and kept improving the app when something bothered us. Una had barely 30 active households, but that was fine.

Users or not, this app was going to live. It had become our daily driver.

Then summer ended, I was on parental leave, and most days I had a little time to read while the kid slept. One post on X led me down a rabbit hole about putting an entire website on Ethereum.

That rabbit hole became Ethereum, Render This: I Put an Entire React App Onchain.

It was a 15-minute deep dive into smart contract bytecode, EVM limits, immutable releases, and storing a React application across 24 contracts.

The creator of POIDH shared it, others followed, and the Reddit discussion took off. Traffic to this blog spiked, and people started clicking through to my other projects.

Una went from barely 30 active households to more than 500. New households are still joining every day.

Apparently the best way for me to market an iOS family app was to avoid talking about it and instead explain EXTCODECOPY to Reddit.

Task failed successfully.

A family organizer can see almost everything

We give family organizer apps an extraordinary amount of information.

The vendor can potentially know a lot about you. It can know that one of the kids has a dentist appointment, when it happens, and where the dentist is. It can see medical notes, travel plans, birthdays, school events, family routines, and the times when nobody is home.

Put enough calendar entries, lists, locations, and notes together and you do not just have productivity data. You have a full model of a family's life.

Yet we rarely treat it that way. We install an organizer, accept the privacy policy, and write down some of the most precious details about our children and our home. Because the app feels private, we somehow assume the company behind it cannot see those details.

But if the vendor stores the plaintext, it can technically read it. Maybe nobody looks. Maybe the company has good intentions and strong internal controls. But the household is still trusting its employees, service providers, logs, permissions, security practices, and future business model never to fail.

That is trust. It is not privacy.

I have written before about how we reveal far more than a service actually needs. With Una, this was no longer an abstract example involving identity documents or zero-knowledge proofs. It was our own children's appointments, our own locations, and our own family life. This part had to be built differently.

Building a backend that cannot read the app

The simple version is that sensitive household content is encrypted on the device before it reaches Una's backend.

I am sorry, but we have to go a little further into encryption jargon here. It can be boring, but privacy claims are easy to write on a marketing page. I would rather lay out what actually happens so you can decide for yourself how private this really is.

When a household is created, Una generates a 256-bit household key. That key is stored in Apple Keychain and can synchronize across the household owner's Apple devices through iCloud Keychain.

When someone creates an event or adds an item to a list, Apple CryptoKit encrypts the sensitive fields with AES-GCM before they are sent anywhere.

Sensitive household content is encrypted on the device before it syncs.

The plaintext household key never reaches the backend. Event titles, notes, locations, URLs, household names, people, birthdays, list names, list items, filenames, profile photos, and attachment bytes are all encrypted before upload. The backend stores the ciphertext and synchronizes it between authorized devices, but it does not have the key required to turn it back into readable content.

This means my own backend cannot tell me that Max has a dentist appointment.

It cannot tell me what is on someone's shopping list, where a family is traveling, what they wrote in a private note, or which document is attached to a school event. Support cannot open the database and reconstruct a household's calendar. I cannot use the content for analytics, search through it, or train a model on it.

There is an important distinction here. The backend does not know nothing.

A shared organizer still needs operational metadata to work. It may need to know that an event starts at 14:00 and ends at 15:00, which internal profile IDs are assigned, whether it repeats, or whether a list item is checked. It needs membership, invite, subscription, and synchronization state.

What it does not know is what that time block means.

Availability without the details.

That boundary matters. Una can coordinate the plan without building a readable database of the family's life.

There are trade-offs. If no trusted device has the household key, I cannot simply reset it from an admin dashboard and recover the encrypted content. That is less convenient than a system where the vendor secretly keeps everything needed to decrypt the data, but it is also the point.

Una has no ads, no cross-app tracking, no third-party analytics SDKs in the iOS app, and does not train AI models on household content. The complete version of what is encrypted, which metadata exists, and where the boundaries are is available in the privacy explanation.

Now add AI without ruining all of that

This is where the original idea came back and created a fairly obvious problem.

Una began because I wanted an agent to work with our household plan. But now I had deliberately built a backend that could not read that plan.

The easy AI integration would be to create a plaintext API, give an assistant access to everything and pretend the privacy architecture still counted.

Una does not ship with a built-in AI that automatically receives the household or its key. If a family wants an assistant to help, they connect one themselves and choose exactly what it is allowed to see and do.

A separate identity with a separate key

An assistant connection is not a household member. It receives its own identity, bearer token, public key, capabilities, resource grants, and activity history.

Capabilities and grants are checked separately:

• Capabilities decide which tools the assistant can use, such as reading calendar availability, reading approved event details, creating events, or working with lists.
• Grants decide which people and which exact lists those tools can touch.

An assistant might be allowed to find free time for two adults and add items to the grocery list. That does not give it access to a child's personal event, a packing list, household attachments, billing, invites, or every other piece of data in Una.

Calendar availability is also separate from event details. The assistant can learn that everyone is busy between 14:00 and 15:00 without receiving the title, note, location, or URL behind that block.

The cryptography is separate too. The assistant runtime creates a P-256 key pair. Its private key stays inside that trusted runtime. Una creates a separate agent-readable content key and wraps it to the connection's public key. The assistant never receives the household key.

Separate keys. Explicit access.

For reads, Una's hosted MCP endpoint returns encrypted payloads. Authorized decryption happens inside the trusted assistant runtime, not on Una's backend and not by pasting private keys into a model prompt.

For writes, the process works in reverse. The runtime encrypts the new event or list content with AES-256-GCM before it reaches Una. Every side-effecting tool requires an idempotency key, requests are bounded, and the backend stores only a SHA-256 hash of the connection's bearer token.

I published the provider-neutral Una SDK so compatible runtimes do not all have to invent this pairing, key unwrap, encryption, and tool handling themselves.

Choosing an assistant's role, capabilities, and grants in Una.

Encryption does not make an external assistant magically private

There is one boundary worth being extremely clear about. When a household authorizes an assistant to read something, that content is decrypted inside the assistant's trusted runtime. If the runtime then sends it to ChatGPT, Claude, or another hosted model, the selected plaintext enters that provider's environment.

Una's privacy policy cannot govern another company. Its storage, retention, processing, and model-training policies apply to the information it receives.

A fully local or self-hosted runtime can keep the approved plaintext inside infrastructure the household controls. But running only the connector locally while it calls a hosted model does not make the complete system local. The data still goes to the model provider.

Revoking an Una connection stops future calls. It cannot travel back in time and erase information an external provider already received.

This is why the access is scoped, reviewable, and revocable, and why Una shows the boundary before an adult creates the connection. Privacy here does not mean pretending information never leaves the device. It means the household chooses the assistant, chooses the exact information, and understands where it is going.

Where Una stands now

A connected assistant can find a time when selected people are free, create an agreed family event, turn a trip into a packing list, add groceries, store recipe links, or mark the items someone bought as complete.

The general reasoning happens in the assistant the household chose. Una provides the protected calendar, people, and list tools, then stores the agreed result without making the normal household readable to my backend.

That is where the project stands now: more than 500 households, an app my own family uses every day, and the agent integration that caused me to build it in the first place.

But Una is not an “AI family organizer.” It is a private family organizer that can let an assistant help without automatically opening the door to the entire household.

AI products often begin by collecting as much context as possible and working out the privacy story later. Una starts from the opposite direction. The backend should know as little as it can. An assistant should see only what it needs. The household should remain the one deciding where that boundary sits.

That is a much harder way to add AI, but for a family organizer, I think it is the only sensible one.

Explore Una or read exactly how assistant access works.