DEV Community: R.Karunya Naidu

Designing a tool that uses LLMs to negotiate SaaS prices. Looking for feedback on the architecture.

R.Karunya Naidu — Mon, 28 Sep 2026 17:08:04 +0000

One of the easiest ways to make an AI application difficult to use is to turn every capability into another screen.
While building DealMind, we wanted to avoid that.
The product has memory, evidence, strategies, what-if analysis, counteroffer guidance, customer history, and learning.
But the user should not feel like they are navigating seven different applications.
The solution was to organize everything around one object:
the current negotiation.

One simple workflow

The main workflow is:
Dashboard
↓
New Negotiation
↓
Analyze
↓
Recommendation
↓
Strategies / What-if / Counteroffer / Evidence / Customer
↓
Record Outcome
↓
Learning
This keeps the user's mental model simple.
The user starts with a deal.
Everything else exists to help with that deal.

New Negotiation

The New Negotiation screen captures information that matters to the negotiation:
• Customer
• Industry
• Segment
• Deal value
• Initial offer
• Customer counteroffer
• Requested discount
• Objection
• Competitor pressure
• Contract length
The user can enter their own negotiation.
There is also a demo scenario for quickly understanding the workflow.
The demo customer is not hardcoded into the product's identity.
The system should work with arbitrary customers and negotiation values.

The deal workspace

After analysis, the user enters the deal workspace.
Instead of creating separate permanent pages for every feature, the current negotiation contains tabs such as:
Overview
Strategies
What-if
Counteroffer
Evidence
Customer
This keeps the tools contextual.
For example, evidence is useful because it explains the current recommendation.
What-if analysis is useful because it lets the user explore the current deal.
Customer history is useful because it provides context for the current customer.
Everything belongs to the same workflow.

Making memory visible

Hindsight should not be hidden behind the backend.
One of the UX goals was to make memory visible when it matters.
The user should be able to see that the recommendation is based on historical experience.
Evidence identifiers help connect the recommendation to recalled memories.
This gives the user a way to understand:
What did the system remember?
and:
Why did that memory matter?

Handling uncertainty

A professional AI interface also needs to communicate when it does not have enough information.
If Hindsight is temporarily unavailable, the system should not pretend that it recalled historical negotiations.
Instead, the interface should indicate that historical memory is unavailable.
Similarly, if the LLM is unavailable and the application uses a deterministic fallback, that should be clear.
We considered this an important UX principle:
Uncertainty should be visible rather than hidden.

The 60-second workflow

The same design philosophy applies to the short product demo.
The demo should tell one story:

Load a negotiation.
Analyze it.
Recall Hindsight memory.
Show evidence.
Show confidence and economics.
Explore strategies.
Record the outcome.
Show the learning update. The user should be able to understand the entire memory loop without navigating through unrelated screens.

Why the learning loop affects UX

The learning feature also changes how we think about the product.
If the application only produced a recommendation, the workflow would end at the recommendation.
But DealMind continues:
Recommendation → Outcome → Memory → Future recommendation
That means the UX needs to make the outcome step visible.
The user should understand that recording the result is not just administrative work.
It is how the system gains another piece of organizational experience.

Keeping technical complexity away from the main workflow

Another design decision was keeping technical system information separate.
API health, memory configuration, and system status belong in Settings.
They should not dominate the main negotiation experience.
The salesperson's main concern is the deal.
The system's technical implementation should support that workflow without getting in its way.

Human-centered decision support

DealMind is designed to support the salesperson rather than replace them.
The interface presents evidence, calculations, strategies, and customer context.
The user decides what to do.
This makes the product feel more like a negotiation workspace than an autonomous chatbot.

Conclusion

The UX challenge in DealMind was not simply making the interface look good.
It was making the memory loop understandable.
The user should be able to see:
What the system remembered.
Why it mattered.
What the system recommends.
What happened afterward.
How that outcome can become future memory.__
That is what guided the DealMind workflow.
The product becomes more useful as organizational experience accumulates, while the interface remains centered on one simple thing:
the negotiation happening right now.