Di Larmore | Product Leader

A Teardown — the measurement layer AI's spend rails can't deliver.

At a Glance

The Puzzle

Companies are handing AI agents a blank check. The agent spends on compute, on data, and increasingly on purchases — and finance can see the bill but can't say what any of it bought.

That is not a billing problem. It's a measurement problem. A 2026 enterprise can tell you it spent $3M last month on agents. It cannot tell you the cost of one validated result — one enriched lead that passed QA, one resolved ticket that didn't bounce back, one reconciled invoice that was actually correct. The denominator doesn't exist yet.

PM Insight: The question leadership is asking — "what did we get for it?" — is unanswerable today, and not for the reason people assume. Outcomes aren't hard to define. The spend is just scattered across rails that can't see each other and was never tied to the task that incurred it.

Only about 21% of enterprises have mature agent governance. The other ~$100B+ of agent operating spend in 2026 is flying blind.

The Trigger

Simon Taylor framed AI's cost explosion as a fintech problem. That framing is correct, and it's why the obvious players moved. But the answer the market reached for governs the seller's side of the meter, not the buyer's side of the decision.

Metered billing helps AI companies charge. Scoped agent cards help commerce platforms issue. Both address cost inputs. Neither answers the buyer's question, because the buyer's question is a ratio — cost over result — and nobody owns the denominator.

The Landscape — Who's Already Here

I'm not first. Stating that plainly is the point; the credibility of the thesis depends on knowing exactly who occupies the territory and where the seam is.

PM Insight: Each solved a hard half. The seam none of them has closed is the buyer-side join: an agent's inference spend and commerce spend, together, under one identity, expressed as cost-per-validated-unit. That seam is narrow, and it's where I plant the flag.

The Insight

The denominator is the whole game.

You can't compute cost-per-validated-unit (CVU) today — not because outcomes are hard to define, but because an agent's spend is fragmented across rails and unattributed to the task that produced the result. Fix the attribution and the metric falls out.

Unify spend under one agent-task identity and CVU becomes computable for the first time. That is the product. The rails are the substrate it stands on.

CVU = the cost to produce one quality-accepted result. Measured at the layer the agent controls — not the downstream business outcome, which sales cycles and timing contaminate. We measure "the lead was enriched and passed QA," not "the lead closed."

The Architecture

One control plane across all three rails (inference, usage, commerce), built bottom-up.

1 — Unified agent-task ledger. Every spend event — a token call, a metered API hit, a purchase — is tagged to one agent identity and one task. This is the substrate; without it nothing above is computable.

2 — Real-time authorization. Approve / downgrade / route / escalate / decline, on every event.

3 — The measurement layer (CVU). The hero. Turns governed spend into a trustworthy cost-per-validated-unit.

4 — Routing on the ranking. Send each task to the best-value provider. This is the mechanism by which CVU falls.

The decision function — the part most people get wrong

A system that gates on spend alone is rudimentary: it's a smarter spending limit, which is the commoditized "give the agent a card with a cap" that the incumbents already ship.

The decision indexes on expected marginal CVU, not dollars. Spend is the constraint; CVU is the objective. We don't authorize what's cheap — we authorize what's worth it. A $0.05 premium-model call that materially raises validated-completion probability is a good decision; a $0.001 call that yields junk that fails validation is a bad one.

The inputs to each decision:

• Expected value — predicted validated-outcome value of this action vs. its cost.
• Marginal / diminishing value — a 4th retry has near-zero expected lift → declined on negative marginal CVU, not because it's "over budget."
• Task criticality — high-stakes work earns the premium path; standard work takes good-enough-and-cheap.
• Risk / anomaly — runaway loops and unusual patterns, weighted independent of amount.
• Confidence — low confidence in the prediction → don't auto-decide; escalate.

PM Insight: CVU isn't only the scoreboard — it's the decision currency. The same metric that measures spend efficiency is the one the authorization layer decides on. Measurement and authorization collapse into a single loop: predict marginal CVU → decide → measure realized CVU → update the predictor.

Where the AI sits — and where it must not. The hot-path decision is made by a cheap learned predictor (a small model scoring expected marginal CVU in milliseconds) — AI, but not an LLM. An LLM is reserved for the tail and the human layer: plain-language rationale for escalated decisions, natural-language policy authoring, anomaly investigation, and proactive suggestions. Putting an LLM in the loop on every event would re-create the exact cost-and-latency tax this product exists to kill. The control plane governs its own AI spend by the same CVU logic it enforces on the agents — it eats its own dog food.

