Measuring Carbon Footprints: Faraday's AI-Powered Sustainability Solution with Aycan Gulez CTO of Faraday

Hello, Ayhan. How are you doing?

Good, good. How are you?

I'm okay as well. Welcome to the show, Ayhan. So, so let us know who Ayhan is. How did you end up in the tech industry?

My name is Ayhan Gülez, and I have worked at startups including one of my own throughout my career. And I've worked at both B2C and B2B startups. And I'm currently the CTO of Ferdy. So I guess I'm a startup person. You could say that.

A startup CTO.

Yes, of course. I haven't always been a CTO. I started as a developer. And actually, my first job was as a founder of my own startup. So I did these things the other way around. You normally work at a company and start your own company, but I did these things, I guess, the wrong way.

Upside down. Did it work out with your startup? Did you end it up? Selling it, having an exit, or, you know, what happened?

Well, actually, it went well for a few years. It was about— this was really a long time ago. It was a forum software startup, and it did okay for a few years. Then sales started to slow down, and I had to close it down, really.

Okay, that's a very common journey though, Adrian. It's not easy. As people would think. You actually run your own business, and especially technology business, it takes some, some, some grit. So today we got you on the show because you, you know, you work for a company called Faraday. Am I saying this okay?

It's just Faraday. Faraday, it's okay, it's okay.

Yep. And what does Faraday do?

We have a product, uh, called— which is called Net Zero Intelligence, and we help companies calculate their carbon emissions And we also provide a platform that they can use to manage their energy consumption. That's what we do.

Okay. Why would the company care about their carbon emission?

Because there is this huge problem we are facing right now, the climate change. And Basically, governments are starting to pass regulations that require companies to report their emissions so that those emissions can be reduced. You can't measure— you can't reduce something you don't measure. And also, there are initiatives about a so-called carbon tax, which will be— some companies will be expected to pay a carbon tax for damaging the environment and making the entire world a really bad place for our children to live in. So we care about— we are trying to do our part in stopping the climate change, basically.

Okay, so effectively you said very important bit there. If you cannot decrease it if you don't measure it, right? You cannot do better if you cannot set your baseline of how much, you know, energy and consuming and all of the rules around carbon emissions. So can you give us a little bit of setup of, of what your platform is offering? So let's say I'm a Company A, you know, I'm a huge company, you know, maybe I'm manufacturing cars, you know, maybe some, some other hardware. How do I measure, you know, my energy and all other things which are important for, for the carbon emission calculation?

There are standards that we follow, and you basically have to collect data, for example, your energy consumption, your gas consumption, or your fleet, if you have a fleet of cars, those also cause emissions. And if you're a manufacturing plant, whatever you produce is probably emitting quite a bit of carbon emissions also. So you have to save, store all this data and recalculate all the emissions that's, uh, based on that data. That's, that's what we do.

Okay, so do you bring hardware in the setup as well? So let's say, you know, I'm, I'm doing, um, a car fleet. That was a good example. So let's say I have a car fleet. How do I actually measure what I'm emitting? Do you give me some type of hardware which I need to put in my car?

Actually, our business has two parts. One part is about measuring carbon emissions and other part is managing energy. So in calculating your emissions, you don't really need hardware. I mean, it helps to have some, but it doesn't have to be that precise, the calculations. But in the energy management part, we are more interested in more precise, highly granular calculations. So we provide hardware, but our platform is really hardware agnostic. It can provide, it can run with compatible hardware that is already in use, such as sensors or IoT gateways that collect energy data, high-precise energy data from the premises.

Okay, so as long as I have hardware which measures my energy, I can integrate with your system and get the calculations done, right?

For carbon accounting part, that's optional. But for energy management, if you are trying to reduce your energy use, you have to measure it and you have to measure it precisely as much as possible, of course. And for that, it helps to have some dedicated hardware.

Okay.

But for the carbon accounting part, no, it's optional.

