The first reason we built SwiTra was that we wanted to work directly with large volumes of data.
We wanted to work with large volumes of data
In day-to-day development, there are not many opportunities to work in an environment where hundreds of thousands of data records arrive continuously. Market data seemed like a practical subject for applying stream-processing technologies such as Kafka and Flink.
We wanted to go beyond a technical experiment and turn it into a product that could stay in operation. At this point, however, we had not yet decided exactly what that product would be.
The difficulty of continuously monitoring charts
The shape of the product became clearer through conversations with people around us.
We heard that finding the moment when a desired condition appears requires repeatedly checking charts, but continuously watching a screen is difficult in practice. Automatically detecting that moment and sending an alert seemed like a way to reduce this burden.
Our research showed that services for combining technical indicators and receiving alerts already existed. However, configuring the indicators and conditions we wanted did not look easy to approach.
A problem we could address through technology and UI
There were two distinct challenges in this problem.
The first was a technical challenge: process a continuous stream of market data and determine whether each user's conditions had been met. The second was a UI challenge: make it easier to combine indicators such as RSI and MACD using AND and OR conditions.
Our technical interest in processing large volumes of data met the difficulty of continuously monitoring charts at this point. We thought we could address the problem by designing the underlying technology and the interface together. That was how we started building SwiTra.
Being able to build it is not the same as knowing it is needed
What we had observed at the time was a problem raised in conversations and the configuration experience of existing services. That alone did not prove that many people shared the same problem or that SwiTra's approach would be the right solution.
SwiTra did not begin with thoroughly validated demand. It began with a technical problem we wanted to solve and a practical frustration we had encountered through conversation.
Being technically able to build something and giving people a reason to keep using it are different questions. SwiTra started with the first question. Now that it has launched, we are observing the response to answer the second.