The measurement layer — CVU, defined precisely

Governed CVU = (governed spend attributed to validated units, incl. amortized orphan cost) ÷ (validated units)

Three components most people miss:

• Cost-to-validated-completion — includes the retries and failed attempts on the path to a passing result, not just the successful call.
• Escape rate — work that was validated but later failed in the field; CVU is adjusted for it so we don't reward a loose quality bar.
• Amortized orphan cost — spend that produced nothing, allocated across the units that did pass. Hiding orphan spend would flatter CVU; we refuse to.

The baseline is the human counterfactual. CVU only means something against what the result used to cost. Data sources, ranked by trust: (1) the prior process's actual financial cost; (2) external benchmarks; (3) intra-system trend once enough history accrues.

For net-new workflows with no human counterfactual, the baseline is the first stabilized CVU; performance is then judged by the CVU trend over time rather than against a prior process.

Honesty caveat we state out loud: deflected spend is theoretical savings until the freed capacity is actually recovered. A model that claims savings while headcount and budgets are untouched is lying. We label realized vs. theoretical.

The baseline study (template)

To anchor CVU at onboarding, we run a short time-and-quality study of the incumbent process. The public anchor we lean on: in a controlled lead-enrichment test, two analysts doing manual research hit ~91% accuracy across ~143 hours per 10,000 contacts; a structured automated path verified ~96.4% in under 11 minutes. Two axes move at once — time and quality — which is exactly why a cost-only view misleads.

Governance as a marginal cost

Control is not free. If it scales linearly with spend, it eats the savings.

Principle: control cost must scale sub-linearly. Mechanism: risk-tiered enforcement. Cheap deterministic policy (budgets, allowlists, limits, velocity) runs on the hot path at near-zero marginal cost per event; expensive evaluation (anomaly models, human approval, the LLM judgments above) fires only on the risky or expensive tail, sampled or async. This is the same logic card networks use to authorize billions of transactions without reviewing every receipt.

The Prototype

I built it. Demos beat decks.

▶ Live demo — the CVU Command Center: prototypes.dilarmore.com/Command-Center

The command center runs a representative enterprise — $3.0M/month of ungoverned agent spend across 2,400 agents — and shows the divergence between the ungoverned trajectory and the governed one in real time. Toggle a policy (value-based model routing, retry caps, best-value provider routing, criticality-aware premium) and the headline deflection, the CVU, and the projected annual impact move because the underlying unit economics move — each lever's saving derives from the real 2026 price spread between frontier (~$15–30 per million output tokens) and mini (~$0.40) models, the ~96.4% validation benchmark, and the McKinsey $5–50M/yr production-agent band. A "your company's numbers" mode lets a buyer model their own scale. The live decision stream and a click-through reasoning view make the decision function legible; an assumptions-and-sensitivity drawer shows the model rather than asserting it.

PM Insight: The decision in the demo is deterministic and instant; the LLM only writes the explanation. That's the architecture made literal — the cheap engine decides, the model narrates. Even the prototype refuses to commit the governance-tax sin.

The Edge — A Three-Sided Data Moat

Every governed task sharpens one shared performance ranking: cost-per-validated-unit by provider, across both rails. The ranking the suppliers compete on is the same one buyers route from.

More buyers → more spend routed → a sharper ranking → lower CVU and harder supplier competition → more buyers. An incumbent can clone the rails; the ranking accrues to whoever sits at the measurement layer first and widest.

Who wins (neutral): whoever pairs a payment rail with buyer-side governance DNA. That's a short list — a rail-holder who learns to think from the buyer's chair, or a spend-governance company that earns the cross-rail join. Stated honestly, both are credible; neither has done it yet.

Metrics — The Full Tree

The pair that matters: CVU down while task success holds. The whole point is value-per-dollar, not dollars saved. If you cut CVU by breaking the agents — declining spend they needed, downgrading models below the quality bar — task success falls and you've failed, no matter how good the cost line looks. Task success is the counter-metric that keeps the North Star honest.

Monetization

Savings-share is the right model. The platform takes a percentage of realized savings — the dollars it provably deflected against the baseline. It only earns when the buyer wins. That alignment is the product's integrity: a spend-governance tool that profits from more spend is conflicted.

PM Insight: I considered and rejected a per-transaction volume fee. It's simpler to bill, but it inverts the incentive — the vendor would quietly profit from the very runaway spend it's supposed to stop. The CVU thesis and a volume fee can't coexist. Savings-share is harder to instrument (it requires the baseline study) and that difficulty is itself a moat.

