Designing a calmer coparenting system from idea to live beta
I defined the MVP, designed the core product system, and audited the live beta for Coparent Companion, a coparenting app built to reduce conflict, not just document it.
Lead Designer
Early Stage Product
June 2025 - Present
Context
Coparent Companion is a co-parenting app for separated parents who need to manage communication, decisions, schedules, and shared responsibilities after a relationship ends.
Challenge
Existing tools in this space were built around legal defensibility, not human usability. My challenge was to help define a product that put the co-parenting experience first: reducing cognitive and emotional load in a context where both are already stretched thin.
Role
I joined before any wireframes existed. Working directly with the founder, I helped define the MVP, shape the product architecture, design the core workflows, and bring the product to live beta. I'm currently embedded in the beta, auditing the live product and defining new features as the product evolves.
Impact
The result is a product built to make co-parenting feel calmer, clearer, and easier to manage day to day, without losing the structure users need when things get hard. The beta is live and open for public sign-ups.
The problem
My role
I joined Coparent Companion before any wireframes existed. The founder had a focused early concept, which was an AI coach to help separated parents handle difficult communication with more clarity and less escalation, but no defined product scope, no flows, and no design system.
Over the following months, my work fell into two distinct phases:
Phase 1 : Defining and designing the MVP. Working directly with the founder, I helped shape what the product needed to include, how the features should connect, and what the core workflows should feel like. This was scope work as much as design work.
Phase 2: Auditing and redesigning the live beta. As development accelerated, the founder built ahead of design to hit the beta launch quickly. I shifted into a UX audit role: evaluating live flows, identifying where implementation logic had overtaken user logic, and redesigning the experiences that felt technically functional but emotionally off.
Defining the MVP
The founding concept — an AI coach — made sense as a starting point. But a difficult exchange between co-parents rarely exists in isolation. It sits inside a larger web of custody timing, past agreements, shared expenses, and ongoing schedule changes. A coaching tool without that context would be limited: useful in the moment, but disconnected from the situation that created the moment.
I worked with the founder to define an MVP that reflected that full picture. The AI Coach became the center of the system, a dedicated space where users could bring in a message, process what was happening, and draft a calmer response — with surrounding context already available to it. Around it, I helped shape the workflows that gave the coach depth and gave co-parents the structure they needed to manage shared logistics without defaulting to text threads.
The six features that made up the MVP:
AI Coach — A private support space where users can process a difficult message, vent, and draft a clearer response. The coach draws on agreements, schedule, and expense history to give grounded, relevant support.
Custody Calendar — A shared source of truth for parenting time, events, holidays, and schedule changes.
Trade Requests — A structured way to propose custody swaps and schedule changes, replacing text threads that are easy to lose or dispute.
Expenses — A way to track shared costs, categorize them, and connect them to agreement logic over time.
Agreements — A shared record for parenting decisions, obligations, and recurring expectations.
Incident Log — A timestamped record for missed agreements or violations. I proposed this feature after spotting a gap in the early product logic: users could create agreements, but had no neutral way to document when those agreements weren't kept. More on this below.
Helps users process conflict, reflect, and draft clearer responses
Bringing UX rigor to a fast-moving beta
As development accelerated, the founder often built ahead of design to move the product into beta quickly. That changed my role. My work shifted from defining new workflows to auditing and redesigning live ones.
This became a meaningful part of the project. I was reviewing flows that worked at a technical level but still felt confusing, verbose, brittle, or emotionally off once they were in front of a user. I used my UX design background to evaluate where implementation logic had overtaken user logic, where onboarding introduced too much complexity too early, where trade request flows needed clearer structure, and where the coach lost context or fell into loops.
Language became a large part of this work. In an AI-heavy product for high-conflict situations, wording affects trust. Prompts, system messages, labels, and generated responses all shape whether the experience feels clear and grounded. I focused on improving the language the product generated, especially in places where it sounded too technical, too generic, or too detached from the emotional reality of co-parenting.
This phase of the work brought the case study into the present. It shows how I apply UX judgment once a product is live, messy, and moving fast. I was not polishing the edges of a finished system. I was helping turn a fast-built beta into an experience that felt clearer, calmer, and more trustworthy in use.
Decision 1
Proposing the Incident Log
Early in the project, I noticed a gap in the product logic. Users could create agreements — shared records of decisions and obligations. But there was no way to record when those agreements were broken. That gap mattered. Co-parents in high-conflict situations often need documentation not just of what was agreed, but of what happened afterward.
I proposed a dedicated Incident Log: a timestamped, neutral record of missed agreements or violations. The feature closed an important loop in the product system — connecting agreement creation to accountability over time — and gave users a record they could rely on without it feeling punitive inside the app.
This is the kind of contribution I find most meaningful in 0→1 work: catching what's missing before users have to feel its absence.
Decision 2
Designing Agreements as Guided Structure
Agreements were the hardest workflow to design. Co-parenting arrangements are deeply specific, emotionally loaded, and hard to standardize — every family's situation is different, and designing a form that feels flexible enough to accommodate real life without feeling overwhelming was genuinely difficult.
I explored multiple structural approaches before landing on a direction that gave users enough guidance to get started without making the product feel rigid or prescriptive. The goal was a workflow that felt like a shared workspace, not a legal document — something both co-parents could contribute to and revisit.
Later beta scoping narrowed the near-term solution, which helped align the design with what the product could support well in an early release. That tradeoff — between the ideal UX and what's buildable now — is a real constraint in early-stage work, and this was a useful exercise in designing to what's actually shippable.
Decision 3
Defining Trade Requests as structured proposals
Before Trade Requests existed, schedule changes happened the way most coordination does in co-parenting: buried in text threads, easy to misremember, easy to dispute. One parent requests a swap, the other responds in a separate message, neither has a reliable record.
I helped design Trade Requests as a structured proposal flow — a defined handoff that both parties could see, respond to, and track. The goal was to replace ambiguity with a shared record without making the interaction feel bureaucratic. The flow needed to be quick to initiate, easy to understand, and clear about what had been agreed.
Auditing the live beta
As development accelerated, my role shifted. The founder built fast to get the product into users' hands. That was the right call for an early beta. My job became evaluating what had been built from a user experience standpoint and redesigning the parts that worked at a technical level but felt off in practice.
This kind of work is harder to show than early design work. There are no clean comps when the "before" is a live product in active use. But it is some of the most important design work I did on this project. It required applying UX judgment to something messy, moving, and real.
I was looking for three categories of problems.
Complexity introduced too early. Onboarding screens that asked users to make decisions before they had enough context.
Implementation logic overtaking user logic. Flows that made engineering sense but created friction or confusion for users.
Language misaligned with emotional context. In a product built for high-conflict situations, the words matter as much as the layout. Prompts that were too generic, too technical, or too detached from the emotional reality of co-parenting undermined trust — even when the underlying logic was correct.
For each problem I identified, I documented what was wrong, proposed a solution, and in most cases redesigned the relevant screen or flow.
Outcome
Coparent Companion launched to live beta and is open for public sign-ups. The product went from a single concept to a connected system of six features, covering communication support, scheduling, agreements, documentation, and shared finances.
The work I'm most proud of isn't any single screen. It's the coherence of the system: that the AI Coach can draw on the custody calendar, flag a relevant agreement, or reference an expense when a user brings in a difficult message. That depth is what makes the product genuinely useful in the moments that matter most.
The beta audit tightened the live experience — not by adding features, but by making existing flows feel clearer, calmer, and easier to trust.
What I learned
The most useful thing I developed on this project was comfort with scope ambiguity. In 0→1 work, the design problem and the product problem are the same problem — you're not executing a brief, you're writing it. That requires a different kind of judgment: knowing when to push for more definition, when to move forward with uncertainty, and when a tradeoff is worth making to keep the product moving.
I also learned something specific about designing for emotional context. In a product used during conflict, every UX decision carries more weight than usual — information architecture, default states, the words a prompt chooses. Getting those details right isn't polish. It's the product.