Okay. So we effectively talking about IoT devices, right?

Yes, yes, IoT devices. And there we don't really manufacture our own device. We only have a gateway that collects data and it interfaces with other devices other manufacturers make and reads data from those devices and transfers the data to our platform for further analysis.

Okay, this is interesting. So you have different manufacturers producing devices, IoT devices, and then you have your platform consuming the data. Is there any standard around APIs, how you talk with the devices, or is it more like a pair device integrations which you need to do?

That's a good question, and the answer is interesting, really. When I first joined FireDye, I was surprised to learn that there was this protocol that is used to exchange data between industrial energy devices. And it dated back to, it dates back to late '70s and it's still in use, active use after 40 years. And we use that to exchange data so that the protocols are really old, I would say.

Why are they so old? I mean, were they so perfect that no one needed to you know, iterate and make them better, or is it because there was no real market need so they just got forgotten?

The thing is, in the energy management business, the, um, um, the business is quite hardware-centric. The software component is often an afterthought and is provided by the hardware manufacturers themselves, and they are minimal software really. So, um, there is some progress though. I mean, there are platforms like ours which are hardware agnostic and interface with lots of different hardware, but, uh, the mindset is, is, is, I can say, there's this famous saying, if it ain't broke, don't fix it.

That's a good thing, isn't it?

Yeah, it's in the hardware world, they don't like to change protocols very much. That's their mindset, I guess. It's a little foreign to us software developers, but that's how it works.

Can you even change protocols for hardware? I'm just thinking about like backwards compatibility. That probably would cause a lot of issues if you start changing protocols around that. It's an afterthought of my own. Okay, so we got IoT devices, we have a certain protocol which allows us to integrate with them. So now we are at this platform level. In the spirit of, you know, current market of AI, let me ask this question. Do you guys integrate AI and how does that help you, you know, in your offerings, your technology, in making assessments around carbon emissions and everything else?

We effectively use AI in the energy management part more. Because there is more highly granular data. And for AI to work effectively, you need as much data as possible. So, um, we, we collect terabytes and terabytes of energy data from thousands of different locations, and we use different algorithms, uh, such as decision trees, clustering algorithms, neural networks, to analyze this huge data base, and we try to establish baselines to see what regular use patterns would be like. And once we have the baselines, we try to predict future, uh, energy consumption. And by doing that, we, we can, uh, most of the time identify abnormal use cases like abnormal consumption in certain locations, for example, or in certain times of the day.

Okay, that's, that's very interesting. And very important note is that, you know, data is— AI is effectively data hungry. The more data you have, the more you can trust the module. Otherwise, you know, it's, it's probably should not be that, that much of a trust. Um, let me ask this. Can you give us an example where your AI-driven predictable analytics have helped optimize energy consumption?

Yes, but we had quite a bit of success in the retail chain business. Retail chains have usually tens or hundreds of stores they manage. And surprisingly, they have, or maybe not surprisingly, they have common problems regardless of brand. And the first problem we identified was their nighttime use, energy consumption was highly, or too much, I would say. And that's interesting. Normally, stores are closed. I mean, what are they using anyway? And we found out that The employees didn't really pay attention to turning off lights and HVAC systems and stuff like that. That was low-hanging fruit, really. After that, we focused on regular working hours during the times that stores are open. And we managed to By taking things like the temperature outside and internal temperature, the seasonal changes, we managed to help them reduce their energy use by as much as 15%. So that not only helped them to save some money, but also it helped them reduce their emissions also.

Okay, so this temperature taking thing, is that like iteration around the process? Or if you come to a business and you go like, we have experience, we know that we need to measure this and this and this, or is it more like tell us what you're measuring and it's a, you know, backward, back and forth type of process where you're getting a feedback from a company and, you know, you're pushing information, so maybe you install more devices, more measurements to draw conclusions, or is it just like a, as a bundle? That temperature was very interesting. I felt like outside of the box, you probably wouldn't ask people to measure outside and inside temperature.