The take rides on savings, never on spend. A fee on governed spend is the wrong base — it bills more as the customer spends more, the exact misalignment savings-share exists to kill. (For net-new workflows with no human baseline, savings-share begins once the first stabilized CVU is set and the platform optimizes below it.)

The Bottom-Up Revenue Model

Top-down sizes the prize; bottom-up sizes the business. Year 1–2 serviceable revenue, grounded in direct capture:

At these settings, 20% of savings ≡ 5% of governed spend ≡ 1.25% of total spend, and the customer keeps 80% of every dollar saved. The deflection anchor is deliberately conservative: the prototype models a larger, high-waste enterprise (~42% deflected on $3.0M/month), while the revenue model uses a blended 25% on a mid-market $15M/yr base.

PM Insight: North Star, monetization, and revenue are one engine viewed three ways. Deflection lowers CVU (the North Star); deflection is the savings we share (monetization); savings × take × customers = revenue. When the metric, the money, and the model all key off the same number, the business reads as coherent rather than bolted together.

▶ Interactive revenue calculator: prototypes.dilarmore.com/Revenue-Calculator

Value at Stake

~$150B+ of agent operating spend in 2026 — anchored by the inference floor, with tool/API and early commerce-as-cost additive — of which the ~79% that is ungoverned ≈ $100B+ flying blind. Stress the two drivers ±20% and the range is ~$95–145B.

The trajectory is the real story: a path past $0.5T by 2027 as inference compute scales roughly 1,000× and agent counts ~10×. And inference is the smaller rail — agents are projected to intermediate >$15T in B2B spend by 2028. The measurement layer sits on top of both.

Illustrative. Top-down from the ~$150B+ inference-floor of agent operating spend × the inverse of the ~21% mature-governance rate (assuming governance maturity is broadly uncorrelated with total organizational spend); bounded by ±20% on either driver. The bottom-up serviceable-revenue model lives under Monetization.

What I'd Build — Where to Play, How to Win, Why Now

Where to play — FinOps beachhead. Land with the buyer who already feels the pain and owns a budget: the FinOps lead. The first wedge is read-only — attribute existing spend to tasks and produce the first real CVU number. You can't be turned off once you're the only source of that number.

How to win — own the denominator, then the routing. Coverage first (attribution), then authorization (the decision function), then routing on the ranking (where CVU actually falls), then the three-sided moat compounds. Each layer is defensible only because the one below it exists.

Why now — the rails just shipped and governance hasn't. 2026 is the seam: the cost rails are live (Stripe, the clouds, Ramp), spend is exploding, and only ~21% of enterprises can govern it. The category forms in the next few quarters. After that the denominator belongs to whoever computed it first.

Sequencing:

1. Attribution (read-only). One ledger, one identity, the first CVU. Lands the FinOps buyer.
2. Authorization. The decision function — approve/downgrade/route/decline on expected marginal CVU.
3. Routing + the ranking. Best-value routing; the shared performance surface; the moat begins to compound.

Risks & Mitigations

Recommendation

The cheapest token and the scoped agent card are necessary — and already shipping. The defensible product is the layer above them: spend that is unified, authorized in real time on expected marginal CVU, and measured in cost-per-validated-unit.

What would change my mind: if an incumbent ships unified, cross-rail CVU before the category forms. In that case the moat is theirs — but the lesson is identical: the seam was real, and the denominator was the prize. I'd rather be demonstrably right about where the value is than protective of whose it becomes.

Key Takeaways

1. The rails are table stakes; the denominator is the product. Everyone built the meter. Nobody owns cost-per-result. That ratio is the whole game.

2. Govern on value, not on budget. "Can we afford it?" is a spending limit. "Is it worth it?" is a product. The decision function indexes on expected marginal CVU — and the same metric that measures is the one that decides.

3. The moat is the ranking, not the rails. Whoever measures validated-unit economics first and widest accumulates a surface buyers route from and suppliers compete on. Incumbents can copy the plumbing; they can't copy the accrued ranking.

Summary

AI's cost explosion is a fintech problem — Simon Taylor is right. But the fintech answer the market reached for governs the seller's meter, not the buyer's decision. Companies can see what their agents spent. They can't see what they got for it.

That gap exists because spend is fragmented across rails that can't see each other and was never tied to the task that produced the result. Unify it under one agent-task identity and a single number becomes computable for the first time: cost-per-validated-unit. CVU is the scoreboard and the decision currency — authorize on expected marginal CVU, route on the shared ranking, and the cost of a validated result falls while the work still passes.

