AI Product Repair Plan

Your AI product demos well. Users still hesitate.

Somewhere between the demo and daily use, people stop trusting it. We find where, and tell you what to fix first — and what to leave alone.

Request a repair plan See the plan structure
Scattered particles resolving into one solid glowing signal — the FixBroken cone
// what this is

A human-reviewed teardown. Not a chatbot audit.

Ask ChatGPT what's wrong with your product and you'll get twenty reasonable suggestions with no ranking and no evidence. This is the opposite: we go through your live product, score what we find, and rank it by impact and effort. Half the value is the list of things you were about to build that won't move the number.

01 Trust 02 UX clarity 03 Explainability 04 Activation 05 Positioning-vs-product gap 06 Evidence quality 07 What not to fix yet
// what we review
  • Your live product URL, as a new user meets it
  • Onboarding — the first five minutes, step by step
  • Trust and explainability — where users stop believing the output
  • Positioning — the gap between what you claim and what the product shows
// what you get
  • Every break we find, ranked by impact and effort
  • One highest-impact recommendation, called out plainly
  • A "do not fix yet" list, so you stop working on the wrong things
  • A 7-day action plan your team can run without us
// right fit

This works when the product exists and a number is stuck.

// for you if
  • Your AI product is live, or has a staging link we can walk through
  • A specific number is stuck — conversion, activation, retention
  • Your team can ship changes in days, not quarters
  • You want a call made: one ranked plan, not a menu of options
// not for you if
  • There's no product yet — this diagnoses what exists, it doesn't spec v1
  • You want the fixes built for you — that's an engagement, and it starts after a plan
  • The problem is model research — we fix the product around the model, not the model
// how the diagnosis works

Four steps.

01

Intake

The product URL, the stuck metric, what you've already tried. Five minutes, form below.

02

First-contact run

We go through your product the way a new user does — signup, onboarding, first output.

03

Structured diagnostic

Everything we find is written up in the same ten fields and ranked by impact and effort.

04

Human review, then delivery

A human reviews and signs every plan. Nothing ships on model output alone.

// what this is not
  • Not an automated score with a logo on it
  • Not a 40-page strategy deck
  • Not a design roast for engagement
  • Not a retainer pitch wearing a report
// who reviews this

One operator, not a review farm. The same person who does the client work on the work page reads your intake, walks your product, and signs your plan.

// the plan structure

Every break gets the same treatment.

No essays. Each break in your repair plan is documented in the same ten fields, so your team can act on it without a meeting.

repair-plan · field structure
break_summarywhat is broken, in one sentence evidencewhat we observed — screens, flows, copy, behavior severitycritical / high / medium / low likely_causewhy it is happening, not just where impactwhat it costs you — trust, activation, conversion efforthours, days, or a sprint recommended_fixthe specific change, not a direction ownerwho should do it — design, eng, founder do_not_fix_yetwhat to leave alone, and why seven_day_planthe order of operations for the next week
// sample output

One break, documented.

Example content. Product details invented for illustration.

severity: high dimension: trust effort: 2–3 days owner: design + eng sample — invented

Break: the meeting summary appears instantly, with no indication of what it read or skipped.

Evidence. Three of the five summary bullets reference the transcript; two don't, and nothing tells the user which is which. So they re-read the transcript to check — which takes longer than writing the summary themselves.

Recommended fix. Link each bullet to the transcript span it came from; unsourced bullets get a visible "unverified" state. Checking becomes a glance instead of a re-read.

Do not fix yet. The model. Output quality is not the bottleneck — verifiability is. Skip the fine-tuning sprint until users can see sources.

seven_day_plan (excerpt)
day 1–2 · source links behind a feature flag, transcript spans indexed
day 3–4 · "unverified" state for unsourced bullets, click tracking on both
day 5–7 · release to new signups, watch export rate against last cohort
// against the chatbot baseline

You could paste this page into ChatGPT. Here's the difference.

diff · chatbot vs repair plan
- a vague prompt, from memory
+ structured evidence intake: URL, metric, users, what you tried
- twenty suggestions, all equally urgent
+ every break ranked by impact and effort, one top call
- has never seen your product
+ run against your live product, as a first-time user
- equally confident when it's wrong
+ human-reviewed and signed before it reaches you
- everything is worth trying
+ an explicit list of what not to fix yet
Request a repair plan Five-minute intake. Read by a human.
// the offer

Pick the size of the break.

Rapid Repair Scan
$20,000

One product surface, one workflow, or one broken conversion moment. Every field of the plan structure, applied to the thing that hurts most.

For when you already know where it breaks — you need to know why, and what to do first.

Delivered within 10 business days of scope agreement.

Request a Rapid Scan
Deep Repair Plan
$40,000

The full diagnostic: onboarding, positioning, trust, and activation. Every break ranked, one highest-impact call, and a 7-day action plan.

For when users hesitate and you can't see where it's losing them.

Delivered within 15 business days of scope agreement.

Request a Deep Plan

Not sure which? Pick the Rapid Scan — if the break is bigger than one surface, we say so before any work starts. Requesting a plan is a fit check, not a purchase; nothing is billed until you agree on scope. Reply within 48 hours. Hands-on repair work is a separate engagement, and it starts after a plan.

Terms, plainly: 50% books the work, 50% on delivery. If the queue changes a delivery date, you'll know before you pay. And if the plan doesn't hand you a call you can act on, the second half is waived.

Judge the thinking before the price — the sample break above is exactly what every finding in your plan looks like.

// before you ask

The five questions everyone has.

The product isn't public yet. Can you still review it?

Yes — a staging link, test account, or recorded walkthrough all work.

What if the product is in better shape than we think?

Then the plan is short and says so. You're paying for the call, not for page count.

Do you build the fixes?

Not as part of the teardown — the plan is written so your own team can run it. If you want hands-on help afterward, that's a separate conversation, and it starts from the plan.

What do we actually receive?

A shareable document — PDF or Notion, your pick — in the ten-field structure above, plus one optional call to walk it through with your team.

Who sees what I submit?

The operator who writes your plan. Nobody else. Intakes are never published, and client work is never named publicly.

// start

Tell us where it breaks.

Every question below maps to a section of your plan. About five minutes, and sending it commits you to nothing.

// what happens next
01 · a human reads your intake — reply within 48 hours
02 · you get a straight answer: right fit, wrong fit, or wrong size
03 · scope and date agreed — your plan lands in 10–15 business days
01 · The product
We review it as a first-time user would.
02 · The break
One number or behavior beats a paragraph. This anchors the whole plan.
So the plan doesn't recommend what you've already ruled out.
No file uploads here — drop a link instead.
03 · The engagement
04 · You
Read by a human. Reply within 48 hours. No list, no drip sequence.