Let’s Debunk the WooCommerce Scaling Myth ![rw-book-cover](https://i.ytimg.com/vi/DZ_2DuuHTOE/maxresdefault.jpg) 🔗 **Source:** [Let’s Debunk the WooCommerce Scaling Myth](https://www.youtube.com/watch?v=DZ_2DuuHTOE) > [!note]+ Document Notes > --- > tags: [woocommerce, ecommerce-scaling, caching, web-performance, ai-site-operations] > author: WP Minute Podcasts > source: The WP Minute > reference: https://www.youtube.com/watch?v=DZ_2DuuHTOE > date created: 2026-09-14 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Let's Debunk the WooCommerce Scaling Myth > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [Episode page: Let's Debunk the WooCommerce Scaling Myth (The WP Minute, published 2026-09-14)](https://thewpminute.com/lets-debunk-the-woocommerce-scaling-myth/) > - [YouTube: WP Minute Podcasts upload](https://www.youtube.com/watch?v=DZ_2DuuHTOE) > - [Urumi (guest's company)](https://urumi.ai/) > - [WooCommerce developer docs: High-Performance Order Storage](https://developer.woocommerce.com/docs/features/high-performance-order-storage/) > - [WooCommerce developer blog: Performance benchmarking for WooCommerce HPOS (2023-03-17)](https://developer.woocommerce.com/2023/03/17/performance-benchmarking-for-woocommerce-hpos/) > - [WooCommerce developer blog: The plan for the WooCommerce custom order table (2022-01-17)](https://developer.woocommerce.com/2022/01/17/the-plan-for-the-woocommerce-custom-order-table/) > - [WooCommerce developer docs: Configuring caching plugins](https://developer.woocommerce.com/docs/best-practices/performance/configuring-caching-plugins) > ## 📝 Summary > - **What happened:** Eric Karkovack hosts a 29:20 episode of The WP Minute+ podcast with Vedanshu Jain, whom the episode page lists as CEO and co-founder of Urumi AI and a former WooCommerce technical lead. Jain says WooCommerce has no fixed scaling ceiling: the limits merchants hit come from uncacheable cart and session requests, bot crawls of large catalogs, and slow code paths, and each has a fix. > - **Why it matters:** The episode pairs a first-hand account of the High-Performance Order Storage (HPOS) rollout, which moved orders out of `wp_posts`/`wp_postmeta` into four dedicated tables, with a vendor pitch for AI-run hosting. WooCommerce's own 2023 benchmark reports 5.1x faster order creation and 40x faster filtering by customer ID with HPOS, which backs the "WooCommerce can scale" half of the argument with first-party numbers. > - **Key stakeholders:** WooCommerce merchants, freelancers and agencies who host stores, plugin authors whose code still reads order data from post tables, managed hosts, and the WooCommerce core team. > - **Risks and tradeoffs:** The guest sells the solution the episode describes, and most numbers (a store doing $1M a year on $100–$200/month hosting, a 400,000-product catalog, a 1:5 to 1:10 human-to-bot ratio, a customer with "billions in revenue") are unverified anecdotes. AI agents that hot-patch third-party plugins and remove the update button move update decisions from the merchant to the host, which raises review and disclosure questions the episode doesn't address. > - **Bottom line:** The mechanism claims (cart state defeats page caching, HPOS removed an order-storage bottleneck, autoscaling trades fixed headroom for per-use cost) match WooCommerce's first-party docs. The market prediction (open-source commerce "would absolutely dominate the market" in 5 years) and the Urumi-specific results carry no evidence in the episode. > ## 📖 Main Content > - **Core argument 1, HPOS removed a structural bottleneck.** Jain says they led the HPOS project, which moved order storage from the WordPress posts tables to dedicated order tables. WooCommerce docs name the tables `_wc_orders`, `_wc_order_addresses`, `_wc_order_operational_data`, and `_wc_orders_meta` (with the site's table prefix). Jain says implementation took about 1 year and reaching default-on for new sites took 1 more. The public record fits that estimate: the plan post ran 2022-01-17, the early-adopter call came in May 2022, HPOS shipped as opt-in in WooCommerce 7.1, and WooCommerce 8.2 (October 2023) enabled it by default for new installs. > - **Core argument 2, "inversion of blame" as a rollout principle.** The team treated a broken store as the project's failure, not the merchant's. Jain lists the mechanisms: outreach to third-party plugin developers, "upgrade parties" with real-time support, documentation, a sync mode that keeps writing to the old post tables so unported plugins keep working, and incompatibility warnings in the admin. The HPOS docs confirm the compatibility-mode sync and a `wp wc cot sync` CLI command. > - **Core argument 3, the real bottleneck is uncacheable requests.** A plain WordPress site serves most requests from a page cache. Jain says a WooCommerce request stops being cacheable once a visitor adds to cart, and a plugin that sets a session cookie can make even the homepage uncacheable. WooCommerce's caching guide supports the mechanism: it tells you to exclude Cart, My Account, and Checkout and to bypass cache for the `woocommerce_cart_hash`, `woocommerce_items_in_cart`, `wp_woocommerce_session_`, `woocommerce_recently_viewed`, and `store_notice[notice id]` cookies. Jain's fix list: cache as much as possible, load add-to-cart state by Ajax after render, or buy more PHP workers. > - **Core argument 4, bots are a cache-capacity problem, not a checkout problem.** Jain says a site with 100–500 products can cache every page a crawler hits. A catalog of 400,000 products with 100,000 changing daily (a customer anecdote) outgrows cache capacity, so page generation speed decides whether the site holds up. They say bots outnumber humans by 5x to 10x across Urumi-managed sites (speaker estimate; the caption's ratio direction is ambiguous) but don't add to cart or check out. > - **Core argument 5, AI operations plus autoscaling.** Jain describes Urumi's system as request tracing that finds slow code paths, AI-generated fixes, hot patches sent upstream to plugin authors, Kubernetes-based autoscaling, staging "workspaces," an AI QA pass that writes reusable test scripts to limit token spend, and no plugin update button on production. These are the guest's descriptions of their own product. Urumi's blog post (Vedanshu Jain, updated 2026-08-26) confirms upstream fix submission ("including to Automattic") and managed APM. The post doesn't mention Kubernetes. > - **Terms defined.** > - *HPOS*: High-Performance Order Storage, WooCommerce's dedicated order tables (captions render it "HPS"). > - *PHP workers*: the number of PHP processes a host allows at once, which caps concurrent uncached requests. > - *Traces*: per-request timing records that show where a request spends its time. > - *Autoscaling*: adding or removing servers as request volume changes. > - *Agentic commerce*: AI assistants placing orders on a shopper's behalf. > - **Uncertain or contested claims.** > - The "20% utilization at peak, 80% headroom" figure for static servers is a rule of thumb the guest attributes to general practice without a source. > - "WooCommerce… is just another PHP application. And it can scale to whatever you want it to" skips the database and session layers, which don't scale horizontally the way stateless PHP containers do. > - The claim that "an existing host" pushes merchants to migrate to BigCommerce names no host and goes unverified here. > - Urumi's founders page lists Naman Malhotra and Vedanshu Jain. A search summary of a Repository newsletter article named a different co-founder, and that article [0:01] 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 the 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 Urmi AI, a managed WordPress work WooCommerce, excuse me, infrastructure platform. He previously worked as a technical lead for WooCommerce. [0:34] Vedanshu, welcome to the WP Minute. >> Uh 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 uh when it pertains to scaling in WooCommerce, and how do we, but also everyone out there, can can go past it, or scale their WooCommerce sites to the value that they want. >> 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 uh a technical lead for WooCommerce. What does that entail? What kind of things did you uh have to do there? [1:18] >> So, um So, I was responsible for So, I joined the core team for WooCommerce 2019, which was like my second team inside Automatic. Previously, I used to work in the WordCamps team. So, the camp takes and all the WordCamps, like, you know, site interface and so on is something that I would work on. Then, I worked at WooCommerce for 5 years, uh and towards the end, I was the technical lead for it. [1:47] The one of the interesting thing that I had the privilege to lead was the HPS project, where we essentially migrated, or, you know, like, the started the database to storing everything in the post tables to dedicated order tables, right? >> Yes. >> That's that's something I am like super excited about because it unlocked like a lot of lot of performance improvements that were really hard to work around earlier, right? [2:15] Then, my focus area has been performance around scaling. So, 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, there was this issue with WooCommerce where if there are like multiple people selling out the same product, we might oversell, like you know, stock count could get to negative, right? [2:38] And that was the first thing we solved 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, right? This laid the foundation of like what I would work on and I would naturally gravitate towards performance improvements. I would naturally gravitate towards scaling issues, which I did a lot of during my time at WooCommerce or at Automattic. [3:07] And yeah, so that's like here I am continuing that work even after Automattic. >> I can imagine the the whole idea of moving the WooCommerce order system to their own tables. That had to be a massive undertaking. >> Yes. So, the challenges that we were facing were So, like the technical part was easy, right? Like it just code. You write code, you deploy, all good, 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. [3:46] 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, you know, uh enable or disable this for them, which means that the interface has to be intuitive enough, it has to be uh 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, you know, issues. [4:23] And then the interface was simple enough ultimately that people were able to use it. Uh uh like people were like the merchants were able to use it. I think the biggest um the biggest like the principle like the underlying principle we worked on was this inversion of blame, right? 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, right? Hey, you should have read the doc, right? Hey, you should have done your research before doing this, right? [4:55] Because that sort of, you know, like removes all the 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 upgrade our plugins. We released 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. [5:28] We made sure that there's enough documentation in place for them to do so. We made sure that there are safety mechanisms in the code itself where 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, you know, red warnings or this like, you know, warning labels where if something is not compatible it would tell you. [5:50] >> Right. >> But essentially what we want to like what we wanted to do was to execute this massive like, you know, massive like rearranging the internals of WooCommerce without uh without increasing the operational overload or without like having merchant site go down, right? So, that was like the challenges behind this like this entire project. It took like 2 years, right? So, with like >> Yeah, 2 years. [6:14] >> When we started working on it within the first year we had uh we had the implementation done. >> Right. >> And then it took 1 more year to be to get to a state where we can like enable it by default for new sites, right? Because of all these underlying challenges that uh that we want to make sure that people are not disrupted with this change. [6:37] >> Yeah, 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. Um so, you took that experience that you gained as as a technical lead and you turned it into Aroomi. How did How did that come about and and tell us a little bit about what Aroomi does? >> Right. So, so we decided to like start Aroomi. [7:04] Uh well, we are at this fundamental shift, right? Like with the AI making these breakthrough changes. Like however way you look at it the world is going to change, right? It's not it's much bigger than previous waves. It's much bigger than previous technological advancements. And we've been like I personally think in my opinion it is one of the biggest change that if not the biggest, it's definitely one of the biggest change that we will see in our career. [7:34] And we decided that this is something that we must like must take advantage of. We must dial into it. And you know, like so scaling in 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 started as a roomi.ai. We actually started as a starshot.app which was just the performance and the scaling platform, right? Then we rebranded to roomi to take advantage of the AI. [8:04] And you know what? AI works so much better with the open source than it would work with any closed source system, right? 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, right? Some data exist in like, you know, some third-party apps, their servers, their database. Some data exist in a custom app, right? It it does not like even Shopify doesn't have direct access to that data and that code, right? [8:37] >> Sure. >> With the AI on open source not only it has like like the full access it can also like read the code to figure out how things are stored in the database, what to do, what not to do. Which means that when you once you start working with the AI on the open source, you will get like really really powerful results, right? You can modify whatever you want. You can answer whatever queries of the customers that you want. You can really like manage it well. [9:03] And this is why we started a roomi to make sure that these benefits are available to people in the community. Are available to merchants, are available to freelancers, web 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 BigCommerce like like an existing host wants you to do uh to, you know, just like get past the ceiling barrier for WooCommerce. [9:34] >> Yeah, I I WooCommerce is interesting to me because it okay, it's part of WordPress, you know, and and I think a lot of times we who build sites and maybe people who own sites want to treat it just like another WordPress site, you know, and we'll put it on shared hosting and we'll put it on our small VPS or something like that. But in your experience, like what kind of bottlenecks do you tend to see it and like what size does a site need to get to to really start having those performance issues? [10:06] >> Right. So, with WooCommerce, you can go like really far on a on a simple hosting, like just to be honest. Um so, the main bottleneck with WooCommerce is that you will have lot more requests reaching your servers than a WordPress site, right? So, the main way that people handle um like scaling WordPress site is caching, right? So, you put a cache in front of your site, so most of the requests would be served by cache. They do not need to generate all the data, right? [10:36] With WooCommerce, for example, once you add something to the cart, it's that request cannot be cached anymore, right? Because like the homepage is changed, right? The like the like how it renders changed, right? Which means that lot more requests that would have been handled by cache now have to be answered by your server. Going even further, sometimes the homepage 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 homepage like a fresh render can not also be cached, right? [11:10] And I think that's the that's like the sort of main differentiator or sort of like, you know, difference that people experience when dealing with a WordPress site versus a WordPress with WooCommerce site, right? And even on like like entry-level hosting, you can get really 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. [11:41] If possible, uh your add to cart is like an Ajax request later on rather than like uh you know uh something that's like rendered beforehand. You can like go really far on a budget hosting, like 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. You 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. [12:20] But it really depends, like you know, the number of orders, the average order value, how many transactions, whether you are running meta ads, whether you are running um whether it's like all organic traffic and so on. That really impacts how much can you scale or like what sort of server configuration that that you need for your site. >> Yeah. >> It's and I I I kind of 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 uh agentic commerce coming at some point where [clears throat] you're going to be able to order something uh and we we [12:53] just had a an episode with uh Brian Cordes, who's uh a developer advocate at Woo, and he was talking about the future where agentic commerce could uh you know, you could be in chat GPT uh and and asking about a specific product and you know, you might be able to order it right from a WooCommerce site. Um but then there's there's all this bot traffic now hitting sites. So, that's another concern that I think even caching can't necessarily fix, right? [13:22] >> Right. So, um So, for the bot traffic, like uh So, first off, caching can most definitely deal with bot traffic. The only problem is a bot is going to like go through pretty much all your products, right? So, if you have like 100, 200 products, caching would generally be able to cache all the pages, like, it would generally be able to cache all the dynamic pages. [13:46] So, like, the traffic doesn't reach you, right? But, for example, for one of our customers, they have like, you know, 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? [14:09] Because you cannot like possibly hold that much of data in your caches, right? The way to do it is like have it fast, right? So, it's not a Oh, well, it is not a magic bullet, right? Like, I was going to say that it is also something that you got as expertise. But, honestly, not anymore, you know, if you work with AI, if you work with Cloud, you will go like really, really far in optimizing your initial page load. [14:35] With, uh uh to make sure that those bot traffics are handled that way. So, so, that's one, right? That's one. Um is to just make your site faster. Which is which can be really interesting, uh 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, like, the bot will be able to handle it. [15:03] Whether you're using Cloudflare, whether you're using like an inbuilt cache from your host, they would usually be able to handle it. You can also ask them what is the, you know, what is like what's their capacity uh to hold cache for you, and that would also tell you like how much of your site is are they going to catch right? >> The size of your product pages matter. [15:25] If you have like a very big product page, for example, you're going to run out of cash faster than uh than bot can pass it through. So, that's another thing. You might If you can reduce like, you know, the size of your product's pages or size of the pages that bots are going, that's also fine. That said, bot is not really like, you know, the bot traffic that we want to pass, 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 know, 1:5 between 1:5 to 1:10, right? [16:00] 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, right? >> Sure. >> You So, if if like cache is configured well, if site is configured well, you are not really like it's okay. It it's not bad. It's okay. It can be handled, and your site can appear across like all the chat channels, all like the AI agentic channels, which will give you like open up a new line of revenue for you. [16:34] >> Okay. Well, thank you for that exploration. I So, you're using AI in your roomie. How How does that help with scaling? Like, I I I've Now, I've read through your site, and you know, like, it can [clears throat] detect certain certain characteristics right, and then adjust based on that? >> Right. So, we use like So, we use the power of open source to full extent, right? So, I genuinely believe that open source is one of the most powerful ideas of our generation, and we take it to the extreme, right? [17:05] So, we have an AI running, which monitors like the request. It figures out what the slow requests are. It will try to So, there is this concept called traces, which tells you where the where the request spend its time, right? Whether it was like generating the page, whether it was fetching the products, whether it was fetching the cart or whatever, right? Uh so, there's this concept of traces, which we do. [17:29] And and the AI will run, and it will figure out what are the slow code path, and it will automatically fix it, right? So, so this like uh earlier I said, right? Like with Cloud and with like uh ChatGPT or Gemini, you can go like really far. We we like put it as a as something that is available inside the system, right? Which means as like site continues to operate, we will make it faster and faster and faster, right? [17:56] Over time, we have sent out like patches to multiple plugin uh authors as well. That, "Hey, you know, this this like we found the slowness in your plugin that is impacting our customer. 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, right?" So, so we do this. Which means that the site is fast, right? So, so that's the that's the first thing you want to do. You want to make sure that your like your site is fast, right? If your site is fast, it can handle more number [18:26] of requests per unit time than than if not, right? >> Sure. >> The the second thing we do is scaling. We scale dynamically as and when request comes in, we put in more resources, we put in more servers. Uh if the requests do not come in, we bring it down, right? Which means that we can provide like servers capacity to our customers at a price that they would not like that are otherwise like super expensive, right? So, you could always like plan for peak capacity. You could So, generally like the recommendation is if you're running static servers is to plan for like 20% of your capacity, right? [19:06] So, that there's like this 80% headroom, you know? Uh like whatever your peak traffic is, you should your server should be at 20% utilization, right? 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 to run your site all the time, right? [19:33] But with auto scaling, but with getting resources when you need it, automatically means that you can do that at a much like much reasonable price point where it makes sense to you. And this is not something like new, right? Shopify scales like that. All the big companies scales like that. We use this So there's this technology called Kubernetes that we use. Everyone uses that, right? It's It's like not that popular in the WordPress ecosystem, I imagine, where we run like static servers, where we run like, you know, fixed servers. [20:06] But it's like really a really really popular way to scale this thing, right? Everyone uses it. And that's what we do, too. It's not You know, it's not something like weird that we are doing. It's just that if you configure your systems that way, WooCommerce WooCommerce at the end of the day is just another PHP application. And it can scale to whatever you want it to. >> Yeah, so that that kind of reminds me of just, you know, 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 company $1,000 a month [20:39] for this massive uh grid here instead of, you know, just paying as 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 because I'm getting more traffic. >> Yes. So, and if you get traffic, like if you are getting orders, you really don't mind paying for more servers, right? [21:01] Because why would you? You you do need like your shop open, if that makes sense. Right? >> Exactly. Exactly. So, I mean, that I'm making more money, so of course, you know, I need that the server capacity to do that, and that's kind of the a better deal, I would imagine. Um I One of the things I also noticed about Aumet that was kind of cool was that, um you know, when you're updating your your site, especially an e-commerce site, >> [clears throat] >> uh things can break, right? I mean, a plug-in could have an issue. Even WooCommerce itself might have a bug in it. Uh [21:34] >> Yes. >> It's an edge case. Um but your service has a way to repair that through AI as well. How do How does that work? >> Right. So, what we do is, um So, we monitor, we follow like really great coding practices that are industry standard, which means that we monitor like slow requests, we monitor like 500s, we monitor fitters. And as soon as they happen, like AI will go and find out a root cause and fix it, right? So, so that's like that's one. That's at the operational level. [22:09] But before that, we have this concept of staging environments, we have this concept of workspaces, where you modify your code first, update the plug-ins, add custom custom functionality, or 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 like a QA path, where it tests out all the changes, where it makes sure that basics work, before it deploys to production. [22:34] And again, we leverage AI to do that. The we let AI write test cases. Uh 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, right? We are We are also conscious about how many tokens do we burn. We do not like want to throw AI at everything. [23:02] So, we let it run once. We create scripts like as it goes. And then the next time onwards it would run the script, right? If something fails, then AI will go in and do it like manually, right? Like that part of the test. Sometimes an element change, uh positioning change, so the test needs to be updated. Sometimes something actually is failing, and in which case we will detect and we'll block the deployment, right? [23:28] So, that's how we work. The other thing we do is uh there is no update button, like there is no plugin update button in the like, you know, if you go to work like if you're hosting with us, if you go to like a production site, if you open the plugins like menu, there's no update button, right? Because AI will take care of the updates, it will take care of what needs to be updated, what doesn't. [23:52] Sometimes it will ask you if the changes are major, it will ask you to take a look at it as well. But as much as possible, it will try to do it itself, like itself, right? Update button is something I also have like really personal grudges with, if that makes sense. I think that's like not a great experience for merchants. And you know, you know, you maintain your client side, right? You can update, you know how to do this, you know, plugin conflict test, you know how to know when to update and when to wait, right? [24:21] Merchant wouldn't 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 fearful of, you know, clicking that button. Which is not great because an update could have security issue, security patches, it could have performance patches. You do want that. [24:44] And so, another thing we try to do is to make the experience as seamless as possible leveraging AI, leveraging industry best practices, leveraging uh practices of testing, automated testings, so on. >> So, where do you see this maybe in a year? Like, what what would you like to see A Roomi do in in and how do you think maybe AI will help you get there? >> Like I think that AI solves one of the biggest drawback by far of using WooCommerce. [25:18] Which is So, there's this there's this concept, right? That's by a thousand cuts, I think it's called. So, there are like, you know, there's 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, right? I think AI solves that problem. Whether that's a slow database path whether that's uh uh whether that's like a small bug. I think AI really solves it. [25:48] With open source, with open data it solves it very effectively. There is no third-party app that it needs to go to. There's 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 A Roomi will go. We will host like So, we already for a company that started like this year, right? We are already hosting uh one of our customers actually featured on woocommerce.com, right? Like, they are they they are featured on woocommerce.com as a case study on scaling their company, right? They get [26:27] like uh uh you know, they have like billions in revenue. They have uh like thousands of orders per hour. And they are featured as a case study, right? And they are already like on the platform, right? And we feel that this 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. [26:52] Because the benefits are huge, right? It solves this like the biggest problem in WooCommerce. And I think if if it is done right like I think if uh the community adopts it like not just Do me but like with the other host as well. If they really adopt it, if they really you know like mechanize it mechanize it I believe that open source will be like the absolute winner for me I like I think the gains that AI have from open source like or rather the open the gains that open source has from AI comes anything else. And I believe if things are done right in next 5 years [27:36] open source based e-commerce platforms like WooCommerce would absolutely dominate the market. >> Well, that's fascinating. I I I think it's an interesting way to approach this. I mean we you know the traditionally we've just thrown more hardware at it. More memory at it. And having a tool that kind of can detect and and manage it for you and fix all the little things as you said that that um that pop up when you're running WooCommerce that you know if 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. [28:12] Uh so where can people go to learn more about Do me and connect with you online? >> Right. So I am accessible on WordPress Slack. I'm accessible on WooCommerce Slack. People can email me at [email protected]. They can DM me on I 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 I'm accessible, right? [28:42] The other thing people can do is they can add their email on the dorume.ai and we will be sure to reach out. >> Wonderful. We'll make sure to put that in the show notes so people can can check out a Roomy and see what it might be able to do for them. Pranav, I really appreciate your time today and I want to thank everybody who watched and listened to this episode. [29:05] Visit us over at the wpminute.com/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. >> Thank you so much, Eric. >> Thank you., Let’s Debunk the WooCommerce Scaling Myth, WP Minute Podcasts, 01m2g3vy2tbeeed8w4pa861xpx.