The final story in our 'Meet the flespi team' series comes from the person who has been shaping flespi from day one. As the CEO and Chief Architect at Gurtam, Aliaksei Shchurko has played a key role in defining the product's architecture, vision, and long-term direction.
In this conversation, we talk about why flespi was created in the first place, how it has managed to stay relevant and consistent for a decade, what transparency means for a modern SaaS platform, and why solving real customer problems matters more than following trends. Let's dive in.
Chief Gurtam Architect, CEO
Do you remember the moment you decided to create flespi?
More or less, yes. At some point, Gurtam and Wialon had been evolving for years, and we were starting to see architectural limitations in the existing approach. At the same time, we experimented with a product called Wialon Kit, which was essentially Wialon without the user interface.
The idea came from demand within the market. Various companies – sometimes even competitors – were looking for something that could process telematics data without the full platform. They needed a backend layer that could standardize incoming and outgoing data streams.
We built Wialon Kit, but it never really gained momentum. There was simply too much inherited functionality and too many dependencies on different levels of the system. In many ways, it felt like a stripped-down version of Wialon Hosting rather than a truly independent product.
Eventually, it became clear that we wanted to build something new and fundamentally different.
Initially, the idea was to create a backend component that could eventually become part of Wialon itself. But as development progressed, two things happened. First, it took much longer than expected because we wanted to build it properly. Second, the architecture evolved so significantly that it became obvious Wialon could never fully adapt to it. The concepts were simply too different. At that point, flespi started its own journey.
Beyond the technical side, there were many new ideas we wanted to explore: a completely different customer interaction model, automated billing, a different pricing approach, public offers instead of traditional contracts, and many other things that were new for us as a company. flespi became a way to experiment with all of that at once.
flespi has been around for many years now. What's the secret behind its long-term success?
Consistency. The product is architecturally consistent. Whenever we decide to change something, we don't just patch one area and move on. We invest the time needed to make sure the change is implemented everywhere and that the overall architecture remains coherent.
Another important factor is that the people behind the product haven't really changed. The same people who built it in the beginning are still shaping it today. That means the original vision remains intact. The core goals haven't changed.
We're engineers first, so quality always comes before speed. At the same time, we're still capable of delivering something new incredibly fast – sometimes within days, sometimes within hours. On the frontend side, things can occasionally appear almost immediately.
How do you see the relationship between Gurtam and flespi today?
We've always tried to maintain a balance. On the one hand, we're part of the same company. On the other hand, flespi has always had its own identity and its own way of communicating with the market. The same applies to marketing and community activities.
Flespi conf was a very interesting experiment. Honestly, I'd be happy to repeat it. Everyone who attended was focused exclusively on flespi. The discussions were deeper, the content was highly relevant, and it was much easier to engage with the audience because everyone shared the same context. It was a very focused event, and that made it special.
At the same time, events like Telematics and Connected Mobility operate on a completely different scale. For visitors, a larger event is naturally more attractive because it brings together a much broader audience. You have speakers from outside Gurtam, hardware manufacturers, integrators, technology partners, and many other businesses connected to the industry. The networking opportunities are simply much bigger.
I think last year's event was an important first step, and it turned out to be very successful. Next year, on November 10-11, we'll likely see significantly more attendees, partners, and suppliers. In fact, we may eventually need to limit attendance simply because of the demand.
How do you divide your time between management and product work?
In a normal situation, management probably takes around 20% of my time. If there are serious issues that need attention, it can grow to 30% or 40%. During periods of rapid organizational growth, it was probably more than half of my time. But once things stabilize, I naturally return to product development and architecture. flespi may have a relatively small team, but there is an enormous amount of work that can be done. We're processing well over a million devices already, and that number continues to grow.
Would you say you're more of an architect than a manager today?
Absolutely. The company is structured in a way that allows me to do very little management directly. That's the only way a system like this can truly scale. So yes, architect is probably the more accurate description.
What does your workplace actually look like?
Most people probably imagine a large office, a private room, a long conference table… In reality, it's much simpler. We all sit together in the same room. I have the same desk as everyone else. Next to me is another developer, Jan Bartnitsky, across from me sits our backender, Alexander Adamovich, and Nadzeya Mikhailova, frontend, is diagonally in front of me. We're all sharing the same space and breathing the same air.
Like any group of people, we occasionally negotiate important things such as room temperature, whether the window should be open or closed, and all the other office classics. :) Fortunately, the lighting is automated, so at least we don't have to debate that. Overall, though, it works well. Everyone coexists peacefully.
Why has flespi chosen an office-first approach instead of going fully remote?
Personally, I struggle to imagine building products remotely. I don't see how you can keep people aligned, maintain a shared focus, or resolve questions quickly when everyone is working separately. Human interaction is simply different when people are physically together. Remote work is great when someone needs uninterrupted time to build something independently. But even then, people often need feedback from colleagues. They need someone to challenge an idea, discuss a solution, or offer an alternative perspective.
Doing that remotely is much harder. Product development isn't a sequence of isolated tasks. It's an ongoing stream of conversations, questions, and decisions. And beyond work itself, there's also the human aspect. If you spend weeks or months working completely alone, eventually it becomes monotonous. The social side of being part of a team matters. It keeps people engaged, motivated, and interested in what they're doing. That's one of the reasons people can enjoy working on the same product for decades.
Transparency has always been a major part of flespi. Why is openness so important to you?
Openness creates trust. And trust creates strength. If you're open about what you do, if you're willing to expose your work and your results, then nobody can really use that information against you. Originally, transparency was something we adopted because we wanted customers to trust us more. Today it's simply part of who we are.
It's become one of our core principles. You can see it across the entire ecosystem. Many of our tools are open source. Our traffic viewers, frontend components, and various utilities are publicly available on GitHub. Anyone can fork them, modify them, and build on top of them. We've invested heavily in maintaining that ecosystem. I don't see much value in hiding things unless there's a clear reason to do so.
Of course, there are exceptions. Device protocols, source code, and certain partner-related assets are not public. In many cases, those restrictions exist because of agreements with hardware vendors or other partners. But in general, if you're building enterprise software, trust becomes critical. Companies need confidence that their technology provider is reliable and predictable. They need to understand who they're working with, how the company has behaved in the past, how it's performing today, and how it might respond to future challenges.
Public statistics, growth numbers, and operational transparency all contribute to that trust. We don't publish numbers to impress anyone. We publish them because they're real. And that honesty helps larger companies feel comfortable building their businesses on top of our platform.
The platform keeps growing by tens of thousands of devices every month...
Honestly, I don't spend much time analyzing growth anymore. Just recently, I looked at the numbers and tried to understand where the growth was coming from. What I found was that there isn't a single company driving it. Growth comes from many different businesses. Some are expanding existing projects. Some are moving more devices to flespi. Others are building entirely new products on top of it.
As for the original reason behind the growth, it's actually quite simple. We're affordable. Some customers manage to bring their total cost down to just three to five cents per device. In some cases, it's probably even less. At that level, it's difficult for anyone to compete. The infrastructure alone would often cost more. But price isn't the whole story.
We're affordable, reliable, responsive, and we deliver quality.
All of those things reinforce each other. Could we grow faster? Probably. We could build enterprise sales teams. We could actively pursue large accounts. We could invest heavily in outbound sales. The question is whether that's actually necessary.
The current growth rate feels healthy. If growth becomes too aggressive, the company risks spending all its energy on onboarding and support rather than moving the product forward. Every new customer brings unique requirements, challenges, and expectations. Even with AI helping us, people still want personal attention. And our resources aren't unlimited. So from my perspective, we're growing at a sustainable pace. That's important.
How do different types of customers use flespi today?
There are two broad groups. The first group uses flespi primarily as an ingestion layer. We handle data collection, protocol support, and device communication, while the rest of their infrastructure exists elsewhere. The second group builds products directly on top of flespi. Those customers face a different challenge.
The platform evolves constantly. Features improve. New mechanisms appear. Things that required custom development three years ago can often be solved with built-in functionality today. As a result, some of those companies periodically need to refactor their own systems to take advantage of newer capabilities. Most of them are startups. Enterprise companies – the first group mentioned – tend to think differently. Large organizations rarely want to place everything in a single basket. Even if they trust us, they usually want redundancy, backup plans, and alternative data paths. That's simply how responsible businesses operate.
So I don't expect enterprises to move everything to flespi overnight. What we provide is a service. Companies that use it gain a competitive advantage because they can focus on their own products instead of building and maintaining the underlying telematics infrastructure themselves. Companies that choose a different path will have their own advantages as well. But in most cases, they'll spend more resources solving problems we've already solved.
Would you say flespi is becoming an AI-driven product?
That's a difficult question because AI itself is changing so quickly. Every few months, new capabilities appear that nobody anticipated before. Something that seemed impossible a year ago suddenly becomes practical. Likewise, ideas that sounded convincing a year ago may no longer make sense today. So I wouldn't make long-term predictions with too much confidence. Looking at the current generation of large language models and AI providers, I still see significant limitations. There are incredible opportunities, but there are also many constraints.
At this point, I don't see AI systems that can evolve completely without human involvement. Maybe we simply haven't learned how to build those systems yet. Maybe we'll get there eventually by adding more architectural layers and better feedback loops. But today, humans remain an essential part of the process.
Where does AI already play a significant role inside?
Practically everywhere. The most obvious example is customer support. For the past several months, AI has been handling roughly 98% of all support and customer service interactions. We've been sitting at that number for three or four months already. What's interesting is that users trust it. In many cases, they don't even seem particularly interested in talking to a human instead. And honestly, it's difficult for me to imagine turning it off now.
At any given moment, I can see the system handling multiple conversations in parallel. Two, three, four, sometimes even five simultaneous requests during working hours. If we suddenly removed AI and replaced it with humans only, people would immediately feel the difference. Most support conversations aren't generic questions. They're about projects, devices, integrations, architecture, and technical decisions. Users rely on that information to get real work done. AI has become a natural part of that experience.
What about engineering and protocol development?
We use AI heavily there as well. Protocol development, troubleshooting, code generation, and analysis – AI is involved throughout the process. That doesn't mean engineers have become unnecessary. Quite the opposite.
The amount of human involvement remains substantial. We're constantly reviewing outputs, correcting assumptions, refining implementations, and validating results. At the same time, AI contributes things that humans often wouldn't do manually. It can analyze logs, inspect errors, search through large volumes of account data, identify traffic patterns, investigate edge cases, and connect information across systems much faster than a person could. The combination of human expertise and AI capabilities is extremely powerful. It's not a replacement. It's a partnership.
Has AI fundamentally changed the way you personally work?
Yes, although perhaps not in the way people expect. Today, a significant part of my work consists of interacting with AI almost like a technical partner. We're exploring codebases together, analyzing architectures, discussing implementation approaches, and evaluating alternatives. There was a period when I delegated more actual programming work to AI.
More recently, I've found myself returning to hands-on development more often. The reason is context. To make good architectural decisions, I need to stay close to the code. I need to understand what's happening beneath the surface. Sometimes I revisit something that was implemented months ago and discover inconsistencies that weren't obvious at the time. Then I spend considerable effort cleaning things up, refactoring, and restoring consistency across the system.
As a result, a large portion of my work today falls into the category of quality control. Reviewing. Refining. Refactoring. Making sure everything fits together properly. AI accelerates development in many ways, but maintaining long-term architectural consistency still requires human judgment.
What about prompt engineering? Do you spend much time crafting prompts yourself?
Not really. I've learned that my understanding of English and an AI model's understanding of English are often very different things. The meanings we attach to the same words aren't always identical. And the model is usually better at understanding how to communicate with other models than I am. So instead of manually writing elaborate prompts, I typically work iteratively. I remove things. Adjust things. Clarify things. Simplify things. It's more of a collaborative process than traditional prompt writing.
Looking ahead, what role do you think AI will play inside flespi?
If all AI systems disappeared tomorrow, we'd still be able to operate. The product would continue to exist. The company would continue to function. That's important.
I don't want AI to become something we depend on blindly. At the same time, AI is now deeply integrated into almost everything we do. The way I see it, that's how things should remain.
AI should be present everywhere as a powerful supporting layer. But people should still be responsible for decisions.
People should provide critical thinking. People should ensure consistency. People should remain accountable for the final result. Human-in-the-loop isn't a temporary phase. For the foreseeable future, it's the right model.
Looking back, what advice would you give to your younger self?
Honestly, none. I wouldn't change anything. Every experience – good or bad – becomes part of whatever comes next. The successes matter, but so do the mistakes. Without both, you don't end up where you are. So if I could go back in time, I wouldn't try to correct anything. I'd let everything happen exactly the same way.
Then what has experience taught you over the years?
Probably the simplest lesson imaginable: If you keep doing things long enough, eventually something will work. At the beginning, I didn't think I fully appreciated how much could be achieved through persistence alone. You work. You experiment. You try things. You fail. You try again. And over time, progress accumulates. Most problems can be solved if you're willing to invest enough effort into understanding them.
Your familiar phrase – “It's not difficult.”
Not entirely. There are absolutely difficult problems. Really difficult ones. The important question is whether they're worth solving right now. Sometimes the smartest thing you can do is set aside a complicated problem and solve several simpler ones first. Progress matters more than complexity. People occasionally assume that successful products emerge from solving technically impressive problems.
Products succeed when they solve real human problems.
That's the only thing that matters. You have to understand people's pain points. You have to find them, understand them, and then build something that removes that pain. When you do that successfully, the product starts growing almost by itself.
So what makes a truly great product?
The best products solve genuine problems. People adopt them because they get value from them. They use them because they want to, not because somebody convinced them to. Everything else is marketing.
Marketing can create awareness. It can create interest. Sometimes it can even create demand. But products that genuinely solve problems don't rely on marketing alone. People recommend them naturally. They spread through word of mouth. Users bring in other users because the product makes their lives easier. Of course, good marketing helps.
Everything grows faster when marketing and product work together. But if the product doesn't solve a real problem in the first place, marketing can only take it so far. That's why we always try to start with the problem itself. The rest follows from there.