I didn't invent this category. Stripe, the clouds, and Ramp are already in it, each having solved a hard half. The half they've left open is the buyer-side, cross-rail join — and that's a narrow, real, and briefly open seam. The rails are the substrate. The measurement layer is the product. The denominator is the prize.

End of Teardown · Companion to the Highlight · Working prototype embedded above.

The measurement layer AI's spend rails can't deliver. A response to Simon Taylor — the rails are table stakes; the denominator is the product.

The Problem

Companies are handing AI agents a blank check — to spend on compute, on data, on purchases — and finance can see the bill but can't tell what any of it bought.

Today only ~21% of enterprises have mature agent governance. The other ~$100B+ of agent operating spend in 2026 is flying blind.

Why the Rails Don't Fix It

Simon Taylor is right that this is a fintech problem. But the answer the market reached for solves the seller's side, not the buyer's:

• Stripe now holds both rails — metering for tokens, Issuing for commerce — pointed at helping AI companies bill.
• The clouds (AWS AgentCore, Google's Gemini Enterprise) govern infrastructure and token spend.
• Ramp reconciles token spend and issues agent cards — but as two separate, after-the-fact ledgers.

Each solved a hard half. None governs an agent's inference spend and commerce spend together, from the buyer's chair, under one identity. They give you cost inputs — not the answer to David's question.

The Insight

You can't compute cost-per-validated-unit (CVU) today — not because outcomes are hard to define, but because an agent's spend is scattered across rails that can't see each other and isn't tied to the task that incurred it.

Unify spend under one agent-task identity and CVU becomes computable for the first time. That's the product. The rails are the substrate it stands on.

CVU = cost to produce one quality-accepted result. Measured at the layer the agent controls — not the downstream business outcome, which sales and timing contaminate.

The Solution

One control plane across all three rails, built bottom-up:

1. Unified agent-task ledger — every spend event (token, API, purchase) tagged to one agent identity and one task.
2. Risk-tiered authorization — cheap deterministic rules on the hot path (budgets, limits, velocity); expensive checks (anomaly, human approval) only on the risky tail. Control cost stays sub-linear — the way card networks authorize spend, not by reviewing every receipt.
3. CVU measurement — cost-to-validated-completion, escape rate, amortized orphan cost. The hero.
4. Routing on the ranking — send each task to the best-value provider. This is how CVU falls.

The decision isn't "can we afford it?" — it's "is it worth it?" Every authorization scores expected marginal CVU: a premium model call that lifts validated completion gets approved; a cheap one that yields junk that fails validation doesn't. Spend is the constraint; CVU is the objective.

The workflow it collapses (illustrative): A lead-enrichment agent buys data credits (commerce), calls an enrichment API (usage), and runs an LLM to dedupe and score (inference). Today that's three consoles and an invoice. Here it's one policy, one ledger, one CVU readout — with a spend event downgraded to a cheaper model in real time.

I built it. Demos beat decks.

▶ Live demo — the CVU Command Center: prototypes.dilarmore.com/Command-Center

The live build — policy engine, real authorization decisions, the full CVU readout — runs above; the full teardown walks the architecture behind it.

The Edge: A Three-Sided Data Moat

Every governed task sharpens one shared performance ranking — cost-per-validated-unit by provider, across both rails. The same ranking the suppliers compete on is the one buyers route from.

An incumbent can clone the rails; the ranking accrues to whoever sits at the measurement layer first and widest.

Who wins: whoever pairs a payment rail with buyer-side governance DNA — a short list today.

Success Metrics

The pair that matters: CVU down while task success holds. Save money by breaking the agents and you've failed.

Value at Stake (Illustrative)

~$150B+ agent operating spend in 2026 (anchored by the inference floor) × ~79% ungoverned ≈ $100B+ flying blind — on a path past $0.5T by 2027 as inference compute scales ~1,000×. The commerce rail (agents projected to intermediate >$15T in B2B spend by 2028) is orders of magnitude larger.

Note: Illustrative. Top-down from the ~$150B+ inference-floor of agent operating spend × the inverse of the ~21% mature-governance rate (assuming governance maturity is broadly uncorrelated with total spend); ±20% on either driver bounds it at ~$95–145B.

The Recommendation

The cheapest token and the scoped agent card are necessary — and already shipping. The defensible product is the layer above them: spend that is unified, authorized in real time, and measured in cost-per-validated-unit.

What would change my mind: if an incumbent ships unified cross-rail CVU before the category forms — in which case the moat is theirs, and the lesson is the same. The seam is real either way.

[Full teardown — architecture, formulas, the baseline study, monetization, and the embedded prototype — available.]

The Live Prototype

This is the real, installable build — flip between the infant-care and elder-care instances and watch one architecture reconfigure into two products.

Open the live prototype in a new tab ↗

The Situation

Caring for a dependent — a newborn, a young child, an aging parent — is almost never a solo job. It's a rotating cast of caregivers whose availability, role, and context shift by the hour and by the year. And the work that actually breaks down is rarely the task itself. It's the coordination: who has the dependent right now, what's already been done today, what changed, and what the next caregiver — or the physician at the next appointment — needs to know.

The cost of a dropped handoff isn't a missed checkbox. It's a double-dosed medication, a child left uncovered, or a pattern of small changes that no single caregiver saw and no one flagged at the visit.

I came to this problem from both directions. The personas behind Kin OS were developed from lived experience and direct observation within a small group of active caregivers across both domains — early-childhood care, and elder care including a multi-year dementia progression coordinated across family and a professional home-health aide. Two ends of the same problem. So I built for both.

The Reframe

Every tool in this space treats care as a tracking problem — log the feed, log the dose, check the box. Tracking is necessary, but it's commoditized; every competitor does it. The unsolved problem is the coordination layer that sits on top of tracking: keeping multiple caregivers genuinely in sync, with role-appropriate context, when none of them has spare cognitive bandwidth.

Then the reframe that became the platform thesis: infant care and dementia care are the same coordination problem at opposite ends of the dependency lifecycle. Both involve multiple caregivers, a dependent on a shifting schedule, primary responsibility that reassigns, exception-driven attention, and a continuity-of-information need spanning the daily handoff to the periodic clinical visit. The dependent's life-stage is a configuration; the coordination architecture is constant.

That insight is the wedge. Care software today is siloed by vertical — a baby tracker here, a med reminder there, an elder-care app elsewhere — and almost none coordinate across caregivers, let alone across life-stages. Kin OS is one platform built on the coordination building blocks that generalize: a schedule that serves as the source of truth, role-neutral coverage, exception-logging, continuity-of-information, and visit-prep.

The Two Caregivers I Built For

A parent coordinating two young children at different developmental stages, across two working co-caregivers. Two children, two rhythms, no shared schedule. Coverage is dynamic — roles flip on weekends, availability varies by day, a spontaneous handoff can move a child to either parent at any moment. The acute need beneath the tracking is coordination under chronic cognitive load: two operators, neither able to hold the day in their head, needing to stay in sync without a meeting.

A working primary caregiver coordinating a parent's dementia care, across family and a home-health aide. An aging parent whose needs drift as the condition progresses. A rotating cast — the working primary, other family, and a constant professional aide. Over a multi-year course, the primary caregiver role reassigns entirely, more than once, while the aide remains the continuity layer. Beyond tracking, the real problems are handoff across caregiver types, continuity of information across time (the aide's mid-afternoon observation that matters at a visit three weeks later — in dementia care, the pattern of small changes is the clinical signal, and no single caregiver sees the whole pattern), and medication as a first-class concern.

