A prior authorization denial arrives as a PDF. Three pages, formatted for insurance auditors, with a sentence somewhere in the middle telling a patient their surgery has been denied. Most patients don't know the sentence is there. Most don't know they have 60 days to appeal. Most don't know the appeal succeeds roughly half the time when someone who knows the system files it properly.
Brivon started as an attempt to build that someone at scale, without burning out the humans who currently do this work one case at a time. The timing was real. Medicare started reimbursing advocacy services in 2024, the structural shift that took Solace from a Series A to a billion-dollar valuation in 18 months. What I underestimated was how much the design problem was actually a trust problem on both sides of the platform.
The American healthcare system doesn't fail patients through malice. It fails them through friction. Prior authorizations get denied on technicalities. Bills arrive with errors no layperson can catch. A patient navigating a serious diagnosis is simultaneously managing their condition and fighting a bureaucratic process designed by institutions with better lawyers and more time.
In 2026, that fight is getting harder. Insurers are using AI to deny claims faster — denial rates are at record highs, and the tooling gap between institutional and patient-side is widening. The patient-side countermeasure doesn't exist at scale.
Not one of them opened the dashboard they already owned. One said it plainly: it tells me what happened, not what to do about it. (If you have ever bought enterprise software and then watched the team quietly go back to a spreadsheet, you know the feeling.) These are people running plants with thousands of staff and razor margins, and the most expensive system on their desk was the one they trusted least.
That is the problem I was actually being asked to solve.
The earliest design work was strategic and it was the most consequential work on the project.
Brivon could touch prior authorization, billing disputes, care navigation, insurance appeals, clinical trial matching. Without a forcing function, it becomes a generic health platform that earns no one's trust deeply enough to generate referrals.
Care navigation for newly diagnosed patients scored highest on emotional intensity. But the win condition was diffuse, the feedback loop long, and operationalizing it early meant designing for a problem we couldn't yet measure.
Prior authorization won. Highest urgency. Clear win/loss signal. Natural success-fee alignment. A case either gets approved or it doesn't. That binary was a gift for a 0→1 product; it meant we could know whether we were working before we had enough data to model anything. PA denial rates are at record highs in 2026, with no good patient-side countermeasure at scale.
The PM moved fast and thought in systems. In a 0→1 context that's mostly an asset — decisions get made, momentum holds, the product doesn't die of analysis paralysis.
The design tension came from what AI tooling made possible. The PM could generate a plausible-looking advocacy workflow in an afternoon. The question I kept returning to: what decision does a human make at each step, and what happens when the AI is wrong?
In healthcare, wrong isn't abstract. A misclassified denial type routes to the wrong appeal template. A missed deadline means a patient's surgery gets postponed. Those stakes shifted the conversation from "does this work" to "what does failure look like and who is holding the bag." Three dynamics shaped every design decision:
Speed
The PM could generate a plausible advocacy workflow in an afternoon. Velocity is an asset until it isn’t — and in healthcare it can move faster than trust.
Stakes
A misclassified denial type routes to the wrong appeal template. A missed deadline means a patient’s surgery gets postponed. Wrong isn’t abstract here.
Control
Nothing leaves the building without an advocate’s eyes on it. That gate isn’t a safety rail — it’s the product.
The Phase 1 roadmap had a compelling vision. A case copilot that drafts appeal letters, summarizes medical history, extracts key facts from documents, suggests next actions. All of it technically achievable from week two. All of it premature.
The problem was sequencing. If the AI misclassified a denial type it routes to the wrong appeal template. If it misses a PA deadline, a patient's surgery gets postponed. An advocate who catches the AI being wrong twice loses confidence in the whole system. An advocate who feels like the AI saves them two hours while they stay in control becomes the product's best distribution channel.
Phase 0 shipped with AI-assisted intake and classification, manual advocate work, and transparent case timelines. The AI handles triage. Humans handle everything that leaves the building. It felt like leaving capability on the table. It was the only trust-building path available.
No system owns the decision layer. Takorin is built to sit across these categories and turn fragmented signals into a single ranked decision, with clear context, traceability, and a human approval step. It also exposes data readiness as a visible score and evaluates quality, supplier, and operational signals together in one place.
The brief that kept surfacing: this user arrived because something already went wrong. They're not evaluating Brivon the way someone browses a health app. They need to decide fast whether this is worth trusting with a fight they can't afford to lose.
Direction 1 — Clinical Authority: Deep teal, document-forward UI. Early feedback: "looks like a hospital's internal tool." The product is supposed to be on the patient's side. It looked like it was on the institution's side.
Direction 2 — Warm Advocacy: Warmer palette, conversational UI. One tester said it looked like a meditation app. In a prior authorization dispute, that's a credibility problem. I had that feedback in week two and kept trying to fix the direction instead of cutting it. The PM responded to the approachability. Two weeks lost.
Direction 3 — Earned Confidence: What does a person look like when they've done this before and won? The palette built from neutral grounds — stone, not gray, because gray reads as unfinished and stone reads as durable. Typographic hierarchy set to match the actual information density: case status, deadlines, insurer names, document types. Nothing decorative. Everything earns its place by carrying something specific.
Color was the hardest call. The system ended up with two functional colors: one for active and escalating, one for resolved and complete. Every other state lives in the neutral ground. The Won state is the sharpest version of that logic — a specific warm amber that appears nowhere else in the product. In testing, two advocates stopped mid-sentence when it appeared. One said: "oh, that's the good one." The color doesn't need a label because the restraint has already done the work.
So I did the opposite of what the brief implied and started taking things off the screen. The front door became one ranked queue. Every signal shows up with a priority, an owner attached, and a clock running, all of it built from data the plant already had. I made it a standalone screen and the default landing view rather than a panel on the old home screen, because a panel competes with everything around it while a screen with nothing else on it makes the ranked list the only thing in the room.
Shipped: structured and conversational AI intake, case type classification and urgency routing, case timeline with status and next action, outcome tracking (won / partial / loss), document ingestion for bills, EOBs, and denial letters.
Cut: AI-drafted appeal letters — deferred to Phase 1, after advocate trust is established. Proactive monitoring and deadline alerts — Phase 1. Employer dashboards — Phase 2 at earliest. Any marketplace or browsing surface — never in the initial wedge.
The cuts weren’t compromises. They were the design. The Phase 0 scope was the smallest version of the system that could demonstrate a real outcome — a patient who won — and build the advocate trust that Phase 1 automation would depend on.
The first version organized around cases.
One case, full screen, everything about that patient in one place. The logic seemed sound: advocates provide personalized service, personalization requires depth, depth requires focus. Advocates found it frustrating in a specific way. Getting to the next urgent thing required backing out, scanning a list, clicking in. In a session where an advocate is managing eight active cases, that's eight separate context switches just to triage the day.
1. A precedent from the plant's own past, because a director trusts a recommendation grounded in their own history
2. A countdown to the moment the window closes, because a finding without a deadline is just trivia.
The reframe came from listening.
Advocates don't think in cases — they think in urgency. The question at the start of every session isn't "which patient am I working on?" It's "who's critical right now and what do they need from me in the next hour?" Once that was clear, the information hierarchy redesigned itself. The final case view leads with a prioritized queue: cases ranked by urgency, with the specific action each one needs visible without opening it. A PA deadline expiring today sits above a document review that can wait until Thursday.
Data Readiness is about the platform itself rather than the plant, and it scores how much of what Takorin says can be trusted. More to the point, it names the specific reasons confidence is low, the same ingredient sitting under three different names across the MES, the ERP, and the supplier portal, and it gives an honest effort estimate to fix each one. Most factory AI hides its uncertainty. This product points straight at it, because the directors told me that hiding it is precisely how trust dies.
The hardest specific call: the collapsed queue card.
Too little and the advocate still has to open everything to triage. Too much and the card becomes unreadable at the density of eight cases. The final card shows four fields: patient name, case type, next required action, deadline. Everything else is one click in.
Testing surfaced something I didn't anticipate: advocates wanted to see their own workload, not just patient status. How many cases active, how many due today, how many waiting on the patient versus waiting on the advocate. Adding a session-level summary at the top of the queue changed how advocates described the experience. "I can see what my day looks like" is different from "I can see what my patients need." Both matter. The first one is about advocate capacity, which directly affects whether they burn out or stay on the platform.
The three things an advocate manages per patient — care plan, activities, documentation — live inside the case, not as top-level navigation. Triage first, depth second. One thing I'd push further: the documentation panel is currently flat, files in reverse chronological order. A denial letter at intake and a denial letter filed as appeal evidence are different objects that happen to be the same file type. The design should reflect that.
Marketplace and advocate profiles
The assumption I walked in with: patients browsing advocate profiles are making a hiring decision, so the profile should function like a résumé. Credentials, specialties, years of experience. That assumption was wrong in a specific way.
Patients dealing with chronic pain management aren't evaluating advocates the way you evaluate a contractor. By the time they're on a marketplace, the question isn't "is this person qualified?" It's "has this person seen my exact situation before, and did they win?" That reframe changed the profile structure. Credentials stayed but moved down. The top of the profile became about pattern recognition: what kinds of cases this advocate takes, how they work, what a patient should expect the process to feel like.
The success stories section was the most contested piece. Privacy concerns were real. The resolution was framing outcomes as patterns rather than individual cases — "15 of 17 Cigna denials for this condition reversed on first appeal" rather than patient narratives. A specific win rate against a specific insurer is a harder signal than a testimonial.
Two trust signals came from my hypotheses going into patient research. The 12% acceptance rate was the riskier one — displaying it openly creates a selection signal patients can use, but also a liability if the criteria aren't legible. In testing, patients flagged it as the detail that made Brivon feel different from a directory. "So they're not just listing everyone." The aggregate rating needed more structure than a number: the profile anchors ratings to outcome categories — communication, case resolution, speed — so a chronic pain patient can evaluate the dimension that actually matters to them.
What I'd push further: the "how I work" section is currently static copy the advocate writes once. Advocates approach different case types differently — a PA appeal runs differently than a billing dispute. The profile should let advocates describe their process per case category. The information architecture already accommodates it.
The moat
Every other module reads data generated inside the building. This one handles the risk that walks in from outside. It tracks certificate status against the production schedule, watches delivery ETAs, and runs a shelf-life optimizer that flags a lot about to expire before the run that needs it, while there is still time to reorder. It also carries a supplier compliance scorecard, which exists for two reasons. FSMA 204 is coming, and a score a supplier can see changes that supplier's behavior without anyone having to chase them.
Knowledge, against the retirement cliff.
The master operators who hold these plants together are retiring, and their judgment leaves with them. The Knowledge tab captures that tacit expertise and rates the risk of losing it. The most expensive thing a plant can lose is the person who knows why the oven runs warm on the gluten-free line, and nobody had a place to put that knowledge before it walked out the door.
Impact, the proof.
Every resolved case — won, partial, loss — feeds a record of what works against which insurer, for which denial type, with which documentation strategy. The product doesn't have that data yet. What it has is the architecture to collect it cleanly. By Phase 2, the pitch to a patient isn't "our AI is good at drafting appeals." It's: for this denial type, at this insurer, in this state, we've seen 340 cases. Here's what worked. That's a different product than any competitor is building. Whether it works depends on whether Phase 0 generates enough cases to make the data meaningful.
There was a stage that audited the existing patient advocacy landscape for the real gap, a stage that pressure-tested the wedge before any pixels got drawn, a build pass, and then two critique passes run separately so visual polish couldn't quietly cover for functional debt.
My job in that loop was not writing prompts. It was deciding which findings were real debt and which were noise, and overriding the model when its first answer optimized for looking finished over being right. The clearest case: an early intake flow that routed all denial types through the same appeal template. It looked complete. The stakes of that error — a patient's case filed with the wrong framing — made it non-negotiable to catch before anything shipped.
My job in that loop was not writing prompts. It was deciding which findings were real debt and which were noise, and overriding the model when its first answer optimized for looking finished over being right. The clearest case: the second critique pass caught an operator view that had hardcoded one operator's name across every shift. The screen looked complete. A single combined review, satisfied by the polish, would most likely have waved it through.
Phase 0 success condition: 70% or more of cases reach a clear outcome signal — won, saved, or resolved — within the case lifecycle. Advocates reporting significantly faster throughput even on a partially automated system is the leading indicator that Phase 1 automation earns its deployment.
The success-fee model aligns incentives in a way subscription-first can't achieve at this stage. Subscription without demonstrated outcomes is a churn machine. Success fee makes Brivon's interests identical to the patient's — and creates a revenue model that scales directly with impact.
The proprietary outcome data, accumulated cleanly through Phases 0 and 1, becomes genuinely defensible by Phase 2. Most healthcare advocacy tools compete on features. A tool that can say "we know how this type of fight ends" competes on a different dimension entirely.
The review held up. 2 independent passes found 4 critical and 4 major issues. Every critical was fixed before sign-off. One major was logged as documented design debt rather than dropped silently, an operator workflow that takes three taps against a two-tap spec, deferred because the real fix needs a different input method.
The structural wins are easy to state: 1 ranked entry point replaced five unranked alert sources, with ownership and deadlines built in by construction. A token-enforced design system holds all 22 screens to zero raw-value violations through a CI-ready audit. And the worker-mode decision let 2 later screens ship with no change to the original logic.
The OEE targets the product is built to move, the 5-15% gain on pilot lines and the drop in time between a risk and a response, are hypotheses to test in a pilot. I am not claiming them as results, because they are not results yet.
The wedge decision was right but slow. Three weeks of sequential analysis could have been a two-day structured exercise. I'd run it faster and commit earlier.
The brand took two extra weeks because Direction 2 looked good in Figma. I had the "meditation app" feedback in week two and kept trying to fix the direction instead of cutting it. Earlier alignment on a single brief — this user is in a fight, not a wellness journey — would have saved it.
The AI PM dynamic is something I haven't fully resolved. The right model isn't the PM proposes and the designer approves. It's closer to both parties holding the question of failure at the same time. Getting there required friction I had to keep generating for the first month. Eventually it became shared culture. I'm not sure that friction ever fully becomes culture or whether it's just something you maintain.
Not because the technology is limited, but because the failure modes are human. Wrong information doesn't just feel bad. It delays a surgery. It misses an appeal window. It costs someone a fight they could have won.
The design work that mattered most on this project wasn't the interface. It was the discipline of asking, at every decision point, what happens when this is wrong — and making sure the system's answer was: a person catches it before it leaves the building.