Well, temperature is very important because modern buildings have HVAC systems, so it's very easy to set a temperature which is too high or too low, which wastes a lot of energy. So temperature, both inside and external temperatures, are very important for our calculations.

Okay, so let's go a little bit to, you know, to that AI layer. So I would imagine that's like a machine learning, like a deep data type of situation. Can you give us a little bit more insight of, you know, how that technology stack looks like? You know, what are you guys using? How are you iterating? How are you improving the algorithms? And Just a little bit more like a technical flavor around that.

We mostly use decision or the modern versions of decision trees to categorize or classify similar buildings in terms of, for example, in shopping malls are quite different than regular office buildings. Because their internal structure is quite different. They have centralized heating and air conditioning, and stores are different. The traffic is different, the customer traffic. Offices are quite different. So we try to understand how different buildings behave, so to speak. In terms of energy use, like, and in terms of customer traffic. So we classify buildings and we try to establish baselines depending on building types and seasonal changes, like day of the month or holidays or just, I don't know, things like that. Because there are many, many, many factors, and we— some of the times we get these things wrong too. So we try to iterate to, uh, see, to fix the things we got wrong.

Okay, so you're getting all the data, uh, that's a decision tree which goes to your ML. What type of software are you actually using to like capture data? You know, like, is it cloud provider? Are you pointing in your own data center? It's like, what you know, how does your data lake look like?

We use the cloud and we have quite a few servers on the cloud and we have our own database. We don't use managed cloud services. We find, I personally think that since our core business is data storage, we need to know how to operate a large data store. And we try to use as much open source technologies as possible. And our main database is PostgreSQL, for example. And we save— I think we are among the heaviest, probably, PostgreSQL users in terms of the amount of data stored, tens of terabytes, uh, at least, uh, and that's, that's quite big for typical PostgreSQL database.

Okay, so everything sits in a, in a Postgres. Um, do you train your data? Like, when you think about AI predictable, you know, modules you have to forecast energy consumption, like, do you train the data? Do you train the modules?

We obviously retrieve the data according to a certain set of criteria, and we use, yes, training, um, depending on, uh, customers' requirements and the nature of the data. We use different algorithms to, uh, train those, uh, algorithms, and based on the data we store.

Okay, is it per-client-driven training, or are you creating more like a unified module which applies to many clients, or do you find yourself into the situation where, you know, you have to have some type of almost like custom, customability offering per client when it comes to AI modules?

Oh, it's actually sector-based. For example, we have some of our customers are retail chains. We have a number of retail chain customers. We have banking customers. We have, um, hotel hotels. And manufacturing plants. So different customers use different types of buildings, obviously, and different— they have different energy patterns, use patterns. So, uh, we choose the algorithms based on the unique properties of a particular customer or sector.

Okay, so that's That's a very interesting one. Um, so because you're working with so many different sectors and industries, is there any, um, outdated practices which you're seeing in energy management which you would like to improve of, or yeah, just improve?

As I said, uh, earlier, the energy management business is hardly highly hardware-centric. And this is— this, um, no matter what sector you are working with, they use the same hardware manufactured by the same manufacturers who, who are, um, really, I would say, kind of old school in their thinking. So, um, there aren't very many platforms that like ours too, that can work with multiple hardware providers. This hardware-centric mindset I think needs to change. It's changing, but it's slower than I would like it to be, really.

Let's say you get what you want tomorrow. What would be that one thing when it comes to that particular situation around the old school thinking and the hardware is like one thing. If you would change, you know, what that would be and what you would expect from that change?

