Sergei Vertepov joined Faraway in December 2024 and wrote backend code for games. A month later the game project was shut down. The team moved to a trading service, and since May 2025 it has been building the Rift mobile app from scratch.
Vertepov is responsible for its financial core: balances, transactions, portfolio and market analytics, and token handling. He made the first architectural decisions across all four areas on his own.
He has more than ten years of backend experience, at companies ranging from two people to several thousand employees. We spoke about where mobile trading is heading and what is hardest to build on the server side.
Sergei, hello. You joined the company to write backend code for games. How long did that last?
Hello. About a month. I joined the project, got up to speed, and started writing code. Then the project was shut down. That happens in this industry. The decision was the company’s.
What did the team do next?
We took on a trading service. The first version was set up as a website. It ran automated modules and software agents. On paper the idea looked right.
What turned out to be wrong?
It was inconvenient to use. And complicated.
The work was already done. How do you make the decision to delete it?
With difficulty. Nobody likes deleting work that is already finished.
But we looked at the alternative. We could have added more features and confused the product completely. We chose a different route: we stopped and started over.
Since May 2025 we have been writing the current app from scratch. The task sounds simple: the user buys the asset they want in a few taps.
So literally from a clean slate.
Yes. The previous version gave us an understanding of what not to do. That is a result too.
What does simplification mean on the server side?
On the server side, simplification almost always means added complexity. The user presses one button. Behind that button several services have to agree with each other.
We need to show the current balance, calculate portfolio analytics, pull a fresh asset price, and process the transaction. All of that has to happen within the time a person is willing to wait.
Let’s start with balances. Why is that a separate problem?
The balance has to look the same everywhere in the app. It has to update quickly. And it must not cost the company extra money.
The last point needs explaining. Balance and market data come from external sources. Those sources charge for requests. The simple solution looks like this: request everything, all the time. The bill for that solution grows along with the number of users.
Three requirements pull in different directions. Speed asks you to request more often, cost asks you to request less often. Consistency adds a third condition: every part of the app has to hold the same value. Our balance architecture grew out of the search for an equilibrium between those three.
Are transactions and token data built on the same logic?
Partly. Transactions have a requirement of their own: the history has to be stored so that it never gets lost and can be reconstructed at any moment. The user has to see what happened to their money and when it happened.
Tokens are handled by a third system. The app offers a large number of assets, and each one needs fresh data. We update that data and store it on our side.
What does reactivity mean inside the app?
The user does not press a refresh button. They open a screen and the data there is already current. Prices move, and the numbers on the screen move with them.
For the server this means a constant stream of updates going out to the client. Keeping that stream economical is a separate piece of work.
You made all four of those decisions alone at the start. What did that look like?
In the early stages I defined the architecture. The team is small now, and everyone has their own area of responsibility. Mine is balances, transactions, portfolio and market analytics, and tokens.
So there was no one to argue with.
No one. Task speed goes up because of that, but decision review gets weaker: nobody will catch your mistake for you.
You have worked at companies ranging from two people to several thousand. Does a small team require a different approach?
It does. At a large company you are responsible for your own section, and there are people nearby who will cover the neighboring ones.
In a small team that section expands to everything connected to your area. Questions that would go to another department at a large company stay with you here.
Experience at different scales helps most in exactly this situation.
Games and finance: how different are these tasks for a backend developer?
The tools are largely the same. What changes is the cost of an error. In a game, a failure annoys the user. When a person keeps money in the app, the same failure costs trust, and trust is harder to win back.
Learning a new domain is not hard for me. I learn quickly. In ten years I have not been given a task I could not figure out. The financial side took time, but it turned out to be manageable.
What is mobile trading becoming today?
I will answer through what we did ourselves.
The number of user actions is going down. Trading apps spent a long time copying the professional terminal: many screens, many settings, many decisions left to the person. We walked that path in our first version and walked back. The work now runs in the other direction — remove steps, keep the result.
Along with that, the way data is delivered is changing. People stop pressing refresh and stop comparing numbers across tabs. The data comes to them on its own. From the outside this looks like an interface detail. For the server it is a different set of requirements.
There is one more observation. The cost of data is becoming part of the architecture. External sources charge for requests, and the number of users multiplies that charge. An engineering decision here has a direct effect on the economics of the product. This used to be the last thing anyone thought about.
A Working Product Was Deleted: What That Costs a Company
The decision this interview is built around is one that companies rarely make. The web version of the trading service worked. It was deleted because it was difficult to use.
The usual approach is different: you refine a finished product, add features, and explain to the user where everything is. Writing off working code means admitting that the work already done came to nothing, and everyone who paid for that work has to agree to it.
Faraway agreed to the write-off. By May 2025 the team had started again, and Vertepov designed the financial part of the new app from the first line. Buying an asset in it takes a few taps, which is exactly what the deleted version failed to deliver.
