Why I built a business diagnostic with no AI in the engine
I'm a systems engineer, and I've run small businesses from many angles: handmade products, print-on-demand, digital products, creative work.
Across all of them I kept seeing the same pattern: people doing genuinely good work, putting in real effort, and still falling behind. Not because the product was bad, but because the owner couldn't see which part of the business was holding the rest back. That always felt unfair to me. Good work should reach the people it was made for.
Most small business advice works symptom-first. The owner feels something ("I need more visibility", "my prices must be wrong") and gets tips for that feeling. But the symptom is rarely the constraint. A shop with zero sales asking "should I lower my prices?" doesn't have a pricing problem, nobody has seen the prices yet. In systems engineering you don't fix the part making the most noise. You trace the system and find what's limiting everything else.
Coheriv is that tracing step turned into a method: see the whole system, find one constraint, run one 30-day improvement cycle.
One design decision I keep having to defend: the engine is deterministic. No AI in the diagnosis. I use AI heavily as a build tool, but the same answers should always produce the same result, and every score should be traceable. A diagnosis you can't reproduce is an opinion.
It's live, it's early, and I'm now in the part I'm worst at: getting it in front of real people.
Happy to answer anything - especially from folks who've built diagnostic or assessment products.
This resonates a lot, just aimed at a different layer of the same problem (I'm the founder of FounderFlow, mentioning since it's relevant). You're finding the one constraint holding a business back, we're trying to catch the one thing that actually needs a founder's attention today instead of the ten things that are just loud. Same principle underneath, the loudest problem and the real problem are rarely the same one. Also agree hard on traceability, a diagnosis or a flag you can't reproduce or explain is just an opinion with better formatting. Curious how you handle it as the business changes month to month, does someone have to manually re-run the diagnostic, or does it notice when the old constraint stops being the real one?
Thanks, this made me think. Same principle, different layer. Took a look at FounderFlow, you're watching the day-to-day stream, I'm doing a point-in-time X-ray of the whole system. Honestly they could sit side by side in the same founder's toolkit.
On your question: it's manual right now. Coheriv runs as a monthly loop: you spend 30 days on the constraint, then re-run the diagnostic to see if the breakpoint moved. Same inputs give the same result, so if a new run points somewhere else, that's the business changing, not the tool having a mood. Automatic drift detection is on the roadmap, but I'd rather earn that with real usage than build it on a guess.
Good luck with the launch, by the way.
Thanks, same to you. I like that framing, FounderFlow's the daily stream and Coheriv's more of a deep check-up, they'd actually sit well side by side like you said. Manual monthly loop makes sense too, especially since reproducibility is the whole point of what you built. If you ever get to automatic drift detection, I'd love to see how you keep it deterministic. Good luck getting more people through the door.
This really resonates—especially the “don’t fix the loudest problem, fix the constraint” mindset. That alone puts you ahead of most advice in the small business space.
The deterministic angle is interesting too. I think you’re right that reproducibility builds trust, especially for something diagnostic. If someone gets a different answer every time, it immediately feels like guesswork. That said, you might eventually find a sweet spot where AI sits around the system (explaining results, suggesting experiments), but not inside the scoring itself.
On distribution: one thing I’ve seen work well for products like this is turning the diagnosis into content loops:
anonymized “before → constraint → intervention → result” breakdowns
short case studies showing how one bottleneck change shifted outcomes
even letting users share their “constraint report” publicly
It makes the abstract system tangible and builds credibility fast.
Also curious—how are you currently validating that the identified constraint is actually the constraint? Are you tracking post-diagnosis outcomes over those 30-day cycles?
Thanks... "AI around the system, not inside the scoring" is a sharper way to put it than I've managed. Might borrow that.
That line actually maps to how I think about it. There are three places AI could sit: building the thing (I used it heavily there), scoring the diagnosis (deliberately kept out, that's what keeps it reproducible), and explaining the result after the fact (currently deterministic too, but that's the layer where I think it could sit later, exactly like you said). So the scoring stays a closed engine, and AI, if it comes in, only ever wraps around it. Never touches the number.
The content loop is close to what I already do by hand: diagnosing real small business cases in threads (someone asks "should I lower my prices?" when the actual constraint is that nobody has seen the prices yet). Turning those into anonymized before/constraint/after write-ups is the natural next step.
On validation - the mechanism is built in: the paid package has a 30-day workbook and tracker, and the loop is diagnosis -> 30 days -> re-run -> did the breakpoint move. So a single user can validate their own result. What I don't have yet is the aggregate: enough real diagnoses to say "across N businesses, the constraint held up X% of the time." That comes with volume, which is what I'm working on now.
Just checked it and had a demo, and i must say its actually a good decision to keep AI off it, anyone can have a LLM ask them questions and analyze it for them, the issue is always about the credibility before commitment. AI would change the answer every time a little.
Now, as for the questions, you could offer a bit diverse options or a "write it" for those cases where your provided options don't match with what the issue is. eg: If a person previously chose that that people aren't finding it, and the next question asks how steadily new people come, then what if someone has no lead yet? let's say they chose rarely, then being asked "what people say most often" creates a gap, from here the path diverges where the person who tried yet no lead came to analyze has no other option just to guess when the system asks them no need to guess... I haven't tried all paths, but what is great is that the analysis and solutions are consistent, the score varies between ~2-7 points for same answers too, but that is fine.
As someone building my own product on pure research, logic and formulas where ai is just a good to have background part which can be removed and the product still delivers the result, i honestly appreciate this approach. Do provide a clarification if i'm wrong somewhere. Good luck and once again, it's genuinely a good approach.
Thank you for actually running it, this is exactly the kind of feedback I hoped for.
You caught something real with the question path. When someone has no leads yet, the current version still routes them into customer-behaviour questions and forces a guess. That's the main thing I'm fixing in the next engine version: a proper "no signal yet" route where the system stops instead of fabricating a diagnosis from guessed answers.
The 2-7 point variance is interesting and I want to trace it. The scoring itself is deterministic (same inputs always compute the same score), so my first suspicion is the adaptive path: on a retake, did you get the exact same questions, or did some of them differ? If the path differed, that's the path-dependence I need to normalize. If the questions were identical and the score still moved, that's a bug and I'd genuinely love to know.
Either way you've already shaped the next version. Thanks for taking the time.
I like that you're treating diagnosis as an engineering problem rather than an AI problem.
The point that stood out to me was reproducibility. If the same business can receive different diagnoses from the same inputs, founders end up trusting the system less than their own intuition. Making every conclusion traceable and deterministic feels like a strong design principle for a diagnostic product.
Thanks... "trusting the system less than their own intuition" is exactly the failure mode I was trying to avoid. A tool that gives a different answer each time doesn't just feel unreliable, it quietly teaches you to ignore it.
The traceability part matters to me for the same reason: every score points back to specific answers, so if a founder disagrees with the result, they can see exactly which inputs drove it and push back. A black box can't be argued with, and a diagnosis you can't argue with is one you won't act on.
I'm glad it resonated.
Reading your reply gave me one thought about what changes once founders stop trusting the diagnosis because it's correct and start trusting it because they can inspect the reasoning behind it. I'd rather explain it in the context of what you're building than try to condense it into a few comments.
If you're interested, what's the best email to reach you on?