Uh, obviously, as a, uh, as someone coming from a software development background, I would prefer to have completely programmable, uh, fully customizable, that upgradable, uh, hardware. But Unfortunately, cost is a real problem. When you are measuring fine, highly granular data, you might need quite a high number of pieces of hardware, and that the numbers add up quite fast. And when you try to make these things more smart, smarter, then obviously it costs more. It, it's so— I'm— although I don't like the current landscape, uh, very much, I can understand why it is that way, uh, from a cost perspective.

Okay, so if you would change it, you would effectively just have a smarter hardware which allows to integrate with the software level layer much, much easier and have an ability to be a long-lasting relationship. So, so it's just less work for everybody.

Exactly. It would be great if we had systems like plug-and-play systems like that can just connect to Wi-Fi and start transmitting data. It's not that easy, but the hardware is mostly dumb, really, unfortunately. So we need gateways to connect to this mostly dump stuff and extract data from them.

Okay, that's a— I mean, that's a good wish, right? That's a, that's a good vision to have, right? So, um, so you guys are quite big, right? You got different industries, you are, you know, you're all across the globe. Can we touch a little bit of challenges and frustrations along managing and scaling infrastructure? Of such product like Faraday?

I mean, we are not that big, by the way. I mean, we are, I think, we are a small scale-up right now.

Okay.

We are past the startup phase, but we have large clients, yes. As for the scaling part, basically, I complained about the hardware-centric nature of the, uh, energy business, but energy management business. But, uh, interestingly, uh, the relational databases don't scale well horizontally, uh, after all this time. I think it's been over 40 years since the introduction of the first relational database. I think it was Oracle, and it's still hard to scale relational databases horizontally. I mean, you can scale them vertically and it works, uh, to some extent because we have really, uh, affordable, uh, multi-core, uh, processors and RAM is quite cheap these days. But I would love to have an easier way to scale this database horizontally, really. It's still hard. There are solutions for this problem, but they have their own challenges still.

What's the, you know, go-to solution? So the very first time you guys hit the limit of horizontal scalability with, you know, with relationship databases, what was your, what was your solution?

Actually, we haven't hit that limit, fortunately, because I'm not looking forward to a horizontally scaled solution because it has, it comes with a lot of complications. Really?

Okay, so you guys just go ahead and scale vertically, right? Just adding more manpower— not manpower, but, you know, computing power.

More computing power, yes. More, more cores. And fortunately, as a side note, ARM processors are becoming quite common on cloud providers, and they are not only cheap when you compare them with Intel processors and they are fast too. So it makes vertical scaling much easier to have this option.

Did you look potentially into NoSchema databases or like a document databases or any other type of databases which are not relationship? Would that work?

We did, we did, especially from a performance perspective. Column-based databases such as Apache Parquet and ClickHouse. We tried those, specifically ClickHouse, and its performance is great. I mean, it's many times faster than PostgreSQL. Unfortunately, and that's a big issue for us, was these kinds of databases don't like updating past data very much. For all intents and purposes, they consider the data stored in them as immutable. So if you try to change past data, for example, you got like wrong readings from some devices, then performance suffers dramatically. So that's not a price we wanted to pay, and we are still with the tried and true relational databases.

What about doing some type of like a hybrid? You know, you have, you have these rare occasions of updating data, especially in the past. You know, you could, you keep them in the relationship database, but you know, your front end is utilizing a column database, you know, just for the sake of speed writing, and you just sort of sync those two different modules in the background.

Um, we thought of that, but, um We didn't really, um, um, it's, it's a significant, uh, it requires a significant investment, and I don't think— it's a good idea, by the way, um, but I don't think we are willing to make that transition right now.

The trade-off is not worth it, isn't it? The energy required to effectively re-platform all your database layer versus, you know, the value you get is just just, just not on par.

It looks like a huge undertaking. Maybe I'm mistaken, I don't know, but, uh, you don't lightly make changes to your data layer normally.

