We almost submitted a new ForgeXRM product to Microsoft even though something about it didn’t feel finished.
Development was complete. The requirements had been addressed. On paper, the solution was ready for Microsoft Marketplace certification, and the team was ready to move on.
But something kept nagging at me.
I’ve been involved in building business applications for a long time, and I’ve learned not to ignore that feeling. A product can be technically complete and still not feel ready. All the individual pieces may work, but the overall experience may not be as clear, intuitive, or well thought through as it needs to be.
I’d like to say another full review had always been part of the plan.
It wasn’t.
We were close to submitting, and it would have been easy to tell ourselves that anything left could be handled in a future release. Instead, we decided to slow down and put the product through one more end-to-end review.
This time, I used Claude Fable 5 to help us look at it from a different perspective.
What came back changed more than the product. It changed how I think about AI, model selection, judgment, and the role I want to keep playing as we build what comes next.
The Concerns I Could Feel but Couldn’t Explain
I asked Fable 5 to review the solution from top to bottom and evaluate the overall experience.
It took much longer than I expected.
Most AI tools have trained us to expect an immediate answer. You ask a question, wait a few seconds, and something appears. This was different. The process went on for hours.
I checked more than once because I thought something had gone wrong.
When the response finally came back, it was worth the wait.
Fable surfaced real issues. These weren’t generic recommendations or a list of small cosmetic changes. They lined up closely with concerns I had been carrying but hadn’t been able to clearly explain.
Of the five issues I had been quietly wrestling with, the review helped us resolve three.
We’re still working through the other two.
Honestly, I’m glad we found them before we shipped.
It Didn’t Replace Our Judgment
The most valuable part wasn’t simply that AI found something we had missed.
It was that AI helped me better understand something our own judgment had already picked up on.
I don’t see AI as a replacement for experience, intuition, collaboration, or accountability. The model didn’t know our customers the way we do. It didn’t understand every decision our development team had made. It didn’t own the product decision, and it wouldn’t be responsible for supporting what we released.
That responsibility was still ours.
What it gave us was another perspective. It had the patience and capacity to examine the entire solution, question assumptions, spot patterns, and explain where the experience didn’t completely hold together.
I can’t speak to everything happening under the hood, but the experience felt different from a typical prompt-and-response interaction. It didn’t seem to rush toward the first reasonable answer. It looked at the problem from several angles and came back with a much more complete assessment than I expected.
It felt less like asking a tool for an opinion and more like handing a difficult assignment to someone who could work through it independently.
That doesn’t make the human role less important.
It makes the quality of our questions, collaboration, and decisions even more important.
Models Matter
I was an early adopter of Fable 5 and started exploring it when it was first released.
So this wasn’t my first interaction with the model. I had already tested it, learned some of its strengths, and compared the experience with other AI tools I use regularly.
What changed during this review was the size and importance of the assignment I was willing to give it.
There’s a difference between experimenting with a model and trusting it with a meaningful business problem. This was the first time I gave Fable 5 the full context of a product, asked it to work through the experience from beginning to end, and gave it the time to do the deeper work it was designed to do.
That experience reinforced something I think gets lost in the broader AI conversation.
Models matter.
We sometimes talk about AI as though every model is interchangeable. Pick the most convenient one, ask the question, and expect roughly the same result.
That hasn’t been my experience.
Some models are excellent for fast answers, writing assistance, summaries, and everyday problem-solving. Others are better suited to complex assignments that require more context, sustained reasoning, and a willingness to explore the problem before committing to an answer.
The deeper-thinking models usually consume more resources. They take longer, and they can cost more.
That makes it tempting to reserve them for rare situations or choose a less expensive model simply because the immediate price is easier to measure.
But that raises another question.
What is the cost of not using the stronger model?
Consumption Cost Isn’t the Only Cost
The cost of an AI interaction is visible.
The cost of a missed issue usually isn’t.
It may show up later as additional development work, another round of testing, a delayed release, more support time, or a customer encountering a problem we could have addressed earlier.
Those costs are much harder to calculate, but they are real.
In this case, the deeper review helped us identify issues before submitting the product to Microsoft. Even if the model consumed significantly more than a quick review would have, that cost was small compared with the potential cost of revisiting the product after certification had started or after customers began using it.
The same applies to prototyping.
A more capable model may cost more during a long working session, but it can help us explore several ideas, rule out weak directions, and bring a much clearer concept to the development team.
That doesn’t mean the most expensive model should be used for everything.
It means price shouldn’t be the only factor in choosing one.
The right question is not simply:
How much will this model cost to run?
It is also:
What could it cost us to use a model that isn’t capable enough for the assignment?
For simple work, speed and efficiency matter.
For consequential work, depth may matter more.
Product Discipline Isn’t Just About Shipping
There’s constant pressure in software to move faster.
Release the first version. Get it into the market. Learn from customers. Improve it later.
There’s value in that approach. Products don’t get better by sitting forever in a development environment.
But speed can also become an excuse.
There’s a real difference between releasing a focused first version and releasing something before the experience has been fully considered. There’s also a difference between accepting reasonable limitations and leaving customers to discover problems we already suspected were there.
At ForgeXRM, we’re not trying to release the most features in the shortest amount of time.
We’re trying to build products that are repeatable, supportable, and able to hold up in a real customer environment.
That takes input from product, development, customer experience, and support. It means knowing when to move ahead, but it also means knowing when to pause.
Delaying the submission didn’t feel efficient at the time. Development was complete, the certification process was waiting, and the team was ready to move on.
But submitting the product wouldn’t have made the unresolved concerns disappear. It would have simply pushed them into a later release, or worse, into the hands of a customer.
Slowing down was probably the faster decision in the long run.
The Part That Surprised Me Most
The review itself was valuable, but it wasn’t the part of the experience that stayed with me most.
A short time later, I spent nearly twelve straight hours using Fable 5 to prototype ideas for a second version of our Data Grid configuration experience.
Twelve hours sounds excessive.
It probably was.
But I hadn’t felt that absorbed in a product design session in a long time.
Our current configuration screens reflect a significant amount of thought, design, and development from the team. They’re already moving through Microsoft’s certification process, and I’m proud of where we landed.
During that prototyping session, though, I started seeing possibilities for the next version that would have taken much longer to explore in the past.
I could test an idea, question it, change direction, and try another approach without losing the momentum of the original thought. Concepts that might once have stayed as rough notes could quickly become something tangible enough for the team to react to and improve.
The AI didn’t provide the vision.
It gave me a faster way to work through the vision and bring better-defined ideas back to the team for discussion, refinement, and development.
That brought me back to the part of the business I enjoy most: taking something promising, seeing what it could become, and working with talented people to shape it until the experience feels right.
What This Means for How We Build
This experience didn’t convince us to turn product decisions over to AI.
It reinforced the value of combining AI’s breadth and persistence with the context, technical expertise, judgment, and accountability our team brings to the work.
That combination is becoming part of how we build at ForgeXRM.
AI can help us explore more possibilities, question our assumptions, and identify issues earlier. It can speed up prototyping and help us investigate ideas that might previously have stayed out of reach because of time or resource constraints.
But people still have to decide what belongs in the product.
Our developers have to determine what can be responsibly engineered and supported. Our team has to understand the customer, weigh the tradeoffs, recognize when an answer is technically correct but practically wrong, and take responsibility for what ultimately ships.
Part of that responsibility now includes choosing the right AI model for the work.
We don’t need maximum depth for every question. But when a decision could affect the quality of a product, the experience of a customer, or weeks of development effort, selecting a model based only on the lowest consumption cost may be the most expensive decision we can make.
That isn’t a limitation of AI.
That’s the work.
What I Learned About Myself
I don’t think I’ll approach another product review or prototyping session in quite the same way.
But the bigger realization was more personal.
AI didn’t make me less relevant to the product development process. Used the right way, it allowed me to spend more time doing the work I’m best at, while giving our development team clearer ideas and better-defined problems to solve.
Recognizing when something isn’t quite right.
Asking the next question.
Evaluating the tradeoffs.
Connecting ideas that don’t initially seem related.
Imagining what a product could become.
Working with the team to determine what’s realistic.
Choosing the right tools and models for the importance of the assignment.
And knowing when what we’ve built is finally ready to leave our hands.
Nearly twelve hours into that second prototype, I was tired but completely absorbed. I hadn’t felt that energized by a product design session in a long time.
That may be what I learned most from Fable 5.
The future isn’t about stepping away and letting AI build for us.
For me, it’s about finding a better way to stay deeply involved in the work I still love, while helping our team build better products together.
Check out the products ForgeXRM has built.
By Ryan Plourde, ForgeXRM, www.forgexrm.com
