How we decide what to build, and what not to.

1. Privacy is architectural.

Privacy is not a paragraph in a policy. It is a property of the system: where data lives, who holds the keys, how long it is retained, what touches it on the way through. When privacy is treated as a downstream concern — a clause to draft after the product is built — it is structurally too late.

We design data flows before we design features. If the only way a feature can be implemented requires us to see customer content we don't currently have access to, we either redesign the feature, or we don't build it. The end-to-end encrypted parts of our products are not a marketing position; they are the result of having said no to a small number of conveniences over a long period of time.

2. Boring is a feature.

The longer a piece of software lives, the more its dependencies become liabilities. Every framework, build tool, and cloud service in your stack is something that can break, change terms, get sold, get deprecated, or simply require a migration on someone else's schedule.

We choose tools the industry has already stopped arguing about. That usually means vanilla web fundamentals on the client, a mature server-side runtime, and a relational database. We will pick a technology twenty years older than its trendier alternative if the older one will still build cleanly in 2035.

The cost of "boring" is felt in the first month of a project. The benefit is felt in every month after that.

3. Smaller surface, sharper focus.

The default temptation, with any product, is to add. Each feature seems individually defensible; the cumulative weight is what kills the product. We treat additions as expensive.

A feature should answer three questions before it ships:

• Does it serve a need we can describe in a sentence?
• Will it still be the right answer to that need in two years?
• If it stays in forever, is that a future we want?

Most candidates fail at least one. The ones that survive tend to become structural — they earn their position rather than rent it.

4. Own what matters.

We host our own infrastructure where the work demands it. We avoid lock-in to platforms whose terms we cannot influence. We keep an export path open for every piece of customer data we hold, so that a customer who wants to leave can leave with their work intact.

Ownership is not the same as building everything from scratch. It means knowing which dependencies are load-bearing and being prepared to replace any of them on our own timeline rather than on someone else's.

5. Engagement is not a goal.

We do not build for time-on-app. We do not build for daily active usage as a primary metric. We do not build features whose purpose is to bring the user back when they would otherwise have moved on with their day.

A successful product fits cleanly into the rhythm of someone's life. The right amount of time spent in our software is the smallest amount that still does the job.

6. Read your own logs. Answer your own support.

The team that ships the software should be the team that hears from the people using it. Layers of intermediation between the builders and the users degrade both — engineers stop knowing what's actually happening, and users stop being heard with the precision required to fix what's wrong.

We are small enough that there is no layer between the people building the software and the people using it. We intend to stay that way.

7. Plain language.

Our documentation, our terms of service, our privacy policies, and our release notes are written to be read by the customer. We do not hide consequential terms in legalese. We do not describe an opt-in by saying "we may." We say what the system does, in the words a person would use.

What this rules out

These principles are not symmetric. They mean we will not be the studio that ships fastest, scales widest, or chases the newest framework. We will not build the surveillance product, or the engagement-loop product, or the product whose business model depends on customers not understanding what they agreed to.

We are aware that this narrows our addressable market. We consider the narrowing to be the point.