Yeah, because it affects everything else, isn't it? It's how you get the data, how you get data out. Database layer in general is, you know, it's the deepest element of all the layers around your application. So you make that change, the ripple effect will, will will force you to update everything else. So what about microservices, Aijun? It's like, how, how does your service level look like? Is it like monolithic application? Do you have like serverless? Is it, is it macro, you know, microservices?

Okay, um, so it was Uber that the first day they first complained that how hard it was to manage all these microservices. So I'm not against microservices. I mean, they're fine, but as a CTO, I prefer to have as few dependencies as possible because statistically speaking, um, the more dependencies you have, the more chances of something going wrong. So I think it makes sense to build a monolith. First. And if you encounter any performance problems or any flexibility issues, by all means try carving out the problematic parts and turn them into microservices if you think that would work for you.

Okay, it's a gradual step-by-step process. Don't buy into complexity from day one. Build the monolith, reach the point where you actually have a problem with scalability and then start attacking those problematic areas of monoliths, of just effectively, you know, like you said, carving out that part, put it in the service.

Absolutely. I mean, there are 3 stages to programming. I mean, the first one is make it run, and the second part is make it work, and the third part is make it fast. So you need to be good at the first two parts first before trying to optimize things.

Yeah, I love that. Technology people, hands-on developers, or anyone coming from tech background, when they think about launching products, they always think, you know, they need to put in the newest tech, the best patterns, the, you know, the newest flashy things to get the product out. At the end of the day, that doesn't, that doesn't matter really. That's not what, you know, sells the product itself. So the microservices complexity, it's, you know, you're buying into very expensive tech stack from day one with a huge question mark if you even need it, right? So, um, so you have a— so are you a SaaS platform or are you a PaaS platform? So are you platform as a service or are you software as a service?

Somewhere in between, I think. I mean, there is the hardware part, so it would be— it would make sense to say we are part platform as a service and software as a service, but we do support on-premise installations for large enterprise clients. Banks prefer to have on-premise installations, for example.

Definitely, it's going to be likely because of regulations, isn't it? Before we jump in the regulations, Ayhan, one last one. Can you give us an example of scalability issues which, you know, you had or the team had and, you know, how you guys overcome it?

As you know, we collect lots and lots of data, terabytes of it, and the growing database size had made it hard to manage and back up all this data. Fortunately, we came across a file system called ZFS, originally developed by Sun Microsystems, which is owned by Oracle, I think. Anyway, this, this file system is now free and open source, and In my opinion, it is criminally underused. For one thing, ZFS makes it super easy to take file system snapshots. So making incremental database backups is very, very easy with ZFS. And another thing is the snapshots are not read-only. I mean, you can make some of them writable and it's called clones. And we can, we use this feature a lot. We can spin up a development database server literally in seconds. ZFS doesn't care if it's multi-terabyte big, you get your server ready in seconds. That's amazing. And finally, ZFS has built-in compression, so it can transparently compress all the data you have without any apparent performance loss. And I think we reduced our data storage needs by two-thirds, and that's quite substantial. And if this all sounded like a commercial, I'm sorry, but I can't recommend ZFS enough. It's, it's great, uh, open source and free. Give it a try, you will be amazed.

I mean, 2 terabytes, that's a lot of cost. I mean, if, if anybody listening ever dealt with an actual cost of data storage in the cloud— on-premise, of course, is, you know, it's cheaper— but if you're storing in the cloud anywhere, Azure, AWS, Google Cloud, it's actually quite expensive the moment you go into areas of terabytes. Like that's a huge cost. If you can slash this in two-thirds, that's a huge cost saving. So I never heard of ZFS, by the way, so I took a note on, you know, to check this. If it's open source, you know, that's even better, right? You can just run it. What's like, what's the API layer on it? You know, is it easy to install? You know, works with Linux, no problem? Can you run it on Mac?

And, uh, it works on Linux, and it's just a few commands really, it's super easy to use. In fact, I wrote an article about our Postgres queries on ZFS and I wrote every single thing you should do, like installation instructions and stuff like that. If you just run a few commands and you get a super powerful file system. And it's amazing that, that few people know its existence. It's really a superpower.

