The engineering principles behind Seldeo

The team shape

Seldeo is built by a small team. That makes focus a product requirement: each decision must improve something people can feel, such as reliability, privacy, accessibility, or speed. We do not confuse complexity with progress.

Almost every engineering question therefore comes down to the same test: does this help a small team deliver a big product without cutting corners on what matters? The principles below are how we answer that.

Principle 1: One experience across devices

Seldeo serves people on iOS and Android with the same core features, privacy controls, and quality bar. A conversation, call, story, or safety action should behave predictably regardless of which supported phone someone carries.

Platform-specific differences still matter. We account for the permission model, accessibility behavior, background limits, and interaction conventions of each operating system. Consistency means a shared promise, not forcing every device to look identical.

Principle 2: Spend engineering time where users feel it

Account access, media delivery, notifications, calls, and data protection all need to be dependable. We use carefully assessed service partners where they improve availability or coverage, while Seldeo remains accountable for the user experience and the protection of user data.

We assess each service against three questions:

1. Does it materially improve a user-facing capability?
2. Can Seldeo preserve control of user data and continuity if the relationship changes?
3. Does its privacy, security, and compliance posture meet the obligations we make to users?

The providers that process personal data are identified in our Privacy Policy. That legal disclosure is the authoritative list.

Principle 3: Own the security boundaries yourself

Some decisions cannot be delegated. Seldeo owns the rules that govern who can access an account, message, call, post, or private audience. Encryption, user isolation, credential protection, abuse resistance, and request-integrity controls are designed and reviewed against the promises we make.

The rule of thumb: a service partner may help deliver a capability, but never makes Seldeo's trust decision. The rules that decide who can access what remain Seldeo's responsibility (see the E2EE messaging post and Recovery, step-up, and passkeys for concrete examples).

Principle 4: Operational controls from day one

Features that depend on external services can be paused or limited quickly when reliability, safety, or compliance requires it. These controls let us protect the rest of the product during an outage and expand a new capability in measured stages.

The value appears on the difficult day: people keep access to the parts of Seldeo that are working, and the team can respond without waiting for a new app-store release.

Principle 5: Careful rollouts aren't experiments

We introduce meaningful changes in stages: first to the team, then to a limited audience, and then more broadly once quality and support signals are healthy. This is a safety practice, not a way to turn every user into an experiment.

The reason: our feed ranker target is not engagement. A/B testing for engagement is a very effective way to accidentally build the loudest product; we would rather deliberate over changes and be occasionally wrong than optimise our way into a different company.

Principle 6: Fast, private web pages

The corporate website — the one you're reading — is built to load quickly, remain useful on constrained networks, and respect readers without behavioral tracking. Its content and presentation are delivered by Seldeo, with no ad slot or cross-site profiling on the corporate surface.

The outcome is simple: pages open quickly, browser and accessibility preferences remain effective, and fewer outside services are involved in a visit.

Principle 7: Reviewed, accountable content

Every news article, help-center page, legal notice, and product page has a review history and a clear owner. Copy changes are checked alongside the experience they describe, and related updates publish together.

That gives us three useful guarantees:

• Changes are reviewable. Help and policy updates receive the same care as product updates.
• Corrections are recoverable. We can identify what changed and restore the previous approved version.
• Publication is coordinated. Explanatory copy and the behavior it describes can change together.

Principle 8: No premature scale

We are deliberate about solving the problems people actually encounter. Reliability work is driven by measured bottlenecks, observed failure modes, and realistic growth plans rather than imagined complexity.

The rule of thumb: solve the problem you can measure, not the problem you can imagine. Almost every "we might need this at scale" decision we've deferred has stayed deferred. Almost every "we might need this at scale" decision we've taken has turned out to be a distraction from something more important.

Principle 9: Publish the receipts

For anything user-facing that is easy to hide behind opacity — the ranker (see A quieter feed), the safety model (see The trust and safety model behind Seldeo), notification policy (see Notifications, restrained) — we publish the specifics in advance. This is a deliberate discipline: publishing forces us to keep the product's behavior aligned with the promise.

If any of the specifics on this site ever drift from the actual behaviour of the app, someone will notice — either inside the team or outside — and we'll be embarrassed into fixing the drift.

What we don't do

• We don't use A/B testing as a decision-making tool — see Principle 5.
• We don't run behavioural nudges — no engagement streaks, no "your friend just posted, go react?"
• We don't publish unreviewed product or policy copy.
• We don't use third-party behavioral tracking in the mobile app. The measurements we need are scoped to what the product actually requires and disclosed in the Privacy Policy.
• We don't add operational complexity without a measured reliability, privacy, or performance benefit.