Bonds: a relationship platform built for two people sharing one account
Bonds turns relationship growth into a daily practice. We built the platform behind it: the data model that keeps two people separate and together at the same time, the AI coaching layer and its clinical guardrails, the personalisation engine, and the infrastructure it runs on.
- 12 modules
- 2 privacy tiers
- 1 shared record per couple
- 1 enforcement point
What the platform does
Relationships are put under pressure by ordinary weeks rather than by dramatic events. Conversation gets crowded out, communication becomes reactive, and small unresolved things accumulate.
The products available did not help much. Content libraries gave every couple the same advice. Therapy is valuable and episodic, and for many people it is not available as daily support.
Bonds is built on one idea: relationships are built through consistent small actions rather than occasional grand gestures. That produces three pillars.
A psychologist-designed curriculum covering communication, trust, intimacy, attachment, emotional intelligence and conflict. Sequenced to what a particular couple needs next rather than shelved as a library.
One small exercise a day, sized in minutes. An exercise that needs a good evening only happens on good evenings, and the weeks that matter most are rarely the good ones.
A visible record of milestones, reflections and progress. Accumulated progress is the one motivator that grows stronger over time while every other one decays.
Around those sit daily check-ins, shared goals, guided conversations, and Dr. Leo, an AI relationship coach available between the moments a therapist is not.
- Client
- Bonds, an AI relationship wellness platform for couples
- Product
- Two-person shared-account consumer platform, web and mobile
- Our scope
- Product architecture, couple data model and privacy tiers, AI coaching layer and clinical guardrails, personalisation, engagement systems, cloud infrastructure
The one fact that shaped everything
Three parties have to be served by the same data model, and they want different things.
With a private space the other does not reach. This is where the honest material lives, and it is only honest because it is private.
With its own state that both partners write to, from two devices, sometimes in the same second.
Whose frameworks constrain what the AI is permitted to say, and whose boundaries have to hold in features built long after those boundaries were set.
Serve only the individual and there is no shared practice. Serve only the couple and the private space collapses, and with it the candour that makes the data worth anything. A clinical boundary is only worth setting if the data underneath it was gathered honestly in the first place.
The four decisions that mattered
If you read nothing else on this page, read this.
Every record is classified as shared or private at creation, and enforced where data is read.
One authoritative shared record rather than two copies that drift apart.
A bounded profile rebuilt in the background, not a growing transcript sent with every question.
There is no error state for a well written response to the wrong kind of message.
Privacy is decided at the point of writing
Bonds holds some of the most sensitive material a consumer product can hold. Emotional states, private reflections, conflict history. Things one partner has written down precisely because they have not yet said them out loud. Some is shared and some belongs to one partner alone, and the two sit side by side in the same product, feeding the same AI.
Enforce that split where data is displayed, and every read path has to remember it. Read paths multiply as a product grows. A dashboard aggregate. An AI context assembly. A notification on a lock screen. A timeline entry. An export.
Nothing errors. A screen renders. There is no exception for this user should not be seeing this, so the first detector is the person reading it.
A partner reading the other's private reflections is not containable, because the harm happens at the moment of reading.
Every future feature, written by someone who has never read this document, is another independent chance at the same mistake.
Every record is classified as shared or private when it is created. Access rules govern what a given user's queries return at all. A screen that forgets to filter does not receive the records and hide them. It does not receive them.
Context draws on the shared tier plus that partner's own private tier. One partner does not reach the other's private material by asking the coach about it, which closes the most obvious side channel in a product with a conversational interface over a shared dataset.
Nothing private renders on a lock screen. The lock screen is the least controllable surface in a mobile product, and in a relationship product the person most likely to be looking at it is the one partner who must not.
With an audience of two, aggregation is not anonymisation. Show a couple-level average of this week's emotional check-ins, and a partner who knows their own score knows a great deal about the other's. Every couple-level statistic over private inputs carries that property.
So couple-level statistics over private inputs are constrained such that a partner's own figure does not fall out of them. Where a metric could only be shown at the cost of that property, it is presented as trend and direction rather than as a figure. The couple still sees where the relationship is going. Neither partner gets an oracle pointed at the other.
Privacy holds because of where it is enforced rather than because every future feature remembers.
Partners write honestly in their private space. A dashboard that leaks turns every future check-in into a performance, and the personalisation engine starts learning from a curated version of the relationship.
The shared dashboard can show a couple their real trends without becoming a lookup for one partner querying the other.
The most sensitive material in the product travels the shortest distance it can, and does not leave with a name attached.
The couple is the unit of state
Bonds is used by two people as one unit, on two devices that neither know nor care about each other. One partner marks a shared goal complete on a phone during a commute. The other, at the same moment on a laptop, edits that goal's target date.
Under naive last-write-wins, one of those actions disappears silently, usually the more meaningful one. The partner who marked it done sees it undone on the next refresh, and reasonably concludes their partner undid it.
A shared streak incremented by reading the current value and writing back a higher one is a textbook lost update. Two devices read three, both write four, and a couple who did two days of work has one day of credit. The streak is the reinforcement mechanism.
Two copies that reconcile is worse: two versions of the same relationship, drifting apart, each partner looking at a different account of what they have accomplished together.
Shared activities, goals and milestones live in one couple record. Every change goes through a backend workflow, so concurrency handling, validation and propagation exist once.
Completion is monotonic. Counters and streaks are incremented server side. Free text resolves last-write-wins with the superseded version retained rather than discarded, so a partner's words are not lost to timing alone.
Coaching grounded in this couple's own history
Hand a language model a question and nothing else and it returns something plausible, well written, and about nobody in particular. That is a content library with a chat window on it, which is precisely the product Bonds existed to be better than.
The obvious fix is wrong. Sending full history with every request makes cost and latency scale with tenure, buries relevant signal in months of routine check-ins, and sends far more sensitive material to a model provider than any single question justifies.
Check-in history, recurring themes, active goals, recent completed activities and relationship stage are distilled into a compact derived profile. A couple two years in sends the same volume of context as a couple two months in.
The profile is rebuilt by background work as new signal arrives rather than assembled at question time. By the time a user asks something, the context is already sitting there.
Written with the psychologists, held centrally. Improving one improves every surface that uses it without a release. Every recommendation records which signals produced it.
Guidance reads as recognition rather than advice, because it references what this couple has actually been going through.
Cost and latency per interaction stay flat as history grows, so the most engaged couples are not silently the slowest and most expensive to serve.
A bad recommendation is diagnosable. Because the inputs are recorded, it is possible to tell whether the model reasoned poorly or the profile fed it the wrong picture.
Less sensitive material leaves the platform. A compact derived profile ships considerably less than a transcript of everything a couple has ever written down.
The AI is classified before it generates
Almost every message this product receives is what it is for: a communication problem, a recurring argument, a partner who has gone quiet. Occasionally one is not. Something serious, typed into a free-text reflection box late at night, because that is where this person happens to be writing things down.
A coaching model will answer that message. Fluently, warmly, and at length, because answering is what it does and it has no reliable sense that this one is different in kind. There is no error state for a well written response to the wrong kind of message.
Keyword blocklists were considered and rejected early. They miss anything paraphrased, fire on a user discussing a film or a friend's situation, and carry no notion of severity, so they over-block ordinary conversation and under-block the messages that actually matter.
Input is classified ahead of generation, so the decision about what kind of message this is gets made before the model has committed to answering it as coaching. The ordering is the whole point.
Messages outside what coaching should address take a designed path, with content reviewed by the clinical advisors, oriented toward appropriate professional help. It is not a refusal and not a fallback.
Applies tone and scope to everything the AI produces, in every feature. A boundary agreed once holds across the coach, the growth plans, the conversation prompts and the insights, including in features built afterwards.
Expressed as configuration rather than buried in application logic, so adjusting it is a clinical decision rather than an engineering release.
The constraints we designed around
Products carrying real emotional weight and real AI dependency meet constraints. Some come from the domain. Some appear as usage accumulates. Some are imposed by the product's own positioning.
Building for all of them on day one is not prudence, it is waste, and in a consumer product it is usually fatal waste, because runway spent building for scale that never arrives is runway not spent finding out whether anyone wants the thing.
Personalisation had to feel instant
A model call is measured in seconds. An interaction that feels instant has a few hundred milliseconds. Running personalisation inline puts a multi-second wait in front of opening the day's action, loading a check-in and viewing the dashboard, which are exactly the interactions the product depends on.
Compute-heavy analysis runs in the background. The day's action, current insights and relationship profile are generated ahead of need and cached. The morning open is a database read rather than an inference. Provider calls are batched rather than issued one interaction at a time. In conversation with the coach, a brief pause reads as consideration rather than lag: the one surface where live generation is appropriate.
Three seconds of waiting in front of a two-minute exercise is enough for the exercise to stop happening, so this is a product decision rather than an optimisation. Personalisation depth stopped being traded against responsiveness. Spend tracks batched background work rather than raw interaction count, which is what makes per-interaction personalisation affordable at all.
Too many notifications and the user revokes permission at the operating system level, which is close to unrecoverable. Fixed scheduling fails both partners at once and badly times for different time zones.
One partner quietly stops. The other opens the app, finds their check-in unanswered and the shared activity half done. The second partner does not decide to leave. They are pushed by the first partner's silence through a mechanism the product itself built.
Bonds runs on Bubble for its application layer. The privacy rules are enforced server side at the data layer, which is exactly the control this product needed most. The privacy tier is not a filter the interface applies. It is a rule the platform applies to what a query returns at all.
The controls underneath
Six things sit underneath all four decisions.
The data layer applies the privacy rules, rather than the interface filtering results it was handed. That is why the boundary holds for features nobody has written yet.
Sign-up runs through a federated provider or verified email, and the application does not handle passwords. Pairing is one invite flow that creates the couple record, rather than two people separately configuring a relationship and hoping the configurations agree.
The tier decides what class of data a query may touch. The role decides what an account may do with it.
Coaching runs under enterprise data handling terms rather than a general consumer endpoint, which matters when the payload is emotional and relational material about identifiable people.
rather than discarded, so neither partner's words are lost to timing. This applies to shared couple state, not to private reflections.
, which makes relevance auditable after the fact instead of taken on faith.
Privacy is the whole product, and it is the criterion this page has already spent four thousand words on. Classification at write, enforcement at read, context scoped to the partner asking, and a dashboard constrained so a partner's own figure does not fall out of it.
Processing integrity is the one nobody expects to matter in a consumer app. It asks whether the system does what it claims, completely and accurately, and a shared streak that occasionally eats a day fails that test. So does a completion that a concurrent edit silently undoes. Those are not cosmetic bugs here, because the streak is the reinforcement mechanism, and a number a couple cannot trust is worse than no number.
Designed against the criteria is not the same as attested against them, and this page does not claim otherwise.
The impact, depending on your job
If you run the business
Privacy is the product, not a policy page. Couples write honestly only in a space they trust, and the honest data is the entire input to personalisation. A product that leaks quietly becomes a content library, because everyone starts performing.
The shared account is the moat and the risk at once. Two people on one subscription is better economics than two individual accounts and a harder build than either. Getting the shared state right is what stops the product becoming two single-player apps that happen to share a login.
Retention is designed rather than marketed. The daily action is sized for bad weeks, the progress record is the one motivator that strengthens over time, and one partner's drift is treated as a signal about both. In a category where fortnight-two drop-off is the norm, that is where the business is won.
If you run engineering
The tier model is the part worth your attention. Classify at write and enforce at read, so the boundary holds for features nobody has written yet, and the security review has one question rather than one per screen.
Then the part specific to this domain: an audience of two changes what aggregation means, and a design that is safe at scale is not automatically safe at n equals two.
If you run a delivery team
Concurrency rules exist once, in the write path, rather than on every screen that can modify a goal. Prompt frameworks are held centrally, so improving one improves every surface. The clinical boundary is configuration, so changing it is not a release.
That is what keeps a small team shipping features rather than maintaining twelve special cases and a set of prompts nobody dares touch.
If you own the numbers
Cost per interaction stays flat as a couple's history grows, so the most engaged users are not the most expensive to serve. In a subscription product that matters more than average cost.
Provider spend tracks batched background work rather than interaction count, which is what makes per-interaction personalisation affordable at all.
Correlated churn is caught at the first partner, which is worth roughly double, because in this product one lapsed account usually costs two.
Built with
We name the layers rather than the suppliers, because a supplier map is our client's exposure rather than our credential. Full detail available under NDA.
More case studies
View all case studiesAQYR — recruitment platform
One platform. Three user groups. Hard multi-tenant separation.
Read case studyInvestor Relations for ASX — investor relations
Multi-tenant IR platform for ASX-listed companies.
Read case studyKeylr — property marketplace
Trust, dispatch and payments as one system.
Read case studyBuilding a consumer product where a privacy failure is a betrayal rather than an incident?
Tell us what you're building, and we'll tell you honestly how we'd approach it.