Okay, we will add a link to your article in show notes if anyone would like to give it a go. Sounds amazing, by the way. T-Turtle, some I'm blown. I just, I'm thinking about the cost right now, not about, you know, developer experience, but just, just literally the cost of data storage. And, and $3, that just sounds amazing, uh, right? So, um, moving forward, let's dig into sustainability. So effectively, what you guys doing at the end of the day, it's, uh, you know, it's a software and hardware offering to make the businesses more aware about their energy consumption and thus, you know, cut that and just sort of be part of the, you know, very valuable initiative across the globe. How do you do this as a company itself? You know, how do you set that example? How do you think about, you know, energy you spend with your data centers and your cloud and, you know, how you yourself are aware of your own energy consumptions?

We are lucky that we have our own software to calculate all these emissions, but Basically, you need to be aware of your carbon emissions first and foremost, and you need to measure it. Otherwise, you don't have a baseline and you can't do any reductions. And besides, there are regulations coming that will make carbon emission reporting mandatory in the near future. In any case, what we do is we try to switch as a— from point of our tech stack, we try to use cloud providers with low carbon emissions. I think virtually all cloud providers report their carbon emissions. And also working remotely is actually quite environmentally friendly. You don't have to commute to work and transportation is a major source of carbon emissions. So actually, I think most of our company works remotely. And if there are some companies who don't like working remotely, I mean, it's great for environmental change. I mean, in terms of less damage to environment. So that's, that's one point of view.

Okay, so effectively it's an integrational chain. So any services you take to make your business happen, such as cloud provider, you make sure that your partner is following. And if you take any other partner on something else, you know, you make sure that And it's just effectively, it's a chain reaction. Anything around your business is as well thinking about their own energy consumption. So I do have a follow-up on this one because I feel like anytime you have business, governments, or any type of regulations coming in in the sector and going like, you know, here's a framework of rules, like the outcome you get out of this is, is that it hinders innovation because there's no freedom of expression, right? Because you're getting almost like a box. What's your take on this, Ayhan? Like, do you feel like these rules will stifle innovation in the sector?

I can imagine that there are some sectors that are stifled by regulations, but in the carbon accounting business, or let's say this is not a business, carbon accounting affects Or carbon emissions affect everybody, uh, living on this planet. So, uh, you need regulations, uh, you need standards that everyone must follow. Otherwise, it will take too long to stop this climate change, and we will be all, I don't know, living in really bad conditions in the future. So I can imagine some sectors don't like it, but in the carbon emissions parts, we do need regulations and we do need them fast.

Okay, so what advice would you give for CTOs of other businesses and other companies, you know, who who want to be more environmentally friendly, what can they do?

First, of course, they need to measure their emissions. Lots of companies, uh, it's still voluntary to measure emissions unless you are in a really high emission sector, like if you're a cement, uh, manufacturer, or manufacturing plants have to do It's— but most companies don't have to measure and report their emissions. But world governments have started to pass regulations to make it mandatory to measure and report your emissions. And so you will be not only responsible for your own emissions, but for your suppliers as well. So, um, you need to be aware of, um, the, uh, environmental impact of all the suppliers you are using. Maybe not, not right now, but in the near future. So you can't just randomly choose a supplier and hope for the best. I mean, the environmental impact has to be part of it.

Okay, so the easiest what CTOs could do right now If they cannot, you know, change their business, or, you know, they look at the cost and they go like, okay, we cannot right now pay for a, for a partner to calculate our energy emission, or whatever the choice they make, they can at least— they look at the partner, partners they have, you know, partners they integrate with, and ask a question: are they calculate their emission right? That's, that's quite easy exercise to do.

