xos chat

The story

I've been working on a personal project as a way to show how I approach a product as a whole: deciding what something is, what it will never be, and how decisions get made when I'm no longer in the room.

The name. The logo. The domain. What the product stands for. Which features belong in it. How to explain its behaviour before writing the code. How to make decisions understandable to someone who wasn't there when they were made. And when to share the work, even when it's nowhere near finished.

Here's what that looks like.

The idea: starts with a principle, not a feature list

Some products start with what they do. I started with a principle: ownership.

If AI apps like Whisper AI can run smaller models locally on a device, could messaging work in a similar way too?

That question became the starting point. The product took shape around a simple idea: two people communicating, with nothing in between.

A principle is useful because it can answer questions nobody has asked yet.

Even the visual identity became a way to test the idea. Could the logo communicate the product without needing an explanation? If I'd struggled to design one, it might have revealed something about the clarity of the idea itself, rather than simply a problem with the design.

The aim wasn't just to define a set of features. It was to find an idea clear enough to guide decisions I hadn't made yet, and coherent enough to carry through the whole product.

That includes the technical decisions, even though they're not all resolved yet.

The intention is for messages to live on users' devices, with the relay handling them temporarily rather than becoming a permanent store of conversations. I'm also thinking about access: can people use the product without having to depend on a gatekeeper? The decision framework gives me a way to evaluate technical choices as the implementation develops. Does a solution uphold the principle, or quietly undermine it? It won't answer every engineering question, but it helps keep those decisions honest from the outset.

The same principle shaped the website. It's the first part of the product many people encounter, so I wanted it to reflect the same approach to trust and user control. Including visitor tracking would have felt inconsistent with the experience I wanted to create.

Analytics might be useful when developing a product, but collecting information about visitors wasn't necessary to explain or demonstrate this idea. I wanted the principle of user ownership to shape more than the product itself, so I chose not to.

That's the value of having a clear principle: it doesn't just help me choose between competing options; it helps establish which options make sense to consider in the first place.

The North Star: a decision tool, not a slogan

A lot of North Stars are slogans. They sound good on a wall and never settle an argument.

I wanted one I could actually use.

Mine is three words: Your words, always.

The test is simple: does a decision keep a person's words in their hands? If the answer is no, or even unsure, the idea needs more thought.

A good North Star should be short enough to remember, specific enough to say no with, and uncomfortable at times. If it never stops you from doing something you wanted to do, it isn't doing its job.

But a principle alone isn't enough. It's possible to make almost any idea sound compatible with a sufficiently broad statement. I needed a way to make the principle actionable.

The Double Gate: making good decisions repeatable

I added a second gate that describes the product plainly: Text only. Two people. No server.

One expresses the principle. The other defines the product's boundaries. Every proposal has to pass both.

The point isn't the constraints themselves. It's what they could make possible for a team.

An engineer, a designer, or a stakeholder with an idea would have a shared way to evaluate a proposal before investing time in it. The goal is to make decisions less dependent on whoever is most senior or loudest in the room.

The aim is to make the reasoning explicit enough that anyone else can evaluate an idea, challenge a decision, or contribute something new without having to reconstruct the product's intent from scratch.

The framework hasn't been tested across a team yet. But designing it now means I'm thinking beyond how I make decisions today, towards how the product could accommodate more people tomorrow.

That's the kind of thinking I want to bring to teams: not only building the thing well, but helping establish the principles that make it easier to decide what is worth building.

Working backwards: order is a decision too

The FAQs came first. Then the website. The website went live before the app was ready. That was deliberate.

Writing plain-language answers before writing code is a way to test whether you've actually designed something. A vague answer means a vague feature.

One question forced a rethink of a core feature: what happens when someone blocks you?

The original design let the person doing the blocking decide whether to keep or delete the existing conversation. But when I tried to explain that behaviour honestly to the person being blocked, I realised the problem. Their messages could remain on someone else's device indefinitely, with no way to withdraw them.

That couldn't coexist with Your words, always.

The answer was mutual automatic redaction: both people's messages are removed from both devices when either person blocks the other.

The FAQ hadn't just clarified the feature. It had exposed a contradiction in the product itself.

Fixing a paragraph costs minutes. Discovering the same problem after shipping costs much more.

Notifications presented a different challenge. Message previews are useful, but push notifications pass through infrastructure outside the app itself. Including message content, sender names or even message counts would expose information that the product is designed to keep under the user's control.

So notifications carry nothing. The words stay in the app, rather than being included in a notification payload.

It's a small design decision, but one that follows directly from the principle: convenience shouldn't quietly undermine ownership.

Launching the website early also meant committing to the promise in public before the app was ready. The app's job then became living up to what had already been said, with every build decision checked against it.

Sequence is part of product thinking. What you do first decides which mistakes stay cheap.

Sharing the work is a decision too

There's also a reason I'm sharing before it's finished.

If I waited until the app was polished, people would see the outcome, but much of the thinking that shaped it would be invisible. The name, the principles, the constraints and the decisions would look like a series of things that had simply fallen into place.

Sharing the work as it develops gives me an opportunity to show the reasoning behind those choices, including the things that change along the way.

It's also a decision about what I'm trying to demonstrate. I'm not asking people to judge a finished product. I'm sharing how I approach defining it, making decisions about it, and connecting those decisions to what eventually gets built.

The timing matters. So does what I choose to share. The product is still in progress, but the thinking is already there to examine.

The work around the product

Looking back, the app is only one part of what I've been building.

I've established the name and secured the domain. Designed a visual identity. Defined the North Star and the Double Gate. Written the FAQs, built the website and put it live. And alongside all of that, app development continues.

Each piece serves a different purpose, but none exists in isolation. The name and visual identity establish how the product presents itself. The principle and decision framework help determine what belongs in it. Starting with the FAQs helps me, and eventually developers, designers and stakeholders, imagine how the product will actually work while decisions are still cheap to change. The website communicates the idea before the app is ready.

Why this matters

For me, the interesting work extends beyond implementation: defining the idea, expressing it, establishing principles, testing decisions, choosing what to do first, and making the reasoning clear enough for others to follow.

Even when I'm working on a narrow slice of a product, I'm thinking about the bigger picture: the outcomes we're working towards, the possibilities we haven't considered, and the opportunities to improve what we're building.

Like any side project, this one still has a way to go. But whatever comes next, I think there's value in sharing the process: how an idea takes shape, how decisions are made, and how the two connect.