The Keystone Decision

The single most defensible architectural choice — a role-neutral, configurable-caregiver data model — was demanded independently by both personas, at two different time horizons: intra-day fluidity for the parents, multi-year reassignment for the dementia-care family. A decision forced by two unrelated lived realities isn't an abstraction chosen for elegance. It's the necessary consequence of how care actually moves between people.

What I Built

Everything is organized around one principle: the schedule is the source of truth. It pre-loads the day's expectations; live data adjusts them; optional logging refines them. You only touch the app when reality diverges from plan.

The coordination building blocks are vertical-agnostic — a Now view with schedule-driven coverage and always-visible countdowns; one-tap handoff that temporarily overrides the schedule and reasserts at the next block; shared availability blocks (a parent's focus time and an aide's recurring shift are the same feature); exception-logging that's collapsed by default and surfaces on the timeline, the weekly summary, and visit-prep; symmetric capability with role-aware presentation (every caregiver can log everything; only the default view differs, and care-plan definition stays with the primary — an aide who can't log is useless, one who can rewrite the regimen is dangerous); shared notes with one-tap 'seen,' not chat; a planning-slanted weekly summary; and a visit-prep export with an auto-compiled medication list.

Each vertical then configures the surface: infant care gets feed/sleep/diaper tracking and wake-window logic; elder care promotes medication management to a first-class surface — free-text entry that matches the bottle, meal-based check-off buckets, and a daily checklist that feeds the visit summary automatically.

