3531: Scaling Without the Hype Inside Uploadcare's Technical Philosophy

[00:00:03] Welcome back to the Tech Talks Daily Podcast. And I want to share something close to my heart. Over the years, and 10 years to be precise, I've been lucky enough to speak with guests on here from more than 50 different countries. And the reason I'm so passionate about this is I'm very keen to give a global perspective because it's that global perspective that continues to inspire me every day and not just hear stories in Silicon Valley, for example.

[00:00:31] And I'm genuinely excited about bringing stories from all corners of the world to our listeners. And today's conversation is no different. And as you know, I always say technology works best when it brings people together. And today we're going to prove that because I'm going to take you wherever you are in the world to the mountains of Kyrgyzstan and give you another reminder that technology and the people shaping it.

[00:00:55] These are the people that deserve a truly international spotlight, not just another celebrity podcast. At least that's my dream I have on here. And I think it's the perfect time of the year to be talking about this stuff as well.

[00:01:08] Before I bring today's guest on, I just want to give a massive thank you to my friends at Donodo. Because after visiting over 25 different events in 2025, one of the phrases I keep hearing is no data, no AI. And agentic AI simply needs better data.

[00:01:27] Now, agentic AI is here, but it only works when the data behind it is complete, governed and in real time. And this is one of the areas that Donodo helps because Donodo gives you a logical data foundation that accelerates AI, boosts Lakehouse performance and turns your information into reusable data products and for every team.

[00:01:50] So CIOs, architects and business owners each get the data that they need instantly. And their global partners help you get up and running faster than ever. So if you want AI that doesn't hallucinate, but actually delivers real business outcomes, visit Donodo.com and start making your data work harder. But now let's get today's guest on.

[00:02:15] So a massive warm welcome to the show. Can you tell everyone listening a little about who you are and what you do? Hey everyone, my name is Alex. I'm a CTO of UploadCare and with 20 years of programming experience, I'm working on culture, technology, compliance and everything to ship great product to our customers.

[00:02:40] Well, it's a pleasure to have you join me today. And one of the things I try and do on this podcast every day is get thinking people differently about technology, its impact on areas we don't associate with technology. And yes, we've all heard the Silicon Valley stories and the areas where you expect to see a huge tech scene or a startup scene.

[00:03:00] But obviously you're talking to me today in Kyrgyzstan. So when I think of that, I think beautiful mountainous scenery, but not necessarily technology and tech companies. So I'd love to change that and bust a few myths. Can you tell me anything about the tech scene in the area so we can really shine a light on that today? Well, it's not so strong as in Silicon Valley. However, there is a very strong videography and arts and here in Kyrgyzstan.

[00:03:29] But I think the state takes right steps into the direction. They created the separate tax regime, which is 1% from the money you're earning. If you are a programmer and qualify for this regime and I applied for it. So with 1% taxes, it feels good and mountains.

[00:03:53] And I believe these decisions of state to promote Kyrgyzstan as a place to live as a developer, as a digital art person. Right. And I see increase in amount of tech people around me. I see, I now hear talks in the cafe about technology.

[00:04:14] So it's not a strength, of course, it's not as strong, of course, as the Silicon Valley, but I see it growing and I'm happy to see it because as we talked before, I like to observe something to grow from zero. Love it. I've got to ask because you've had a great career here. Looking back, how has building systems that grew from the first lines of code to millions of daily signups,

[00:04:44] has that shaped your view of what scale actually demands from a technical team? You've probably seen so many big changes and transitions throughout your career. But what have you seen here? Yeah. So I usually work in small headcount teams and I planning to do this in the future too. And all teams are different and all stages of growth are different.

[00:05:08] So my point of view on this is based on my experience, but indeed it's not universal. I think that from the beginning, teams should be very flexible and everyone should wear a lot of hats every day. And for some people, it's not okay to work like that. So you can wake up, you can't wake up and look at your Jiro board, took uppermost ticket and expect everything defined what you need to do.

[00:05:37] There is always a lot of hats every week. And a lot of work lands in the dumpster. And yeah, there are some people who are okay. And for them, it's like a fresh air. You are iterating, you are experimenting, and there are a lot of unknown variables.

[00:06:01] But for others, it's not okay. So you have to pick the right people and create a great vibe for them so that they feel this rush of initial implementation.

