Skip to content
Unbound
Home

Unbound: Vision

Status: Published Last Updated: 2026-03-09

The Problem

Your users’ digital life is fragmented across dozens of proprietary silos. Messages live in iMessage, WhatsApp, Slack, Discord, and Telegram. Emails sit in Gmail or Outlook. Calendar events, phone calls, personal notes, and professional conversations are all trapped in separate systems that don’t talk to each other.

This fragmentation has real consequences:

  • No unified view. You can’t see your full day — the Slack thread, the follow-up email, the WhatsApp message, and the calendar invite — as one coherent stream of interaction.
  • No cross-platform search. Finding a conversation means remembering which app it happened in.
  • No identity coherence. The same person exists as a phone number, an email address, a Slack handle, and a WhatsApp contact — with no connection between them.
  • No foundation for tooling. AI assistants, dashboards, and personal analytics tools can’t access some of the most powerful data to improve the product for users.

The data exists. They generated it. But it’s not theirs in any meaningful, usable sense.

The Thesis

The missing piece is not another app, it’s infrastructure.

Every attempt to solve personal data fragmentation has jumped straight to building end-user features: a search bar, a chatbot, a timeline. These products treat the data model as an implementation detail — a means to an end-user experience.

Unbound inverts this. The data model and API are the product. With the right infrastructure — ingestion, normalization, entity resolution, indexing — Unbound unlocks an entire category of tools that couldn’t otherwise exist. AI assistants that can actually know everything your users would like them to know. A view of their day that spans their full digital life. Search and personal analytics that just work, simply and blazingly fast.

The conviction: a standardized, performant, queryable data layer for personal data is the blocker for a new class of user experience. Everything else runs through this.

What LifeDB Is

LifeDB is a backend data layer for capturing, normalizing, and efficiently querying personal data. It provides an optimized API with a focus on performance, privacy, and security.

Core Capabilities

Ingestion. Pull data from the services people actually use — messaging apps, email providers, calendars, phone call logs, note-taking tools — through integrations that make it as easy as possible to get data in. The value of the system scales directly with how much data it can access.

Normalization. An iMessage, a Slack DM, and a WhatsApp message are all instances of the same underlying entity: a message between people in a conversation. LifeDB defines a canonical data model that represents personal interactions across platforms in a unified schema. Platform-specific metadata is preserved, but the core semantics are standardized.

Entity Resolution. The same person appears across your digital life as a phone number, an email address, a Slack username, and a Discord handle. LifeDB resolves these into unified identities, building a personal contact graph that connects interactions across platforms.

Temporal Indexing. All interactions are indexed by time, enabling queries like “everything that happened on Tuesday” or “all interactions with this person in the last month” — regardless of which platform they occurred on.

API. A clean, performant API that makes the unified data queryable. Optimized for the consumers that matter: AI agents, personal dashboards, automation tools, and applications that need rich personal context.

What LifeDB Is Not

  • Not an end-user application. No built-in UI, no chatbot, no timeline. Those can be built on top.
  • Not a data sovereignty protocol. Not trying to change how the internet works or establish new standards for data portability. Pragmatically pulls data from services as they exist today.
  • Not an enterprise product. Built for individuals and their personal data, not for companies managing customer data.

Principles

Privacy and Security Are Prerequisites

The data LifeDB stores is maximally sensitive: private messages, phone calls, emails, personal notes. Privacy and security are foundational prerequisites for the system to exist. If people don’t trust the system, they won’t give it their data, and the system has no value.

This means:

  • End-to-end encryption is non-negotiable
  • The architecture must support self-hosted deployment from day one
  • Security decisions are never traded off against convenience
  • Data access controls must be rigorous and auditable

Infrastructure First

LifeDB solves the data problem. What gets built on top of that data — by us or by others — is a separate question. The data model and API must be good enough to support use cases we haven’t imagined yet. This means:

  • The schema is designed for generality, not for a specific application
  • The API is designed for multiple consumers, not one UI
  • Performance and query flexibility are first-class concerns

Ingestion Must Be Easy

The system is only as valuable as the data it contains. Every friction point in getting data in — complex setup, flaky integrations, manual steps — directly reduces the system’s value. Ingestion has to be dead simple for your users to authorize and syncs must not get in the way. Auth it and forget it.

Why Now

Two shifts make this moment different from previous attempts at personal data unification:

AI needs context. Large language models are powerful but context-starved. The most immediate, high-value consumer of a unified personal data API is an AI assistant that can actually understand your full context — who you talked to, what was discussed, what’s on your calendar. The AI wave creates urgent demand for exactly the infrastructure LifeDB provides.

Integration is more tractable. Many services now offer richer APIs, export tools, and data portability features (driven by regulation and competition). The ingestion problem is more solvable than it was five years ago.

Users have gotten used to sharing their data. Most users are now willing to share data when it’s easy, and when they see the benefits; the norms have evolved.

Scope

Initial Focus: Communication and Interaction Data

LifeDB’s data model is designed to be general; the focus is on the data types that matter most for understanding a digital life:

  • Messaging — iMessage, WhatsApp, Slack, Discord, Telegram, Signal
  • Email — Gmail, Outlook, and other providers
  • Calendar — Events, meetings, scheduling
  • Phone calls — Call logs and metadata
  • Notes — Personal note-taking tools and docs

This is not an exhaustive list. The architecture will accommodate new data types without schema redesign. But communication and interaction data is where the fragmentation problem is most acute, and where entity resolution adds the most value.

What’s Explicitly Out of Scope (For Now)

  • Health and fitness data
  • Financial data
  • Location/travel data
  • Media libraries (photos, music)
  • Social media posts and feeds

These are valid future extensions, not current priorities.

Strategy

Landscape

Go-to-Market

  • GTM Strategy — Audience segments, value prop hypotheses, and demand validation experiment

Documentation