Co-Founder & CEO, Wix.com
Wix Engineering Podcast, episode 14: Coding with the CEO, Avishai Abrahami
Is good enough good enough?
For years Wix engineers were building fine services, but as systems became more complex, it was taking too long to do it. The code was clean, but it took thousands of lines for each service.
It was inefficient, so @Wix’s CEO & Co-Founder, Avishai Abrahami, decided to step in. He set up weekly, hands-on coding sessions with some of his best developers, to chart a new path.
The goal he set for Wix Engineering was that if a project took months before - it would now take days, and every program with 10,000 lines of code - would now be 100.
Listen to this uniqu...
About Avishai Abrahami
Avishai Abrahami, co-founder and CEO of Wix, has been discussing the company's growth, the impact of artificial intelligence on web development, and his management philosophy in several recent interviews. In April 2025, Abrahami stated that Wix sees about 1.5 million new users joining each month and has over 300 million registered users. He noted that while high interest rates have made it harder for small businesses to start and have affected Wix's customers, the company continues to see demand because a website is a critical part of a business. Abrahami also commented on the state of AI, saying he believes large language models will become a commodity and that "none of us will remember LLMs in five years." He expressed skepticism that AI can be controlled, stating, "I believe there's no chance we will be." Abrahami has also spoken about his approach to running Wix. He said he reviews about 130 pages of metrics monthly and 30 pages weekly, arguing that simplifying measurement to only ten things means "they don't know what they're doing." He emphasized the importance of maintaining company culture and not adopting habits from less successful companies. In a 2022 engineering podcast, Abrahami described his hands-on involvement in coding sessions aimed at dramatically reducing the amount of code needed for services, with a goal of making projects that took months take days. He has also discussed Wix's history, noting that the company went public in 2013 with 32 million users and 550,000 subscriptions, and that by 2016 it had grown to 86 million users and over 2 million subscriptions.
Transcript (57 segments)
N
Narrator0:01
Produced by Pi Media.
R
Ran Levy0:06
Hi and welcome to the Wix Engineering Podcast. I'm Ran Levy.
Just about every developer over the course of their career goes through the same evolutionary process. So usually after three years that you're developing, right, you kind of like get to a point where you know how to do loops and ifs very well, and you think that now you understand programming. That's Avishai Abrahami, Wix's shy, timid, always politically correct CEO.
Okay, and then there's like six years that you're talking so much that you just don't want to listen to them. They're so full of themselves. Never mind. And then they get to this place where they're starting to talk about architecture, and architecture would be how do you connect things to things. And at that point they're starting to really again examine how they work and get much more productive to get to this point where you begin to see the bigger picture, not just the trees but the whole forest.
Takes a lot of experience. The longer you edit, the clearer the picture becomes. And then there's something that happens usually between 15 to 20 years, which is like you start to understand how to do most with less. Okay, and this is kind of like how to develop software that is really, really good at being minimal.
Avishai has been a developer for decades, so he can see the forest. He knows how to design efficient software. But among the thousands of developers who work for him, few have reached that 15 to 20-year mark, and so often forests are missed for trees. Code that could be very minimal ends up maximal when a big project starts to emerge.
We review the roadmap as a manager for Wix's server guild and server infrastructure group, Yuval Perry was encountering lots of Wix projects that just seemed to be way too maximal.
Y
Yuval Perry2:17
In a few projects, we took a look at them, and they started off in the first phase didn't deliver almost anything. Delivered like 12 microservices that do crowd work only, and it took several weeks for each one to be published to production. And all of them, 12 of them, took us almost, I think, 36 weeks in order to publish them.
I
Itai Zeidman2:42
That specific project that Yuval mentioned is a big rewrite.
R
Ran Levy2:46
Itai Zeidman, CTO of the server guild. So that is kind of what lit up the issue, right? Of seeing, okay, we're not getting any features, we're just doing a rewrite, but still we're going to pay a very big cost on something that is and will be still relatively simple. So why are we paying that big of a cost? This kind of story just kept repeating itself. It wasn't that everything was going horribly wrong all the time, or that all the developers didn't know what they were doing. The issue is not talent, the issue is what the patterns that people tend to believe in, complicated patterns instead of simpler ones.
What happened was that during the project that Yuval mentioned, he said, okay, I want to understand why it's complicated. I don't think it should be that complicated. Let's understand. Avishai called a meeting together with Itai, Yuval, and some of his other top guns. They went step by step through the typical development cycle to try and figure out what was slowing things down.
And then he finished and he said, okay, now I understand why it takes you that much time. You're recruiting amazing people. I worked with that developer. Your problem is not recruitment, and the problem is not the estimates inside the companies. The problem is you guys.
Avishai pointed at the infra team, at Itai and Yuval, and said, there is no way people need to do all that work again and again and again. It has to be inside the infra. They tried defending themselves, no, but we think that everyone should know like all of these lines and so on and so on. And then that was the stage where he said, okay, we need to be aligned on how to build software.
How to build software. It's funny in a way, we're talking about one of the biggest, most successful software companies in the world trying to figure out how to build software. But of course we're not talking about how to write HTML. We're talking about philosophy, not how to write code, but how should you write code.
Y
Yuval Perry5:00
It's a shifting mindset. I mean, we had our mindset in one place, and Avishai, he had his view on how an R&D organization should be built.
R
Ran Levy5:10
Of course, shifting the mindset of a whole company isn't the kind of thing you achieve overnight. You can't just write an email like, dear everybody, on Tuesday can you all drastically change the way you've been doing your job for your entire lives? Thanks, Avishai. PS: Who ate my yogurt at the break room fridge? I clearly wrote Avishai on the lid.
Y
Yuval Perry5:41
I think that Avishai realized that unless he brings us to the table, right, and gets us to do the mind shift, then there's no way to bring those thousand to two thousand developers into the game, right? Because people can say, okay, this is the directive and we will do it, but they will do it in the least effective way. And if they're on board, if they're, yes, this is what we need to do, then you will get 10 times more out of them. That's why we decided to do a weekly meeting.
R
Ran Levy6:15
A weekly meeting, a convening of the president and his top generals. They called these sessions design patterns because he thought that we don't understand patterns of design. So he said, we need to be aligned, which is a nice way of saying you need to understand my view of patterns of software design.
The concept of design patterns is ancient in software engineering terms. It was first introduced in the 1970s. In a nutshell, it is the idea of using general, reusable solutions to common problems that developers are likely to encounter again and again. In other words, how to not reinvent the wheel each time you need to build a new carriage.
What are these conversations like? What are you talking about?
Y
Yuval Perry7:09
A lot of the early meetings were completely abstract and did not talk about Wix at all, or only used Wix as metaphors and analogies of commonalities. Why? How can we find common patterns between different services? What are patterns of messaging? What are patterns of persistence? How do we know that something happened in the universe? How do systems recover from faults?
R
Ran Levy7:36
So can you paint a picture for me of when you're looking at the source code, what exactly you find wrong with it?
A
Avishai Abrahami7:42
Well, yeah, of course. So I'll give you the most basic thing, right? How do you approach a database, right? How do you access the database? I think that, and this is normally, you would have a developer that will do some kind of a way to connect to the database, then a way to connect and select the data. And my fault is that, well, if you're always doing the same things, you actually should have zero source code, new lines of code. It should always be exactly the same. You should only find ways to override what is not the default.
I want to give you an example, right? The most used software on the planet, the most used are the operating systems. And operating systems in many ways are developer tools, why? Because you write software into them, but they allow you to have a very clear API, a very clear way of overriding things. And that's why it's so easy to consume them as a developer. So in my mind, if you want to build something that allows you to access a database, you should be having like an operating system for accessing databases. Maybe it should be a very closed software that is very good at doing 90-something percent of the thing that you want to do, and then 5% not be able to do at all. And if you don't need anything different, you actually should only change the configuration and that's it. It should work. And that is a very different approach than how do you easily write a database program.
R
Ran Levy9:03
After weeks of very abstract, high-level discussions, they finally got around to the code.
Y
Yuval Perry9:10
This discussion came to the point that we show a service in production and the code, and then we scan the code and throw remarks at it, right? And everybody shows his ideas on how it should be structured in a better way. And we started to analyze how much of this source code we actually need. So, you know, it's like a bit of trash talking also. Avishai says, like, see what do you think can be removed? Oh, you're not seeing it, and stuff like that.
R
Ran Levy9:37
Avishai pushed hard and he didn't budge even a little. For example, in one case they looked over a project from Wix Booking, how much of its code could be removed, they asked. It was about 1,500 lines of code and I think I don't know how many lines of testing. And the answer was one line.
Y
Yuval Perry9:58
1,500 lines, remove 1,419 of them.
R
Ran Levy10:05
That's insanity. As Avishai tried convincing them of his way of thinking, the infra team wasn't exactly on board.
Y
Yuval Perry10:15
And we're fighting with him, no, this has to stay, and this, and so on and so on. They all explained to me that this will never work, this is not how it develops.
A
Avishai Abrahami10:23
After, you can't really blame them. Imagine your boss telling you that you have to be 1,500 times more efficient. It's always scary, right? And there is a way that we know how to do things, why do we have to change it, right? I'm sure that if you ask somebody in a monarchy 500 years ago, would they consider democracy, they would be like, oh my god, that sounds awful.
R
Ran Levy10:44
No, in meeting after meeting, Avishai gradually tried convincing his team to consider democracy.
Y
Yuval Perry10:51
We just went case after case after case after case. And you know, it's just really smart people with me in these rooms. It's interesting because they don't come with stupid arguments against it, they come with brilliant arguments against it, okay? That's the thing, you know, those people are brilliant. But then they started to play with that, and after about a month, a month and a half, the perspective is starting to change on what they do.
R
Ran Levy11:17
Gradually, the infra people came around to Avishai's philosophy.
Y
Yuval Perry11:25
After they grasped, assuming they are prepared and they have the seniority and knowledge and intelligence to understand the benefits, they just became addicted. And now they all became more, oh my god, this is how we have to work, we have to work like that.
R
Ran Levy11:37
After weeks and weeks of debating, Avishai had broken through. Except that wasn't even half the battle, because it was one thing for Avishai to convince Itai and Yuval about his theories, and it was another thing for Itai and Yuval to then go back to their guilds and convince everybody else about something it took even them so long to come around to.
Y
Yuval Perry12:05
And then they went back to their teams and said, listen guys, we need to work like that. And the next thing that happened is that pretty much everybody from those teams has threatened to quit Wix if we move to work like that. They just weren't used to these kinds of ideas.
If I touch on what Avishai said, right, that he said that it takes people, you know, it's like after they code for 10 years and then 12, 15, 20, right? Like it takes them time and maturity, experience to understand that abstractions, you know, in commonality, far outweigh the cons. Right? So this is something that took us time, and we understand that it will take time for others, right?
R
Ran Levy12:50
Educating the engineers wasn't easy. Like Avishai, they first tried to demonstrate the abstract principles before applying them to Wix use cases. That didn't work.
Y
Yuval Perry13:03
We created code in a dark room without Wix concerns. So we took a service that does almost nothing, saves it to the database, presented it, showed, you know, all of the write-up, section level, and then we gave it to engineers. And it wasn't really connected to day-to-day work. It was not connected to what people actually needed, but it was according to our understanding, which was too limited. So what we did immediately after we understood that, we took services from production and we wrote them with the team until they did exactly the same in our way. And this is where we were more connected to the ground.
R
Ran Levy13:43
I'll give an example. So for instance, we had a challenge called GDPR. GDPR is a set of data privacy regulations that apply to citizens of the European Union. When it was first written into law in 2018, basically every company you can think of had to diligently rewrite their software to comply with it. You have to go to every place you are accessing a database, check if that's personal information. If it is, you have to encrypt it, you have to find a way to erase it, you have to do a lot of different things.
Wix distributed documentation to all their developers. Everybody had to read over the new rules and apply them in their code. It was terribly labor-intensive. The laws were complicated, and software is already complicated. Plus, there was no room for error. Even previously simple tasks now had to be rigorously re-evaluated.
Y
Yuval Perry14:42
If you have a customer's database and you have 20 ways of accessing that database from different places, you have to do it 20 times. Multiply every access that you need, it's a massive effort.
R
Ran Levy14:55
Think of how that adds up across a large company. We're talking about tons and tons of new code. They needed a way to contain that bloating. So using the principles of design patterns, the infra team took a step back. They looked at the bigger picture.
Y
Yuval Perry15:15
Every developer that implemented or complied with GDPR, let's say they had 300 lines of code, okay? They, as far as they were concerned, they had the minimum lines of code that they needed to comply with GDPR. The fact was that this was just a local optimum of lines of code. And if you try to go for the global optimum, they say, there's no sense in everyone doing those 300 lines of code.
Everyone was writing their own GDPR code, which was excessive. And in the iteration after this thinking group emerged, we inserted this concern into the framework. We took this principle into every component that we added, every component like SPI, data extension, plugability, whatever. Instead of 300 lines of GDPR in every individual project, we write, let's say, a thousand lines of generic GDPR, but then that saves, let's say, maybe 30,000 lines of code across the services. The teams that use those systems don't have to think about those things anymore. They just have to say, oh, this is a personal identity field, and that's it. By adding that notation to that field, the infrastructure team is solving that for them, and the infrastructure team is doing it once. And that's a massive improvement.
Gradually over time, more and more projects started to align with the design patterns philosophy. So at the beginning, like I said, there weren't really changes because it took a lot of time, you know, of the mindset. And at that point, it was the first time that things started to change, right? People were like, oh my god, it's so much easier, it's so much better, I want to use that. And that team just suddenly started to ask for more and more projects to do in that way. And then it kind of started to drip around and within the company, and to the point today that I think all of the new projects being opened are now built in this kind of a concept and not with our old techniques.
R
Ran Levy17:27
So how has the company overall, as a business, improved as a result of doing these developments?
Y
Yuval Perry17:34
So the places that are using that, I think the development performance is dramatically faster. We assume that it saves about 75% of the work, which means that you have 25% out of that 25, I believe we can save another 50%. They are seeing amazing results with respect to developer time, with respect to the number of lines of code. We're talking about reductions of 70, 80% of lines of code which are cut. You know, some services, complex services, from 25 days to three working days.
R
Ran Levy18:14
So do you think that these design principles, the work that's now starting to be done at Wix, applies to any company out there? Or is it just sort of companies like Wix, large companies, companies that do the kind of thing that you're doing?
A
Avishai Abrahami18:28
Well, it's a really good question, right? So I think if you're building your first product, right, and you have a very simple first product, which is what you should be building when you're doing a startup and you're just starting, then the benefits from that are not going to be huge. In Wix, deploying services to production is by the dozens every day, so we need to automate it. If we were a small company and services would be deployed once in three months, I wouldn't even address this issue.
Y
Yuval Perry18:57
I super agree with you. All right, you know, find a product-market fit. Don't waste time on preparing for the future that will never happen and your startup failed, you know, there's out of money. I was there, it sucks to run out of money. So that's on the one hand.
A
Avishai Abrahami19:15
On the other hand, there is the other problem of you actually succeeding and now you're in deep mud, right? And that's a question, how do you know where to invest, at what point? And to that, I can probably just say, hire good people who have failed and succeeded, and hopefully will have the intuition on what to automate at what point. But I still think that taking that concept of doing less with more, it's still valid even at the small stage, because you can take, you know, you can think about the open source and the ecosystem as your infrastructure group.
R
Ran Levy20:04
Is there anything else that you guys haven't yet gotten to that listeners might want to take away from this story?
Y
Yuval Perry20:10
One thing that listeners might be interested in hearing is what does this project actually contain, right? And what does it have, what does this mean, these abstractions and so on and so on.
R
Ran Levy20:24
To truly fully understand design patterns, we're going to have to talk about Nile, probably the biggest, most important application of their philosophy when Wix infrastructure put everything they learned to the test. I think this is something that we can dive into further, and maybe we'll do it in the next episode. So stay tuned.
N
Narrator21:00
That's it for this episode. Thank you for listening. For a full list of our previous episodes, visit wix.engineering/podcast. The Wix Engineering Podcast is produced by Pi Media, written by Nate Nielsen, produced by Yotam Halachmi, and narrated and edited by me, Ran Levy. Special thanks to Murad Stern from Wix. See you again next episode. Bye.