[00:06:16] And at the beginning, you can't afford a lot of planning, a lot of processes. You can't, and you have to ship not ideal code. You have to implement technical debt. And the seniority, the leadership here is to distinguish which shortcuts you can take and which you cannot take.

[00:06:41] So this stage introduces a lot of technical debt and should be addressed later. But technical debt on this stage should be taken consciously, not like randomly. And because doing everything perfect at the early stage, when clocks are ticking and in such, in early stages, clocks are always ticking.

[00:07:05] Doing everything perfectly can easily lead to death of the company before your ideal code will face those lots of your dreams. But after it, it's very important to fill the point in time when you need actually to implement processes to address technical debt.

[00:07:28] And by how well do you feel that moment, it describes how good you as an engineering leader. And it also has a huge impact on the future of your company. So long story short, I think from day one, you should ship a lot of bad code, but fast, but to be able to address the debt later.

[00:07:54] And in my experience, it was like this in all companies that I worked in. And before you join me on the podcast today, I was doing a little research on you and I was reading that you said simplicity matters most in high load environment. So where do you think teams overcomplicate things and what does simplicity look like in practice when everything is moving so fast?

[00:08:18] And one of the reasons I wanted to ask you this question is I think that is something that every business in every industry is experiencing right now. So I'd love to hear your insights here. Yeah, the overcomplication comes from several traits of developers. I mean, engineering complexity that we introduced during the implementation of our project. So we like to mock cool guys.

[00:08:44] We like to implement something based on knowledge we see in the internet blog post, hacker news, etc. But we don't think about how do we like can we afford it or not? We don't think about it. We just rush to implement some new framework or tool or tool set from a big company.

[00:09:09] And why I think that simplicity is needed to scale your company and your infrastructure is that in the beginning, you don't have a big team and you have to keep your system simple in order to keep it maintainable.

[00:09:31] And as you know, like premature optimization is an evil and we as engineers like to optimize a lot. And when like every week can be a pivot to your idea, to your product, this optimization is actually lost resources.

[00:09:51] And the simpler you design your system from the beginning, the easier your life will be in the future. And there is, I believe, a good analogy to real world engineering. The simpler, the less moving parts you have in your design, the lower chances that something can break because less things can be broken.

[00:10:19] This is my like point of view on simplicity and scalability. Keep it simple and it can break in a lower number of variations. And when researching you, I was also reading that you're a big fan of Ruby on Rails, which does have plenty of fans, but equally lots of critics. So what is it that keeps you committed to it, both for rapid launches and serious scale? And where do you think people misunderstand what it can do?

[00:10:48] Because I think there is a lot of misunderstanding here. Yeah. So obviously Ruby on Rails is not a tool that you can use for everything. You can't write video encoding on Ruby. You can't implement heavy mathematics on Ruby. And I believe that's okay. But I think the Ruby on Rails is the fastest framework currently existing on the planet.

[00:11:13] And when making such a statement, people will ask me, Ruby on Rails is fast? Are you mad? But actually not. The root of misunderstanding of Ruby on Rails is how different people define speed. I define speed as a speed of initial implementation. I define speed as a speed of making changes to your existing project. And I define speed as simplicity of maintenance of your existing project.

[00:11:43] And from my point of view, there is no faster way to implement some product, iterate over it, pivot, and maintain it than Ruby on Rails with this friendly ecosystem. And the things that it provides out of the box. And I think this is the root of the whole misunderstanding.

[00:12:06] But people will say, in Ruby on Rails, you will spend a lot of more CPU cycles and more memory than you will in framework XYZ. But I definitely agree. But as I said, all companies are different. And we need to understand what's more expensive for your company. Extra people or extra servers.

[00:12:33] For the majority of companies I worked with or I observed, I think that for most of them, people are more expensive than servers. So they can easily spend 50% more on servers, for example. And they don't even feel it. And by servers, I mean compute processing servers.

[00:12:56] And if you as a developer know how to write horizontally scalable code, and you as a developer should know it anyway, whatever language or framework you are using. I think given the margins that we have in internet industry, I think that servers are cheaper than people. And that's why I think Ruby is still a good option.

