I realized the dashboard was not the product. The research engine was.
Traditional SaaS has mostly been about building a web app.
You build a UI layer, create dashboards, add workflows, onboard users, teach them how to use the product, and then keep improving the interface so that users can get more value from it.
I have been trying to build something in the Indian options trading market for quite some time now.
The Indian options trading space already has a lot of strong players. Platforms like AlgoTest, Tradetron, Stockmock, Quantman, Stoxxo, and others have already built serious products for traders.
At the same time, the market itself has changed a lot.
A once booming options trading ecosystem has gone through multiple regulatory changes. User growth has not been as easy as it looked from the outside. The opportunity still exists, but it is not the same market it was in 2021, 2022, or even 2023.
Back in 2023, I also wanted to jump into this space.
My first product was an order management system. The idea was simple. Traders could plug in any strategy code and use our dashboard for execution, order placement, modifications, monitoring, and live trading.
It sounded useful, but it did not really work as a standalone product.
So I pivoted.
That is when I started building BuildAlgos, a custom no-code and low-code DIY platform where users could build, backtest, and deploy their trading strategies.
But I did not want to build another fixed-template strategy platform.
Most trading platforms make users choose from predefined rules, time-based entries, fixed indicators, and limited templates. I wanted to build something more flexible.
So we built an N8N-style flow-based strategy builder for trading.
Users could drag and drop blocks, create their trading logic visually, and internally we would save that logic as JSON. Then our system would convert that JSON into Python code based on our strategy framework.
The same framework could run both backtesting and live deployment.
It was honestly a very hard product to build.
There were too many moving parts.Strategy logic. Backtesting. Live execution. Order management. Broker integrations. UI. Flow builder. Code generation. Risk management. Debugging. User education.
We spent a lot of time building the product.
But after building it, we realized that we had to spend almost equal time explaining it to users.
How to use the builder. How to think in blocks. How to debug a strategy. How to convert their idea into a flow. How backtesting and live deployment worked.
For a while, that was fine.
But then we got hit by a bigger problem.
After SEBI’s algo trading regulations, live trading became a much more complicated area. There were ways in the market to work around some of these restrictions, but I personally did not want to build something that went against the intent of the regulation.
So we paused live trading.
And once live trading was paused, the entire product became difficult to position.
Because what were we now?
A builder? A backtesting platform? An execution platform? A research tool?
I was not fully sure.
Around the same time, I started using AI much more seriously.
Before 2026, I mostly used AI like a better copy-paste coding assistant. But from around February 2026, I started getting real confidence in what AI agents could actually do.
Not just answer questions.
Actually reason through problems. Write code. Debug. Use tools. Run loops. Compare outputs. Improve ideas.
Since we already had a strategy framework, data handling, and backtesting infrastructure, I started thinking:
What if I use the existing framework for research instead of trying to force everything into a web app?
That is when I built the first MCP server.
Initially, it was not some big product decision.
It was more of an experiment.
I wanted to see if an AI agent could connect to our backtesting engine, understand the tools, write strategy logic, run backtests, read results, and then continue the research loop.
And honestly, the experience was insane.
The moment I pushed it into Claude as an MCP server, the entire workflow changed.
Instead of me building a full AI harness inside my own web app, Claude already had the agentic loop.
It could understand the user’s prompt. It could call the right tools. It could write strategy logic. It could run the backtest. It could inspect the result. It could modify the logic. It could compare variations. It could continue the research.
That is when it clicked.
Maybe the product does not need to be another web app.
Maybe the product should simply give AI agents the ability to do real trading research.
This is why we started productizing Volrix as an MCP server.
With the MCP server, the user does not need to learn a new platform.
They do not need to understand our UI. They do not need to learn a flow builder. They do not need to leave Claude, ChatGPT, or whichever AI tool they already trust.
They can just connect Volrix and start prompting.
The onboarding that earlier needed explanation, demos, videos, and support calls became a five-minute setup.
And because everyone already knows how to prompt, the product became much easier to understand.
The user can simply say:
“Backtest a 9:20 straddle with 30 percent stop loss.”
Or:
“Test this only when VIX is above 14.”
Or:
“Compare this strategy across different stop losses and exits.”
Or:
“Find where this strategy fails.”
The AI agent handles the research flow, and Volrix handles the backtesting engine.
That difference is very important.
Earlier, we were building the interface, the workflow, the education layer, and the engine.
Now, the AI agent becomes the interface.
Volrix becomes the engine.
That is a much cleaner product.
I shared the MCP server in a traders’ group of around 100 people. More than 60 people signed up almost instantly. We also got a good response on X .
That does not mean the product is already successful.
But it does mean the direction is interesting.
Because the friction is much lower now.
Users do not have to learn “our way” of building strategies.
They can describe ideas in their own words.
The AI agent can convert those ideas into research.
And Volrix can run the actual backtests.
This is the biggest reason we decided to turn the product into an MCP server instead of building another web app.
It was not because web apps are bad.
Web apps are still useful.
But for this particular product, the core value was not the dashboard.
The core value was the research engine.
And if the best interface for research is now an AI agent, then it makes more sense to connect the engine directly to the agent instead of forcing users into another UI.
That is the bet we are taking with Volrix.
A backtesting and research engine for AI agents.
Not another dashboard.
Not another fixed-template strategy builder.
Not another app that users have to learn from scratch.
Just connect it to your AI tool, describe your trading idea, and let the agent research with real backtesting tools.
You can try it for Free at Volrix.ai