Buildingfortwo

Almost every piece of technology built in the last thirty years has been designed for a single user.¹ One account, one interface, one person's goals. Even social platforms—ostensibly about connection—are built around the individual experience. You have a feed. You have a profile. Your relationship is incidental to the product.

Relationships are not always symmetrical. Some involve coercive control, personality pathology, or abuse. Our system does not assume equal footing where it does not exist. From a design perspective, the central question is not just what the system can detect, but how that detection is presented without distorting the relationship itself. Interface choices can amplify or reduce tension.

Good design in this context is less about visual polish and more about interaction ethics. A prompt delivered ten seconds too early can escalate a conflict; a useful insight delivered with the wrong certainty can be interpreted as judgment. We therefore treat timing, confidence, and reversibility as first-order design primitives.

This also means that silence is often a valid product decision. Choosing not to intervene can be more responsible than forcing feedback into moments where neither partner can process it constructively.

Relaic is built for the space between two people. That's not a metaphor. It's a structural choice that changes almost every design decision we make. Authentication is joint. Consent flows are bilateral. The data model is dyadic. The output is relational, not individual.

We therefore treat product behavior as part of the intervention. Timing, wording, and confidence cues all shape whether feedback is experienced as supportive, intrusive, or neutral.

This is why we evaluate design decisions against both usability criteria and relational outcomes, not just completion metrics.

To make this practical, we prototype at the level of conversation turns: what appears, when it appears, and what follow-up options are offered. Small interaction details materially change whether a tool supports reflection or provokes defensiveness.

This creates real design problems. How do you handle disagreement about whether to use the system at all? What happens when one partner wants more data visibility than the other?² How do you design a UI that doesn't inadvertently privilege one voice over another?

Design constraints become system constraints: bilateral consent, reversible actions, and explicit boundaries on interpretation. These are not decorative ethics principles; they are implementation requirements.

When these constraints are absent, systems drift toward convenience-driven defaults that may optimize short-term engagement while undermining long-term trust. Constraining the system is therefore part of making it usable, not a tradeoff against usability.

We don't have final answers to all of these questions. But we've built the infrastructure to ask them properly—and to iterate on the answers as we learn from real couples in real use. That's the work.

As the product matures, the most valuable design work will likely be in edge cases where intent is ambiguous and emotional stakes are high. Precision in those moments matters disproportionally.

We expect future iterations to focus on exception handling and recovery flows, because that is where relational products either become genuinely supportive or quietly harmful.