The One Fix is a paid diagnostic for founders. You answer the questions and wait about a minute. What comes back is a report that names the pattern your company is stuck in and a fix list with an order to do it in. It costs Rs 399 and lives at yashasvishailly.com/diagnose.
This is the full teardown, including the part most product breakdowns skip: the day the tool returned a payment error on every single run because two flags disagreed. I built every piece of this myself, and most of what I know about it came from the pieces that broke.
Where it came from
Every consulting engagement I've run starts the same way. A founder describes a symptom, usually that hiring isn't working or that every decision keeps coming back to them. The real problem sits somewhere else, and the first hour of every call is me walking them from the symptom to the cause. After enough of these calls I could see that the walk itself had a fixed shape, so I decided to build it.
The first version went up in April 2026 as a plain form. It emailed me the answers and I wrote every diagnosis by hand, which was honest work and completely unscalable, and it meant a founder waited on my calendar to learn what was wrong with their company. In May I rebuilt it around Claude. The form became a conversation, and the wait between answering and knowing dropped from days to about a minute. That wait going away is the whole reason the automated version exists.
The diagnosis itself grew in rounds after that. The first automated report was shallow, six fields and a summary, and it read like it. Round by round it widened into what it is now: a scored nine-section diagnosis that covers execution, operations, decision-making, people, and org design, with the eight-pattern taxonomy underneath holding it all together. Then came payments, which is its own section below. Everything since has been making the diagnosis sharper and the machine around it harder to break.
What it asks
The questions come one at a time, in a chat interface. They read like the questions a diagnostician asks in a first session, because that's what they are. Where do you spend most of your time right now. What happens when you step away.
Each question exists to pull a specific signal, and I've audited every one against the report sections it feeds. A question that produces answers the report can't use gets rewritten or cut. One example of how picky this got: question five originally read "Where does the founder spend most of their time?" in third person, which made the whole thing feel like an HR survey about someone else. It now asks "Where do you spend most of your time right now?" Same data, completely different honesty in the answers.
The eight patterns
Underneath the report sits a taxonomy of eight execution patterns I've seen repeat across early to growth stage companies. The diagnosis engine reads all the answers together and names the dominant one, with a confidence level attached, because a diagnosis without confidence is a horoscope.
- Founder Gravity. Everything routes through you, so the company moves at exactly your speed.
- Execution Debt. Half-finished systems and deferred decisions have piled up until everything new runs slow.
- The Shadow Organization. The org chart you drew and the org that actually gets work done are two different companies.
- The Orphaned Middle. You hired a middle layer and then never gave it real authority, so it forwards instead of decides.
- The Consensus Tax. Decisions wait for everyone to agree, and everyone rarely does.
- Inspection Theater. Reviews and dashboards that perform oversight without catching anything.
- Wrong Altitude. You're operating three levels below where the company needs you.
- The Permanent Pilot. Experiments that never graduate; everything stays a test forever.
Naming the pattern turned out to matter more than I expected. Founders will argue with a score. They go quiet when a pattern gets named, because a name means someone has seen this before, which means it's fixable and also means it's real.
What the report holds
Nine sections. It opens with the pattern, one sentence that summarises the whole diagnosis, and three scores: Execution, Org Design, Decision Velocity. Then it walks the same path I'd walk on a call. What you came in believing the problem was. What your answers actually show. An execution audit. An org design read. The root cause. What stays broken in six months if nothing changes, with a prediction attached. A first move on a week timeline. And a fix list of 12 to 14 items, prioritised, in operator vocabulary.
Two voice rules govern the whole output. The report addresses the founder as "you" throughout; their name appears once, in the header, and never again. And every section opens with a lead sentence followed by bullets, because founders skim, and a wall of paragraphs gets closed before it gets read.
What it runs on
The site is pure static HTML on Cloudflare Pages. No CMS, no build step; publishing means dragging a folder into a browser. Behind it sits one Cloudflare Worker doing four jobs: it proxies calls to Claude (Sonnet 4.6, structured JSON output), creates and verifies Razorpay payments, sends email through Brevo, and stores state in Cloudflare KV.
The system prompt, the taxonomy, and all the diagnosis logic live inside the Worker, server-side. View source on the page and you'll find nothing worth copying, which was a deliberate move after early versions shipped the whole prompt to the browser. It also means the prompt is one constant in one file, so tuning the diagnosis never touches the page.
A single run costs roughly five US cents in API spend. The Worker exposes a /version endpoint that reports its version and whether the payment gate is on, because after one too many "which build is actually live" incidents, I wanted deploy verification to be a URL I can open on my phone.
The payment gate
Payment is Razorpay, India-first, Rs 399. The flow: the Worker creates an order, Razorpay handles checkout, the Worker verifies the payment signature server-side, and only then mints a one-time access token. Every gated call carries that token in a header, and the token is consumed the moment the report is emailed. One payment, one report. A coupon system lives in KV alongside it for gift codes and testing, with per-code usage counts.
The gate flag exists in three places: a constant in the Worker, a variable on the tool page, and the live state of the sales page. All three have to agree or the tool bricks, and I know this because I bricked it, live, by deploying a gated Worker against a page that had no idea payment existed. Every run returned a 402. That failure produced the three-flags rule, which is now written at the top of the Worker file where I can't miss it.
One thing I built and then deleted: country-gating the pay button, so Indian visitors got INR checkout and everyone else got a different path. VPNs and browser privacy shields confused the country check badly enough that some users needed three clicks to open checkout. I reverted it the same day. The button now always opens the INR checkout in one click, and international visitors see a standing invite instead: "Not in India? You are early," with an email link built at runtime so the address never appears in page source. A USD path is fully written and sitting dormant behind a flag, waiting on merchant of record approval.
The permalink decision
Reports used to live in the email and nowhere else. Delete the email and the report was gone, and it was a report you'd paid for. That felt wrong for a paid artifact, so every generated report is now stored permanently in KV and served at its own link: an unguessable 32-character id, marked noindex, with no expiry. The thing you bought outlives the transaction.
This also changed the email itself. The founder now gets a summary: the pattern, the scores, the one-sentence diagnosis, the hard truth, and one button to the full report. My internal copy keeps everything, the full report plus the raw answers, because reading what a founder actually wrote before a call is worth more than any CRM field.
Pricing, honestly
The tool launched free and got real traction, which was the good news and the problem in the same sentence, because every free run was an API bill I was paying for a stranger. The first plan was a $5 gate. What actually shipped was Rs 399 on the domestic Razorpay rail, India-first, because Razorpay was the rail that was live and approved, and I wasn't going to hold the launch for paperwork elsewhere. The price will move once there's enough social proof at this one; the report is worth more than Rs 399 and I know it.
What broke
The full list, because this is the part breakdowns usually hide:
- The first JSON error took a whole debugging round and turned out to be a wrong model name string.
- Email returned 401 for an evening because the Brevo key had been generated from the SMTP tab instead of the API keys tab. Same dashboard, different keys.
- The gated-Worker-against-ungated-page incident above. Every run, 402.
- Later, a subtler cousin: the email call was missing the token header, so every report generated fine and then silently failed to send. No error the founder could see. Found it in testing, not in production, which is the only reason I can type this sentence calmly.
- Contract drift: the page was sending the new request shape while the deployed Worker still expected the old one. A 400 on every generate until both sides matched. The Worker now accepts both shapes, permanently.
- I lost the v3 system prompt file, the one holding all eight patterns, and rebuilt it from build records. Backups exist now.
- A stale deploy served an older partial build for days because the upload had a nested folder and Cloudflare took the wrong directory as root. The rule since: the flattened build, index.html at the top, every time.
Nothing on that list is exotic. Every single one is an integration seam: page to Worker, Worker to Razorpay, Worker to Brevo, build to deploy. The diagnosis engine, the thing people would call "the AI part," was maybe a fifth of the total work. The other four fifths was payments, tokens, email templates, and failure paths.
What happens when it fails
Generation can fail; APIs have bad minutes. When it does, the page fires the founder's answers to my internal inbox, flagged for a manual run, with reply-to set to the founder, and it does this without consuming their token. So a retry still works, and even in the worst case where nothing automated recovers, I have everything I need to write their report by hand and send it myself. A paying founder never falls into a void.
What comes next, in order
The near-term list is hardening. A server-side payment webhook, so a captured payment gets recorded even when the buyer's tab dies mid-redirect; today the client-side capture covers most of that gap, and the webhook closes it fully. Local persistence, so a closed tab doesn't cost a session. And another round of prompt tuning as real reports accumulate. All three are written up with priority order attached. Shipping a working product beat shipping a complete one, and I'd make that trade again.
The product roadmap past that has four steps. International payments come first: the USD path is already written and sitting behind a flag, waiting on merchant of record approval, so founders outside India stop being early and start being customers. Then kits: packaged, actionable self-help workflows built per pattern, so a founder diagnosed with Founder Gravity or The Orphaned Middle gets the fix as something they can run themselves instead of a list they have to interpret. Then the agentic layer, exposed over MCP, so the diagnostic and its fixes can operate inside the tools a founder already works in rather than on a page they visit once. And at the top, a human layer at a higher price point, because some patterns need a person in the room, and by then the tool will have already done the first hour of that conversation.
The short version
Answers go in and a named pattern comes out, with a fix list you can start on Monday. Underneath it, a static site and a single Worker that I built and debugged myself, one seam at a time. Eight years of watching companies get stuck went into the taxonomy, and a few months of breaking things went into the machine that delivers it. Both halves were earned the same way.