Subscribe
Share
Share
Embed
For long-form interviews, news, and commentary about the WordPress ecosystem. This is the companion show to The WP Minute, your favorite 5-minutes of WordPress news every week.
Eric Karkovack (00:00)
Hi everyone, and welcome to the WP Minute. I'm Eric Karkovack. Today we're talking about the supposed ceiling of using WooCommerce. The narrative is that once a store reaches a certain size, the platform just can't keep up. My guest today disputes that notion and maybe has a solution. Vedanshu Jain is the co founder and CEO of Urumi AI, a managed WooCommerce infrastructure platform.
He previously worked as a technical lead for WooCommerce. Vedanshu welcome to the WP Minute.
Vedanshu Jain (00:34)
Thank you so much, Eric. And I am really looking forward to this conversation where we will talk about like the scaling, the perceived ceiling when it pertains to scaling in book commerce. And how do we, but also everyone out there can go past it or scale their book commerce sites to the value that they want.
Eric Karkovack (01:01)
Yeah, that it's an interesting subject and we'll get into all that. I I want to start with your time at Automatic. So you were a technical lead for WooCommerce. What does that entail? What kind of things did you have to do there?
Vedanshu Jain (01:14)
Right.
So I was responsible for, so I joined the core team for WooCommerce 2019, which was like my second team inside Automattic. Previously I used to work in the WordCamps team. So the Camtics and all the WordCamps site interface and so on is something that I would work on. Then I worked at WooCommerce for five years and towards the end I was the technical lead for it. One of the interesting thing that
that
I had the privilege to let was the HPS project, where we essentially migrated or started the database to storing everything in the post tables to dedicated order tables.
Eric Karkovack (01:59)
Yes.
Vedanshu Jain (01:59)
That's something I am super excited about because it unlocked a lot of performance improvements that were really hard to work around earlier. Then my focus area has been performance around scale.
scaling. even like I remember when I joined the WooCommerce core team, the first major project that I had was making sure that we do not oversell, right? So when I joined, was this issue with WooCommerce where if there are like multiple people sending out the same product, we might oversell like, you know, stock count could get to negative, right? And that was the first thing we saw or that was the first thing I was responsible for solving even on anything from like a multi-million deployment to like WordPress.
running on a Raspberry Pi. This led the foundation of what I would work on and I would naturally gravitate towards performance improvements, would naturally gravitate towards scaling issues, which I did a lot of during my time at WooCommerce or at Automatic. yeah, that's like, here I am continuing that work even after Automatic.
Eric Karkovack (03:11)
I
can imagine the the whole idea of moving the WooCommerce order system to their own tables, that had to be a massive undertaking.
Vedanshu Jain (03:21)
Yes, so the challenges that we're facing were, so like the technical part was easy, right? Like it just code, you write code, you deploy all code, right? But then we have like this massive ecosystem of third party plugins, custom themes, custom code and so on that are, you know, still reading from the post tables that are still writing to the post tables. So we have to make sure that when we roll it out, the site doesn't break. The orders do not stop flowing irrespective of
what Merchant has said.
The second challenge we had was that not all the merchants would have access to highly technical people that can enable or disable this for them, which means that the interface has to be intuitive enough. has to be safe enough to be operated by anyone, which we think we did. We did roll out this project without any fires in the community, without site going down, without issues. And then the interface was simple enough, ultimately, that people
were able to use it, like the merchants were able to use it. I think the biggest, the biggest principle, like the underlying principle we worked off was this inversion of blame. If something goes wrong, we cannot blame the operator of the site, which is often the merchant, that you know, hey, you should not click on this setting, Hey, you should have read the doc, right? Hey, you should have done your research before doing this, right? Because the
it sort of, you know, like removes our responsibility. Instead, the approach that we went for was this inversion, which means that we reached out to as many third-party developers as we can to get their plugins. We reached within this like upgrade parties, where we invited people to like, you know, upgrade their plugin with us. And we, including me, my teammates, they would provide real-time support for these plugin authors to upgrade their plugins, answer their
questions be available all the time. We make sure that there's enough documentation in place for them to do so. We make sure that there are safety mechanisms in the code itself. So there is this mechanism of synchronizing to the old tables like at the same time so that plugins will continue working. There were this like, know, red warnings or this like, you know, labels where if something is not compatible, it would tell you. But essentially what we want to like, what we wanted to do was to execute this mask
massive rearranging the internals of O-Commerce without increasing the operational overload or without having merchant side go down. So that was the challenges behind this entire project. It took two years, right? So when we started working on it within the first year, we had the implementation done and then it took one more year to get to a state where we can
enable it by default for new sites. Because of all these underlying challenges that we want to make sure that people are not distracted by this change.
Eric Karkovack (06:34)
Yeah, I mean from from my perspective, just you know, have running several WooCommerce sites for clients, I I've noticed it went very smoothly. So congratulations on that. so you took that experience that you gained as a as a technical lead and you turned
Vedanshu Jain (06:49)
Mm-hmm.
Eric Karkovack (06:50)
it into a Urumi. Now how d how did that come about? And and tell us a little bit about what Urumi does.
Vedanshu Jain (06:57)
Right, so we decided to like start URUMi. Well, we are at this fundamental shift, right, like with the AI making this breakthrough changes. however way you look at it...
the world is going to change, right? It's much bigger than previous waves, it's much bigger than previous technological advancements. I personally think, in my opinion, it is one of the biggest things that, if not the biggest, it's definitely one of the biggest things that people see in our career. And we decided that this is something that we must take advantage of, we must dial into it. And...
You know, like, so scaling and performance is something that I have always wanted to fix, I have always wanted to enable. So that was the first, like we started, we did not start it as a Ruby.ai, we actually started as Starshot.dev, which was just the performance and the scaling platform, right? Then we rebranded to Ruby to take advantage of the AI. And you know what?
AI works so much better with the open source than it would work with any closed source system. Because in a closed source system, we have this like fragmentation of data. So for example, if you take a look at a Shopify site, some data exist in like some third party apps, their servers, their database. Some data exist in a custom app. Even Shopify doesn't have direct access to that data and that code.
With AI on open source, not only does it the full access, it can also read the code to figure out how things are stored in the database, what to do, what not to do. Which means that once you start working with AI on the open source, you will get really, powerful results. You can modify whatever you want. You can answer whatever queries of the customers that you want. You can really manage it well. And this is why we started Udemy to make sure that these benefits.
are available to people in the community, are available to merchants, are available to freelancers, spec developers and so on. So this was like the whole principle while making sure that like the scaling experience is also top notch. There is no ceiling. You do not have to, you know, like migrate to big commerce like an existing host wants you to do to, you know, just like get past the ceiling barrier for WooCommerce.
Eric Karkovack (09:32)
Yeah, I it well WooCommerce is interesting to me because i okay, it's part of WordPress, you know, it a and I think a lot of times we who build sites and maybe people who own sites wanna treat it just like another WordPress site.
you know, a and we'll
Vedanshu Jain (09:46)
ring.
Eric Karkovack (09:47)
put it on shared hosting and we'll put it on or or or small VPS or something like that. But y in your experience, like what kind of bottlenecks do you tend to see and and like what size does a site need to get to to really start having those performance issues?
Vedanshu Jain (10:02)
Right.
Right.
So with WooCommerce, you can go really far on a simple hosting, just to be honest. So the main bottleneck with WooCommerce is that you will have a lot more requests reaching your servers than a WordPress site. So the main way that people handle scaling WordPress site is caching. So you put a cache in front of your site. So most of the requests would be served by cache. They do not teach your origin.
for example, once you add something to the card, that request cannot be cached anymore, right? Because the home page is changed, right? Like how it renders changed, right? Which means that a lot more requests that could have been handled by cache now have to be answered by a server. Going even further, sometimes the home page itself cannot be cached based on the plugins that you're using, based on the, maybe you're setting a session cookie, maybe you're setting a session for the users, in which case even the home page, like,
fresh render can not also be cached, right? And I think that's the, that's like the sort of main differentiator or sort of like, you know, defense that people experience when dealing with a WordPress site versus a WordPress with bookmark site, right? And even on like, like entry level hosting, you can get really, far if you configure these things right, right? If you can configure that,
as much as possible your site can be handled by cache. If possible, your add to cart is like an AJAX request later on rather than like, you know, something that's like rendered beforehand. You can like go really far on a budget hosting. That said, it does require some technical know-how, it does require some expertise.
If you do not want to do that, you can always upgrade. You can have more PHP workers, can have more like a better server, which can then again go really far. Right. I have seen sites doing like 1 million per year on like $100 per month hosting or like 150 or $200 per month hosting. But it really depends. Like, you know, the number of orders, average order value, how many transactions, whether you are running meta ads, whether you are running.
whether it's like all organic traffic and so on, that really impacts how much can you scale or what sort of server configuration that you need for your site.
Eric Karkovack (12:37)
Yeah.
And I I I kinda wonder these days too, because we're seeing so much bot traffic to sites. And I I know we're there's been a lot of talk about agentic commerce coming at some point where you're
Vedanshu Jain (12:47)
this.
Eric Karkovack (12:48)
going to be able to order something. and we we just had an episode with Brian Coords, who's a developer advocate
Vedanshu Jain (12:55)
Yes.
Eric Karkovack (12:56)
at Woo, and he was talking about the future where agentic commerce could you know, you could be in chat GPT and and asking about a specific product and you know you might be able to order it right from a WooCommerce.
site. But then
Vedanshu Jain (13:10)
ride.
Eric Karkovack (13:10)
there's there's all this bot traffic now hitting sites, so that's another concern that I think even caching
Vedanshu Jain (13:16)
Right.
Eric Karkovack (13:16)
can't necessarily fix, right?
Vedanshu Jain (13:19)
Great.
So for the bot traffic, so first off, caching can most definitely deal with bot traffic. The only problem is a bot is going to go through pretty much all your products. So if you have 100 to 100 products, caching would generally be able to cache all the pages. It would generally be able to cache all the dynamic pages. traffic doesn't reach you. But for example, for one of our customers, have like,
400,000
products. They cycle through 100,000 products every day. There's like, you know, being decommissioned, adding new and so on. Then bot tries to like, enumerate all the new 100,000 products because it wants to index it. And then like, you know, your, your caching will go for a toss, right? Because you cannot like possibly hold that much of data in your caches, right? The way to do it is like, it fast, right? So it's not a, well, it is not a magic bullet, right?
I was going to say that it is also something that requires expertise. But honestly, not anymore. If you work with AI, if you work with Cloud, you will go really, really far in optimizing your initial page load to make sure that those broad graphics are handled well. So that's one.
is to just make your site faster, which can be really interesting, but it can also be really complex depending on your site and depending on the person doing it. Second is caching. If you have 100, 200 products, 500 products, maybe caching is fine. The bot will be able to handle it. Whether you are using Cloudflare, whether you are using an inbuilt cache from your host, they would usually be able to handle it. You can also ask them what is their capacity.
to hold cash for you and that would also tell you like how much of your site are they going to cash for you. The size of your product pages matter. If you have like a very big product page for example you're going to run out of cash faster than than bot can pass it through. So that's another thing you might if you can reduce like you know the size of your products pages or side of the pages that bots are going that's also fine. That said
The is not really like, you know, the bot traffic that we want to parse, that we want to allow, it's okay. It's not like, obviously it's more than the human traffic, like for all the sites we manage, the ratio is like, you one to five, between one to five to one to 10. So it is a lot, but bots are not going to add to cart, bots are not going to check out, bots are not going to do a lot of things that puts stress on your servers.
If cache is configured well, if site is configured well, you are not really like, it's okay. It's not bad, it's okay. It can be handled and your site can appear across all the chat channels, all the AI agentic channels, which will give you, up a new line of revenue for you.
Eric Karkovack (16:31)
Okay. Well thank you for that explanation. I so you're using AI in Urumi How how does
Vedanshu Jain (16:38)
Yes.
Eric Karkovack (16:39)
that help with scaling? Like I I I've now I've read through your site and you know like it can detect certain th certain
Vedanshu Jain (16:45)
Yes.
Eric Karkovack (16:46)
characteristics, right, and then adjust based on that?
Vedanshu Jain (16:49)
Yeah.
Right.
So we use the power of open source to full extent. So I generally believe that open source is one of the most powerful ideas of our generation, and we take it to the extreme. So we have an AI running which monitors the request. It figures out what the slow requests are. So there is this concept called traces, which tells you where the request spent its time, whether it was generating the page, whether it was fetching the products, whether it
fetching the cart or whatever. So there's this concept of traces, which we do, and an AI will run, and it will figure out what are the slow code path, and it will automatically fix it. So this, earlier I said, like with Claude and with like ChatGPT or Gemini, you can go like really far. We put it as something that is available inside the system, which means as site continues to operate,
it faster and faster and
Over time, we have sent out patches to multiple plugin authors as well. That, we found the slowness in your plugin that is impacting about this one. This is how you can fix it. We are running a hot patch right now. But if you could fix it by next release, then it would be great. So we do this, which means that the site is fast. So that's the first thing you want to do. You want to make sure that your site is fast. If your site is fast, it can handle more number of
per unit time than if not.
The second thing we do is scaling. We scale dynamically as and when the request comes in. We put in more resources. We put in more servers. If the requests do not come in, we bring it down, right? Which means that we can provide servers capacity to our customers at a price that they would not like that otherwise like super expensive, right? So you could always like plan for peak capacity.
recommendation is if you're running static servers is to plan for like 20 % of your capacity right so that there's like this 80 % headroom you know like whatever your peak traffic is you your server should be at 20 % utilization if to account for you know any like viral movement or account for any like unplanned traffic spike but it can be expensive right it can be expensive to get this big servers that have 80 % headroom
Do run your site all the time.
But with auto-scaling, but with getting the sources when you need it, automatically means that you can do that at a much reasonable price point where it makes sense to you. And this is not something new, right? Shopify skills like that, all the big company skills like that, use this. So there's this technology called Kubernetes that we use. Everyone uses that, right? It's not that popular in the WordPress ecosystem, I imagine, where we run.
like static servers, we run like fixed servers. But it's like really, really popular way to scale the site. Everyone uses it. And that's what we do too. It's not something like weird that you're doing. It's just that if you configure your systems that way, WooCommerce at the end of the day is just another PHP application. And it can scale to whatever you want it to.
Eric Karkovack (20:25)
Yeah, so that that kinda reminds me of just, you know, the the the the old AWS type thing where, you know, you're just paying for what you're using instead of just, you know, I'm I'm paying my server
Vedanshu Jain (20:34)
Yes.
Eric Karkovack (20:34)
company a thousand dollars a month for this massive grid here,
Vedanshu Jain (20:38)
Yes.
Eric Karkovack (20:40)
instead of, you know, just paying as
Vedanshu Jain (20:42)
Yeah.
Eric Karkovack (20:42)
for what I need when I need it. So like, you know, Black Friday and things like that, maybe I'm paying a little more, but I'm also making more
Vedanshu Jain (20:49)
Yes.
Eric Karkovack (20:50)
because I'm getting more traffic.
Vedanshu Jain (20:52)
Yes,
and if you get traffic, like if you are getting orders, you really don't mind paying for more servers, right? Because why would you? You do need your shop owner, if that makes sense.
Eric Karkovack (21:03)
Exactly, exactly. So I mean I I'm making more money, so of course, you know, I need the the server
Vedanshu Jain (21:08)
Yes.
Eric Karkovack (21:08)
capacity to do that and that's kind of the be a better deal, I would imagine.
Yeah, one of the things I also noticed about Urumi that was kind of cool was that you know when you're updating your your site, especially an e-commerce site,
Vedanshu Jain (21:24)
You
Eric Karkovack (21:25)
things can break, right? I mean a plugin could have
Vedanshu Jain (21:27)
Peace.
Eric Karkovack (21:28)
an issue. Even WooCommerce itself might have a bug in it that hits an edge case. but your
Vedanshu Jain (21:31)
Yes. Yes.
Eric Karkovack (21:35)
service has a way to repair that through AI as well? How how does that work?
Vedanshu Jain (21:40)
Right.
So what we do is, so we monitor, we follow like.
really great coding practices that are industry standard, which means that we monitor slow requests, we monitor 500s, we monitor fatals. And as soon as they happen, AI will go and find out the root cause and fix it. So that's one, that's at the operational level. But before that, we had this concept of staging environments, we had this concept of workspaces, where you modify your code first, update the plugins, add custom function, whatever it is you're
doing, right? Once you're happy with it, you deploy it. And while you're deploying it, it goes through a QA path where it tests out all the changes, where it makes sure that basics work before it deploys to production. And again, we leverage AI to do that. We let AI write test cases. AI can drive a browser. It can go through all the flows. It can add to cart, check out, and so on. And we let it do it for the first time.
And as it is doing it, we are also writing script so that next time it's automated. We are also conscious about how many tokens to be won. We do not want to throw AI at everything. So we let it run once. We create scripts as it goes. And then the next time onwards, would run the script. If something fails, then AI will go in and do it manually, like that part of the test. Sometimes an element change, a positioning change, so the test
needs to be updated, sometimes something actually is failing, and in which case we will detect and we will block the deployment. So that's how we work. The other thing we do is there is no update button. There is no plugin update button. If you're hosting with us, if you go to a production site, if you open the plugins menu, there's no update button. Because AI will take care of the updates. It will take care of
what
needs to be updated what doesn't. Sometimes it will ask you if the changes are major, it will ask you to take a look at as well. But as much as possible, it will try to do it itself. Update button is something I also have like daily personal gratitude, if that makes sense. I think that's like not a great experience for merchants. And you know, you you maintain your client side, right? You can update, you know how to do this, you know, plug-in config test, you know how to know when to update and when to...
right? Much in modern know that, you know, they would see an update button, they will click it, something will break. And once something is break on update, next time onwards, they will always be stressed, right? They will, they will always be this like,
Eric Karkovack (24:31)
Absolutely.
Vedanshu Jain (24:32)
fearful of, you know, clicking that button, which is not great, because an update could have security issues, security patches, could have performance patches, you don't want that. And so another thing we try to do is to make the experience as seamless as possible, leverage
leveraging industry best practices, practices of testing, automated testing and so on.
Eric Karkovack (24:56)
So where do you see this maybe in a year? Like what what would you like to see a Urumi do and and and and how do you think maybe AI will help you get there?
Vedanshu Jain (25:07)
Right.
I think that AI solves one of the biggest drawbacks by far of using Google Maps. So there's this concept, right, that's by a thousand cards, I think it's called. So there are like, know, this like multitude of small, small issues. Like nothing is like really very bad, but like it's just that there are like many of them. There are many small, small issues that you need to deal with.
I think AI solves that problem, whether that's a slow request path, whether that's like a small bug. I think AI really solves it. With open source, with open data, it solves it very effectively. There is no third party app that it needs to go to. There is no third party server that it needs to access. It has all the code, it has all the data, it has all the context available to fix something. And I think that's how, that's the way that Urumi
So we already, for a company that started like this year, we are already hosting, one of our customers is actually featured on bookcommerce.com. They
Eric Karkovack (26:18)
Okay.
Vedanshu Jain (26:19)
are featured on bookcommerce.com as a case study on scaling their company. They have like billions in revenue, have like thousands of orders per hour, and they are featured as a case study.
like on our platform, right? And we feel that this is the way we are going to go. We think that lot more hosts will adopt AI practices, will adopt AI internals as part of their workflows, because the benefits are huge, right? It solves this like the biggest problem in more commerce. And I think if it is done right, like I think if the community adopts it, like not just to do me, but like with the
other
host a well if they really adopt it if they really you know like mechanize it I believe that open source will be like the absolute winner
from AI. I think the gains that AI have from open source, or rather the gains that open source has from AI, comes anything else. And I believe if things are done right in next five years, open source based e-commerce platforms like Google commerce would absolutely dominate the market.
Eric Karkovack (27:39)
Well that's fascinating. I I I think i i it's an interesting way to approach this. I mean we you know, they traditionally we've just thrown more hardware at it, more memory at
Vedanshu Jain (27:50)
Yes.
Eric Karkovack (27:51)
it.
And having a a tool that kind of can detect and and manage it for you and fix all the little things, as you said, that that that
Vedanshu Jain (28:00)
Thanks.
Eric Karkovack (28:00)
pop up when you're running WooCommerce. You know, merchants don't have to think about it. And I think that is a win for open source. That's definitely a win for WooCommerce. so
Vedanshu Jain (28:10)
this.
Eric Karkovack (28:12)
where can people go to learn more about Urumi and connect with you online?
Vedanshu Jain (28:17)
Right, so I am accessible on WordPress Slack, I'm accessible on WooCommerce Slack, people can email me at vedanshu@urumi.ai, they can DM me, I try to be generally accessible, right? I do not use like, X a lot, but otherwise, I do not have an Instagram account also, but otherwise I'm accessible, right? The other thing people can do is they can add their email on the urumi.ai website and you will be sure to reach out.
Eric Karkovack (28:47)
Wonderful. Well, we'll make sure to put that in the show notes so people can can check out a urumi and see what it might be able to do for them. Vedanshu I really appreciate your time today, and I want to thank everybody who watched and listened to this episode. Visit us over at the WP Minute.com slash subscribe, grab our newsletter, become a member, support the work we do here at the WP Minute. Thanks, and we will see you again next time.