Yes, I mean, soon this, I hope, will be normal. I mean, asking your partners what their energy and what their emissions are. Right now, I mean, no one cares. But there is an increasing awareness and the upcoming regulations that make it mandatory to check all this data. From your suppliers. And of course, you have to pay attention to your own emissions as well.

Can industry be self-regulated in this space? Like, can we, instead of having like government regulations and you must do this, you know, we have some type of like self-regulation? You know, what's like, do you think that works or it really doesn't?

I will be blunt here. I hate pointless government regulations as much as everyone, but I think self-regulation is an oxymoron. Um, in a free market, all economic actors are supposed to act in their own self-interest. That's the argument, right? So if all left standing between such an actor and a profitable business opportunity, and it is self-regulation, what do you think would happen?

The business will choose any path which is most profitable.

Most probably, yes. So, I don't believe, I don't really believe in self-regulation. I believe that We need sensible, and I stress sensible, government regulations, especially in carbon accounting. We can't just wait everyone to voluntarily reduce their carbon emissions. I mean, it's not profitable. We can already feel the effects of climate change and it will only get worse. So fortunately, I mean, regulations are coming. I mean, I'm talking about all these regulations like it's such a good thing. Yes, it's a very good thing that we are going to have more regulations so that companies will have to reduce their emissions. That's— we need to act fast. I mean, we don't have much time left, really.

Okay. So if we get government regulations coming in, then there's going to be some type of compliance framework. That means that to offer something or to do something, you know, you'll need to hit the marks on the compliance. Did you ever in your career experience where being compliant actually impacts your technology roadmap quite significantly and you either move much, much slower or you need to just forsake some of the features you want to build?

For software developers, it's not, I think, typical to be negatively affected by regulations unless you are a tech giant like Facebook and Google. I mean, they have— and then when you reach such a level, I mean, you have your own regulations department, probably consists of like hundreds of people probably, and lots of lots of attorneys. So, um, for small companies, I don't think it affects them negatively.

Okay. All right. So I'm very interested to understand how you guys innovate around your, your product and how the customer feedback plays into this, because it's such a, such a unique, you know, offering. You are in between of platform and, you know, software as a service and platform as a service. You have a hardware offering And as well, you know, all this integrations, how do you know what you need to build next? Is it like, do you talk with customers? Is it more of you follow government, you know, set roadmaps and you're trying to get aligned with regulations which are coming? Is like, what's your mindset around innovating on your own product and on your, on your own offering?

Um, the regulations part is easy because we have to comply with the regulations, so We add support for any compliance requirements to our software. As for the actual innovation part, we as a B2B provider, we talk to customers a lot because we have direct contacts. And for example, our carbon accounting application began its life as a close collaboration with a major bank, and they have something like, I think, over 20,000 employees. And collecting data from hundreds of branches was a major problem for them. So we took great pains to make data entry easy, and we implemented, um, fine-grained user and location-based controls so that users could only enter the data they are responsible for. Otherwise, it would be easy to be overwhelmed with the complexity of the thousands of different data sources. So we work very closely with our clients and we listen to them a lot and we try to understand the pain points and try to solve them by showing them mockups and our prototypes. And it's a very iterative process and they like it generally.

Okay, where does the data-driven decisions come into that? Is it, is it more like, you know, you choose the biggest clients and then you talk with them and, you know, that's how the roadmap is involved? Or do you collect a lot of data? I mean, you already said you collect a lot of data, but it's more about like how the data-driven decisions shape the roadmap.

Of course, we talk to them, the customers, and we also collect anonymous user statistics and we try to see where they struggle. With our platform. And we also try to find common patterns. I mean, otherwise we would end up with very custom software that, that only works for certain clients. So we try to make it work for as many clients as possible.

What about Security Agent? I mean, everything feels it's just out there in the wild, you know. I have these devices in my office that's just sending data, you know, all around the place, you guys collecting the data. It's all a lot of data processing as well. How do you guys think about security and how you make sure that everything you guys collect is actually, you know, quite secured?

