An interview with Vitali Tsikhanovich – a developer building fintech products with engineering precision
Vitali Tsikhanovich came to fintech from civil engineering. For over a decade, he designed buildings, estimated budgets, and calculated structural loads. Programming was a parallel life – as a kid, before he even had a computer, he was writing code by hand on paper.
At some point, those two worlds swapped places. Today, Vitali is an Android developer at the major European Fintech company, and his engineering background shapes how he approaches mobile product development.
We had a conversation with him about how engineering thinking differs from a typical developer mindset, how designing buildings connects to designing applications, and why technology only matters when it solves real human problems.
Vitali, what made you leave engineering for software development? And why fintech?
It wasn’t a spur-of-the-moment decision. I’d been coding since childhood, but for a long time I wasn’t ready to fully switch. I worked as an engineer until 2019, coding in parallel. Eventually, I realized I wanted to build things that work differently – that scale differently.
In construction, the result is physical. A building stands, you can touch it, walk inside it. But it won’t reach beyond a single city. In software, you create systems that can work across ten countries at once – for thousands of people.
And why fintech specifically? Money is infrastructure – like plumbing or electricity in a building. If the system fails, everything else breaks. I was curious to apply my engineering mindset to this space.
You see, financial services are often designed by people thinking in terms of business logic or UI/UX. I think in terms of load, resilience. What happens when the system fails? How does it recover? These are baseline questions in construction.
Most developers think about architecture too. What’s the difference in your approach?
Developers often see a system as a set of features to implement. I see a structure. It has to bear load, and not collapse when conditions change.
In engineering, you constantly ask: what could go wrong? What if the load exceeds the design? There have to be safety margins, alternate load paths. In software, that’s error handling, fallback scenarios. The system has to degrade gracefully, not crash completely.
In Spring 2024, you launched Transfer To Cash – a service for sending money to people in Ukraine without bank accounts. Why was that important
Because it’s a real problem – and it couldn’t be solved with what was already on the market.
Imagine you need to urgently send money to a relative in Ukraine. They don’t have a bank account – maybe they moved, maybe the bank’s not working, maybe they’ve never had one. Traditional transfers require registration and take days. But that person needs the money now, not next week.
I designed a system where the whole process takes ten minutes. The sender makes the transfer through the app, the recipient goes to any branch in the banking network with a passport and a code they receive after the transfer. That’s it. A 2.3% fee, no hidden charges.
Why Ukraine specifically?
Because it’s especially relevant right now. People are on the move, infrastructure is disrupted, access to banking isn’t guaranteed. Also, I’m from Belarus – I understand how financial systems work there, and what barriers ordinary people face in this part of the world.
For me, it wasn’t an abstract tech challenge. It was about helping people when help is actually needed.
You were the only Android developer on the project. How is it even possible to design and build something like that solo?
Well… it means you’re responsible for everything.
I chose the tech stack. Designed the architecture. Wrote the code, tested it, fixed the bugs. At the same time, I coordinated with the backend team, the people integrating with banks, and compliance.
It’s a huge responsibility. If something goes wrong – it’s on you. There’s no one else to blame. But it also gives you freedom: you’re not wasting time on alignment meetings or debates about approaches. You see a problem – you fix it the way you believe is right.
Wasn’t it scary to take on that much responsibility?
At times, yes. But when you’re the only one, you can’t afford bad architecture. You’ll be the one living with it.
You can’t just hack something together “for now” and hope someone else cleans it up later. That kind of pressure keeps you disciplined.
Another upside – there are no seams in the code. When one person does the UI, another writes the business logic, and a third handles networking, it often doesn’t fit together cleanly. Here, it’s all one vision, one set of hands.
Right after Transfer To Cash, you launched AI-powered invoice scanning. You take a picture of a bill – and the system extracts all the payment data. That’s more than just OCR, right?
Right – it’s not just OCR. OCR will tell you: here’s a number, 1500.00; here’s a string, LT12345… But it doesn’t understand that the first is the amount to pay, and the second is the recipient’s IBAN. Our system understands the document’s structure. It sees context.
You open the camera in the app, point it at an invoice, take a photo – and boom, you’ve got a payment draft. Just review and confirm.
For small businesses that pay dozens of invoices a month, it’s the difference between hours of repetitive work and just a few minutes.
And it’s a purely mobile solution, you know? On the desktop, you’d have to scan the document, upload the file, and wait for processing. On a phone, the camera’s already there – it’s instant. Almost no friction.
Both projects – Transfer To Cash and the invoice scanner – help people in vulnerable situations. Ukrainians without accounts, small business owners buried in paperwork. Coincidence or intentional?
More intentional than not. I want to work on things that matter.
In construction, I could see the result – a building where people actually live. It gives you a sense that you’ve built something meaningful, something that lasts. When I moved into software, I wanted to keep that feeling. I want to build tools that solve real problems – not just write code for the sake of it.
Transfer To Cash is about someone without bank access being able to receive money from family. Quickly and transparently. The invoice scanner is for a small business owner already working 12-hour days – now saving time on routine tasks.
I think technology matters most when it makes life tangibly easier. Saves time, removes barriers, lowers stress. Especially for people with fewer resources – less time, less money, less access to infrastructure.
Working on products that solve made-up problems or exist just for hype – that doesn’t interest me. I want what I build to actually help someone.
Your architectural decisions are becoming company standards. How do you think about tech leadership? Do you see yourself shaping approaches more broadly?
Leading through solutions is probably the most honest kind of leadership. You’re not telling people what to do – you’re showing how it can be done well. Your code, your architecture – they become examples.
I’m more interested in building systems than managing people. Designing. Constructing. Seeing things work.
And broader impact on the industry?
I think that happens naturally when you build quality. People see solutions that work and start using similar approaches in their own projects.
Maybe over time I’ll focus more on sharing experience, on mentorship. But for now, I’m just doing the best work I can.
If the principles I follow spread through code, through conversations with teammates, through projects – that’s influence. No need for big announcements, just real impact.
Vitali isn’t building a career in the conventional sense—he’s not collecting titles or accolades. He builds systems. And judging by how he talks about it, that’s his real currency: code that works, architecture you’re not ashamed to show, a product that solves an actual problem. Everything else is a side effect.
