The Archieve of PROCLI

I think what qualifies as an MVP has changed in practice, particularly in markets where customers already have credible alternatives. A founder may see an early version with potential, while someone trying it sees something less useful than the tool they already use. Calling it an MVP explains its stage of development, but it doesn’t give that person a reason to make room for it.

The purpose of starting small is to learn before committing substantial resources. What deserves more attention, in my view, is how much of the product must exist for that learning to be meaningful. A mockup can reveal whether someone understands an idea, but it offers limited evidence about adoption when the proposed advantage depends on reliability or the effort saved during actual use. The experiment needs to demonstrate the quality on which the business intends to compete.

In a red ocean, where businesses compete for existing demand, customers bring expectations shaped by what is already available. A recognisable problem gives me a starting point, but I also need to understand how adequately it is being solved and whether the remaining dissatisfaction is strong enough to motivate a change.

That makes the current alternative an essential part of evaluating a new product. I want to understand what customers spend on their existing approach, including the less visible effort of working around its limitations, and what adopting mine would require. A technical improvement may have little commercial significance if its benefit is too small to justify that transition.

Lower development barriers make this assessment more important. The tools that help me build affordably may also make it easier for someone else to reproduce the idea, so I cannot treat implementation alone as a lasting advantage. At the same time, easier development doesn’t necessarily make customers easier to reach. An established provider may already have their trust and a place in their workflow, both of which a new entrant still has to earn.

I therefore see two questions that need separate answers: what would persuade someone to adopt the product, and what would allow the business to keep earning that choice as competitors respond? The first helps define what an MVP should demonstrate; the second influences whether the opportunity warrants further investment.

Procli brings those questions into my own work. It began around confidence in AI-assisted development, but the importance of that problem doesn’t settle the product’s position. I also have to consider whether customers value that capability as a separate purchase or expect it to be included in the development tools they already use.

If an existing provider introduces a similar capability, the comparison changes. A standalone product might still offer greater value, but that difference must justify an additional cost and another dependency. I need to understand where that difference would matter enough, rather than assume that a useful capability naturally supports an independent business.

That is why Procli is currently on hold while we reconsider its positioning. I want the next investment to investigate a specific opportunity: a situation where existing alternatives fall short in a consequential way and where Procli could offer an improvement worth adopting.

The next version should be scoped around making that comparison possible. It can remain narrow, but it needs enough depth for someone to assess the proposed advantage in their own work. A positive reaction to a demonstration would be encouraging; choosing to use it again when their existing tools remain available would answer a more substantial question.