It's, it's really, um, tough to be entirely secure, of course. I mean, But we try to follow best practices as best as, as much as we can. We try to encrypt pretty much everything, so nothing is in the open. We try to make, try to simplify our tech stack as much as possible, because if it's it's simple, there are, as I said earlier, less things that, that could go wrong. So we basically are aware of our limitations as human beings. So it's really hard to keep so many different things in mind. So, but so, so we try to keep it simple, in short.

Okay, let's dig into a little bit in the tech stack. So we talked about the database layer. So we know you guys using Postgres, you have some, some tests around potentially different than relationship databases approach. You have a little bit of cloud, but at the same time you have your own data centers. How does your application layer looks like? You know, what, what language you guys use is, you know, it's like, give us a little bit of flavor of that layer.

Okay, um, we use, uh, mostly Node.js. And Java on the backend side. And on the frontend, we use Vue.js. So it's, I think, more than half of the stack is JavaScript-based. And we do use Java for performance reasons.

So JavaScript-heavy. Why did you choose Vue.js? Just, just for our interest, you know, it's, it's, uh, React seems to be the, the love of the market, you know. Were there any particular choices around that decision?

I, I made that decision actually, uh, because there was— when we were making the choice, it came— I mean, we either had to choose React or Vue.js, and I personally didn't like the complexity of React's way of doing things. So that's, that's more like a personal preference. But as I said, I try to keep things simple and I find Vue.js a simpler framework.

Yeah, I love that. I resonated with that actually quite easily, Egean, because I do feel React is, is a, is a lot more complex beast than Vue.js is. And if you think about developer experience, I would lean towards Vue.js as well. So that's a— I want to say it's a good choice, but again, you know, you don't know. It's— everyone is different. But keeping things simple is a, it's a very good rule to follow, right? So in the spirit of the show, Ijin, we have this, we have this question: what is one, and it's only one, main thing in Vue.js which is— has the most importance for any tech growth venture?

That's a very general question. Um, I don't know, could you, could you elaborate a little bit?

Yeah, of course. So, so let's say you're starting a tech, you know, tech venture, or you already have one, like, you know, you, you're working part of— what do you think is one most important thing to make sure that you're growing? Could be people, could be processes, could be, you know, technology, anything in your view, is like, what is one most important thing?

I would say, I mean, it's, it's a cliché maybe, but it's product-market fit, maybe.

Yeah, yeah, product-market fit. That's, uh, that's one, uh, yeah, that's, that's one of the most popular ones, uh, product-market fit. But do you want to give us a little bit more detail? Why do you think it's the most, uh, most important one?

I mean Tech is only part of the equation. I believe that business development, marketing, product-market fit, things like this, this, this soft things are actually more important than the tech stack. Because if you, if no one knows that you have a great product, then I mean, what it does, it doesn't really matter. I mean, yeah, you have to, you have to tell the world that, um, you have something special and you— and it's, it's hard to do in today's environment, but you have to go out and do it.

Exactly. So it does, it doesn't matter what the tech powers that product. It could be, you know, it's all gold dust, right? So unless you actually have people wanting to pay for it and you have that product-market fit, it just doesn't matter. So in your view, that's the most important thing?

Yes, I think so.

Okay, thank you, Adrian. So, um, to finish off the show, we do ask people if you have someone in your network which would be good for the show. Would you know— do you have a person you would like to recommend?

Uh, yes, um The name that comes to my mind is, is John Cook, and who does consulting work in areas like applied math and data privacy. He has a strong background in math, has a popular blog, and is a great guy overall. I think he could provide good insights about really hard problems that involve a lot of math and statistics. I believe he consults with a lot of companies, including tech giants. So I would really want to hear his insights about the real hard problems.

Thanks, Ercan. We'll see if we can again join in. Thank you very much. Thanks for being part of the show.

Thank you, my pleasure.

Cheers.