[00:13:24] And for me, it's still best framework. I love that. People are more expensive than servers. And I also read that you place people before technology and processes as a result. So just to bring that to life and what we're talking about here, can you walk me through a moment where that very philosophy changed the direction of a project or solved a problem that tools alone couldn't fix? Because I think we're seeing more and more that a lot of people are using technology to replace people and getting it all wrong.

[00:13:54] So I'd love to showcase some ROI of putting people first and the kind of difference that could make too. Yeah, like placing people first, it's a long game. It's a strategic game. I believe that ROI in this case is inevitable, but it's not fast. So there is no such definitive moments when such bets change the situation.

[00:14:22] But I can explain very practically why I place people over technology and over processes. Because we work for companies that want us to generate revenue. And if I care about people, for example, less people churn from our company. So company spends less on recruitment. Company spends less on onboarding.

[00:14:49] And business continuity is stronger in such a company. So I care for people, but what I get in return is more optimal resource spending for company. I think that when you care about people, they naturally want to give it back. And how they can give it back in a company, they can work better and deliver better results. For me, it works every time.

[00:15:19] You are kind to people and you get something in return. And when I build culture where people are not offending each other at work, they are less likely to quit too. And when I build culture, people feel more safe. And they are easy, easily express ideas that may feel damp in other companies.

[00:15:45] But some of these ideas are damp only from engineering perspective, but brilliant from a business perspective. Like, for example, if you want a moment from me, like several months ago, one person expressed a pretty silly idea about how to implement the feature that we wanted to implement a lot. And it was not scalable at all. However, the person felt safe.

[00:16:14] We discussed a bit, had some love and decided to give it a try. We implemented this silly from the first site idea and shipped it. And the user experience was not affected, but the shortcuts that we took. It was only scalability. Later, we discovered that although the user experience was great, no one liked this idea from, I mean, from customers.

[00:16:41] So we decided to let it go. But in the end, what we did, we spent a lot less resources by implementing such an idea in a non-scalable way. And we used these resources for other initiatives. And all of this was possible because our environment was safe to express even crazy ideas.

[00:17:07] But to sum it up, if you are creating a company that should work only for one year, you can not care about people. But if your game is long, if you want your employees to stick to a company, to contribute, to evolve and evolve your company, I believe you have to care about people. And yeah, for me, it's my priority.

[00:17:36] It's so refreshing to hear you talk this way. And I completely agree with you. Long game, that's what it is all about. And the more you put in, the more you get out. So it's great to share a story like this. And another phrase I wanted to dig in a little bit with you today, as I hear a lot, is cargo-caught thinking. Because it's still common in engineering culture. But what patterns do you see teams copying without context? And how do you coach your teams to avoid falling into that trap?

[00:18:06] Because it's very easily done. But how do you avoid this? I think, from what I see, small teams, small engineering teams, like to adapt tools invented by big engineering teams without having similar problems and resources. For example, the majority of companies can use their relational database as a message queue. For some of them, their relational database won't fit the purse, of course.

[00:18:32] But they can use Redis in this case and scale to very high numbers, extremely high. And Redis is very simple and easy to maintain. But we are engineers and we like to implement what we read in the internet. So we, for example, set up Kafka. You can say that relational databases and Redis are not event stores. Of course, they are not.

[00:18:56] But walking around this fact is simpler than having another tool in your infrastructure when you're a small team, not a thousand developers from the team who created Kafka. Same goes for Kubernetes, for example.

[00:19:16] And I think such this cargo cult creates a lot of overhead on small teams and it neglects the strengths of small teams because they can afford to be agile. They can afford to make non-ideal solutions to save time and take some shortcuts to revenue and manage the technical debt later.

[00:19:38] Or, for example, people, engineers always dream about high load, about how the system will scale. But in order to get a lot of money in revenue, you not always have to scale a lot. But we are engineers, so we challenge ourselves every day. This comes the same with not only for engineering.

[00:20:03] Small teams, cargo cult, a lot of solutions from big companies, like processes of big companies, tools of big companies. And it totally neglects their strengths and makes them both non-agile as big companies. And they also don't have resources as big companies.

[00:20:26] So for me, such cargo cult, and I observed it in a while several times, it just introduces a lot of overhead and leads to the death of some companies. And I'm not always successful in guiding teams on how to avoid cargo cult. Sometimes engineers need toys to play with, and it's okay, I think. What I do is just challenge them by proposing simpler alternatives to solutions that we are discussing