The Build

I designed, built, and shipped this solo using an AI build stack — taking it from spec to a working, installable PWA on a serverless backend (Cloudflare at the edge, Supabase for data, realtime, and auth). A few decisions worth remembering:

• Sequenced layers. The reliable in-app countdowns shipped before push notifications, so a flaky platform dependency could never block launch.
• Permissive data isolation by design. A household shares everything; per-row ownership would add friction with no security benefit. The real trust boundary lives at the edge auth gate — and it's the correct base to tighten for a multi-tenant future.
• The schedule as a real engine, not a static reference: coverage resolves as override → availability block → schedule owner → time-of-day default.
• Anticipated the non-obvious failure modes — keeping the service worker and manifest reachable behind single-sign-on so install and offline survive; an idempotent, re-runnable schema so deploys stay boring.

How I'd Know It's Working

This is a v0 — built and dogfooded in a single household, with broad validation deliberately pending. Research was intentionally deep-and-narrow at this stage; the next step is expanding it once the core thesis proves out in real use.

The measure that matters right now is daily coordinated actions per household — proof that care is actually being coordinated between people, not just logged by one. A coordinated action is a concrete cross-caregiver event — a handoff completed, a schedule block overridden, or an exception logged by one caregiver and seen by another. I chose an engagement measure over retention on purpose: at this stage the open question is whether the coordinating behavior happens at all, not yet whether it persists. Secondary signals — how much the supporting caregiver logs, handoff-completion, exception-notes captured — test whether the thesis is true in practice. And real usage earns the roadmap: the features people lean on get built deeper, guided by evidence instead of opinion.

There's a deliberate boundary, too: the pilot handles no regulated health data and is personal-use by design. Any future provider-facing expansion is gated on the relevant compliance (HIPAA), and the existing per-household data isolation is the groundwork for that path — not the compliance itself. Naming the boundary up front is a scoping decision, not an afterthought.

What This Taught Me

The ask is ‘track my kid's feeds.' The opportunity is a coordination platform.

The presenting problem is rarely the one worth solving.

Building for exhausted people is a forcing function for ruthless simplicity.

The hardest work wasn't the backend — it was the empathy: the right default per caregiver, calm-by-construction design, logging exceptions instead of norms so the app never punishes an imperfect day.

The strongest architecture decisions are over-determined.

When two unrelated real-world needs demand the same choice, you've found something true.

Ship the reliable thing first.

Sequence so nothing flaky can hold the launch hostage.

‍Open the live prototype in a new tab ↗

The Situation

Caring for someone who can't fully care for themselves — a newborn, a parent with dementia — is almost never done by one person. It's done by a rotating set of caregivers whose availability, role, and context shift constantly. The thing that breaks is rarely the task. It's the coordination between caregivers: who has the dependent right now, what's already been done, what changed, and what the next person — or the doctor in three weeks — needs to know.

I'd lived both ends of this. So I built the tool I kept wishing existed.

The Reframe

Every care app on the market treats this as a tracking problem — log the feed, log the dose. Tracking is necessary, but it's table stakes; everyone does it. The unsolved, higher-value problem is the coordination layer on top of tracking: keeping multiple caregivers in sync, with the right context, when none of them has spare attention.

And the deeper reframe: infant care and dementia care look like opposite ends of a life. Structurally, they're the same problem — multiple caregivers, a dependent on a shifting schedule, primary responsibility that reassigns over time, attention driven by exceptions, and a continuity-of-information need that runs from the daily handoff to the clinical visit. The life-stage is a configuration. The coordination architecture is constant.

Results

I designed, built, and shipped it solo using an AI build stack — a real, installable, instrumented product running on a serverless backend, not a mockup. One architecture configures into two distinct products; an interactive prototype lets you flip between an infant-care and an elder-care instance and watch the same system reconfigure.

What This Taught Me

The hard part was empathy, not plumbing.

The right default view per caregiver, the calm palette for 3am, logging exceptions instead of norms — building for exhausted people is a forcing function for ruthless simplicity.

One architecture decision, two independent reasons, is unshakeable.

The role-neutral data model was demanded by both verticals at two different time horizons — which is how I knew it was right.

Ship the reliable layer first.

I sequenced the build so no flaky dependency could block launch.