[00:20:55] and see how exactly they justify their architecture choices. So I plant seeds of doubt, and sometimes they grow. Oh, absolutely love it. So many great insights coming from you today. And another thing that I'd love to explore is when we're looking at upload care here, you sit in a space where reliability and performance continue to shape customer trust.

[00:21:21] So what decisions behind the scenes that people listening won't know about have had the biggest impact on how you're keeping the platform dependable at scale? Because there's so much of what you do just gets taken for granted. But there's a lot of hard work behind the scenes that make that possible, isn't there? Yes, but again, upload care is a company. It's 12 years old already, so it's not a startup. And we have a lot of customers, and we have to implement processes,

[00:21:50] be less agile than we have been in the beginning. But still, since we are a small company, we have to capitalize on the possibilities that we have. We don't have top-down culture, we have bottom-up culture, and we want to embrace it, etc., etc. But speaking of your question, these decisions that we make that impact us being dependable,

[00:22:18] they are taking place every day. But it's not about using technology X instead of technology Y. It's actually met a decision on how we approach architecture and engineering. At this stage, it makes sense to have processes and make extra effort in keeping code great, because now we have a lot of customers and they are relying on us. Today, when we implement a new system or altering an old one,

[00:22:46] we collaboratively discuss bottlenecks, single points of failure, scaling limitation, and trade-offs. Trade-offs. Because creating a distributed system that is highly low is just a game of picking trade-offs that you want to take, and nothing else. And outside of code, if we just take a break from that for a moment, you've had some memorable experiences yourself,

[00:23:16] including a near-miss with Kimi Raconan at Nuremberg. How have those moments outside of your work influenced how you lead inside a fast-moving tech environment? I feel there's a great story there too, right? Yeah, but near-miss with Kimi Raconan didn't change me or affect me as a personality. My favorite story on how memorable experience can change my life

[00:23:43] is the moment when I lost control over my legs about six or seven years ago, I believe. It was because of the stress, and before it, I always thought that I will always be a developer, will never go management, and be just a better professional every year. However, after this crisis, I decided that I should try some management

[00:24:09] to prevent such situations for other people, to convert my experience into the goods for others. That's why I focus on people so much. Don't want them to lose control over their legs. And before I let you go, we've got an Amazon wish list. Ask my guests to leave books that they can add or recommend to listeners so they can check those out. Is there a book that you'd like to add to that list? What would it be and why?

[00:24:40] As an engineer, I have a lot of engineering in my day routine. So when I read books, I prefer non-fiction. And when I read non-fiction, I prefer Fyodor Dostoevsky. And my favorite book is The Brother Karamazov. The idea of Fyodor Dostoevsky, I believe, is pretty simple and questionable. The soul grows up by suffering.

[00:25:09] It's definitely questionable, but sometimes it works like this. And I think it's time for me to read it for the third time. Brilliant. Well, I'll get that added straight to the wish list. And for anybody listening wanting to find out more about Upload Care, connect with you or your team, or just find out more information about the kind of work that you're doing, where would you like to point them? I think it's our Twitter account, Upload Care.

[00:25:36] It's our website and blog, UploadCare.com. There are a lot of information about us. Brilliant. Well, I'll get everything added there. I'll include all the links, including your socials. I urge people to check you out. And more than anything, just thank you for shining a light, not just on your work, but where you're working, the region and everything in between. Really enjoyed talking with you today and bringing this topic to life. But thank you for sharing your story. Thanks so much.

[00:26:06] I enjoyed it a lot. Wow. Incredible story. And to everyone tuning in from all around the world, thank you for being such a part of this growing global community and how we're able to share how technology does work best when it brings people together. And I always love hearing where you are listening from. So please, consider this your call to action. Get in touch. Drop me a message. Let me know your city, your country, so we can keep putting pins on this ever-expanding map

[00:26:35] and share your stories, your insights and your expertise. So whether you are joining from a bustling tech hub or a quiet corner of the globe, what I'm trying to say is your voice matters. That's why I built this platform. And I'd love to hear your story too. Send me a voice message over at techtalksnetwork.com. Email me techblogwriter at outwork.com or send me a DM on LinkedIn X or Instagram. But that is it for today.

[00:27:05] Really inspiring story there. I'll be back again tomorrow with another guest from another part of the world and a completely different industry. Speak with you all then. Bye for now.