Install on ShopifyModulo launched on 29 May 2026. Seven weeks later it ships 200+ native Online Store 2.0 theme sections. The honest headline is not the number: it is that the section count is close to the least useful thing I could tell you about the app, and the speed that produced it broke things a slower schedule would not have broken.
I want to write that down properly, because "200+ in seven weeks" is exactly the kind of claim I would roll my eyes at if someone else posted it.
Why you should distrust the number, starting with mine
There is a whole genre of post right now bragging about output volume. Lines of code per day. Features per sprint. Sections per week. The problem with all of them is the same: volume is the easiest thing to measure and the least correlated with whether the thing is any good. You can generate a very large number of files without generating a single additional reason for anyone to install your app.
So before I defend my number, let me show you how these numbers get built, using a codebase neither of us controls.
Shopify's own Dawn theme is the reference implementation. Open its sections directory and you will find dozens of Liquid files. That is not the number of sections you can use. A large chunk are main-* template scaffolding: main-404, main-reset-password, main-password-footer, main-activate-account. Nobody "adds" those to a page; they are the page. Several more are cart plumbing fragments like cart-notification-button and cart-live-region-text. A couple are JSON group configs. One is apps.liquid, a wrapper Shopify generates around app blocks. What remains, the things a merchant can actually drop onto a homepage and configure, is a fraction of the directory, and it moves with every Dawn release.
Every article that says "Dawn comes with about 15 sections" is doing that subtraction. They just rarely mention that they did it, or that most of the directory never appears in the theme editor at all. Go and count it yourself rather than taking my arithmetic on faith, which is rather the point of this section.
Now apply the same deflation to me. Here is the constraint that matters more than my catalog size: Shopify allows 25 sections per JSON template, and 50 blocks per section within that template. That is a documented platform limit, not a choice I made. Individual themes can be stricter.
So the ceiling on how much of Modulo any one page of your store can use is 25. I ship 200+. A realistic homepage uses maybe eight to twelve. The catalog is a menu, not a payload. Nobody installs 200 sections, and if my app somehow encouraged you to try, that would be a bug in my product thinking rather than a feature.
Which means the number that would actually tell you something is not "how many sections exist." It is "when you went looking for a specific section, was it there, and was it good." I cannot compress that into a headline, and the fact that I cannot is the whole point.
I still lead with 200+, because that is the number merchants search and compare on. I would rather say it out loud and then immediately explain what it does and does not mean than pretend I am above the metric.
What actually broke
Shipping at this rate breaks things in a specific pattern, and it is not the pattern I expected. I assumed the failures would be architectural. They were mostly failures of attention.
A section shipped with a real bug and stayed broken for a week. Product Slider went out on 7 July. It had a defect where it rendered its own built-in example products, the placeholder tiles you see before you configure anything, instead of the products from the collection you actually picked. Hand-picked product lists broke the same way. Any store that added Product Slider in that window got placeholder tiles on a live storefront. I fixed it on 14 July and wrote it up in the changelog with an apology, because a section that silently shows the wrong products is worse than a section that does not exist. If you had shipped that to a real customer, you would not have wanted a vague release note about "stability improvements."
That bug is the honest cost of the schedule. It was not caused by the architecture or by the platform. It was caused by me moving fast enough that the difference between the demo state and the configured state did not get exercised before release.
My own marketing copy could not keep up with my own release rate. Until this week, parts of this website said Modulo had "100+ sections." The app had roughly twice that. I was shipping faster than I was updating the sentences describing what I had shipped, which is a genuinely stupid failure mode, and also a useful signal. When your marketing is stale in the direction of understating the product, the bottleneck has moved somewhere you were not looking.
The public catalog on this site lags the app badly, on purpose. If you click through to the sections index right now and count, you will find a fraction of 200. That is deliberate. A section only gets an indexable page here once I have verified it against the shipped app and have an accurate screenshot of it. Everything else stays out of the index. I would rather have a small honest catalog than a large one full of pages describing features I have not personally re-checked. The gap between "shipped" and "documented well enough to publish" is real, and it is currently large, and closing it is slower than shipping the sections was.
That third one is the part I would push back on if I were reading this post as a skeptic: the app claims 200+, the website can only vouch for a fraction. Both things are true. The catalog is the number I can prove to a stranger. The 200+ is the number I can prove to someone with the app installed.
What merchants asked for versus what I expected
I expected requests for more sections. I built a request pipeline for exactly that: send a screenshot of what you want and I build it, usually inside an hour. People do use it, and that pipeline is a real part of how the count grew.
But the requests that changed the product were not "build me another section." They were, roughly in order:
Findability, not inventory. Once the catalog got past a hundred, the actual complaint became that merchants could not find anything. The answer was not more sections; it was restructuring the catalog into five goal-based groups (capture attention, sell products, build trust, explain and show, convert and site chrome), giving categories fixed positions so they stop reshuffling as new things ship, and keeping the sidebar on screen while you browse. That work added zero to the section count and did more for the product than the sections I shipped around it.
Updates that do not eat their settings. When a section gets fixed, merchants who already have it configured need the fix without rebuilding their page. So updating a section replaces its code and keeps your settings. This sounds obvious. It is the single most load-bearing piece of plumbing in the app, and it exists because shipping fast means shipping fixes, and shipping fixes to a live storefront is only acceptable if it costs the merchant nothing.
Depth on the boring modules, not breadth. The most requested bundling feature was not a new bundle type. It was letting a shopper buying a 3-pack pick a different colour or size for each unit, with the tier discount still applying across whatever mix they choose. That is the "buy 3, pick your colours" experience big brands already have. One feature, deep, on a module that already existed. If you are weighing that module against a dedicated bundle app, I wrote the honest comparison rather than making you guess.
The pattern: merchants do not want a bigger catalog. They want the catalog they already have to be navigable, updatable, and correct. I spent seven weeks learning that the growth metric I was optimising was the one my users cared about least.
About those 7 reviews
Modulo has a 5.0 star rating from 7 reviews.
Seven. I am not going to dress that up. Seven reviews is not social proof, it is seven people, and a 5.0 average across seven ratings is statistically almost meaningless. Any app can hold a perfect rating across single digits. The rating becomes information somewhere north of a few dozen, and Modulo is not there.
I am telling you the denominator because leaving it out is the oldest trick in App Store marketing and I would rather you trust the next number I give you. When there are 70 reviews I will tell you that too, including if the average has dropped, which it probably will, because averages do that when the sample gets real.
Why free, and the honest risk of free
Modulo is free. There is no paid tier today. Stores that install before a paid tier exists are grandfathered onto free permanently, and that is in the terms, not just in a blog post.
The reason is not generosity. The infrastructure cost of running this is small and bounded, and my marginal cost per merchant is close to zero because the expensive part of serving your storefront is Shopify's infrastructure, which you already pay Shopify for. Free is what the cost structure permits at this size.
Here is the risk, stated plainly, because you should factor it in before installing anything from a solo developer.
Free means there is no revenue tied to your account. Nothing about your install obliges me to still be here in two years. There is no support team behind me, no runway to burn through, no acquirer with a contractual duty to your store. If I stop, I stop. The sections are native Liquid theme sections rather than iframes or injected scripts, which limits the blast radius considerably compared to an app that has its hooks in your <head>, but I am not going to pretend that a solo-maintained free app carries the same continuity guarantee as a funded company charging a monthly subscription. It does not. It carries a different trade, and you should make that trade knowingly.
A paid tier may arrive eventually, for features that genuinely cost more to deliver. Modulo is not Built for Shopify certified today. When either of those changes, it goes in the changelog before it goes in the marketing.
How to audit me
Everything above is a claim. Here is how to check it, which is the part most posts like this leave out.
Install it. Open your theme editor and add a section. Then open DevTools on your storefront and count the requests Modulo added. Look in your theme's <head> and see whether I injected anything into it. Run Lighthouse before and after. Check whether the sections are rendered server-side in Liquid or whether there is an iframe hiding in the markup. Add the product carousel and confirm it is reading your real collection. Add stock urgency and confirm the count it shows matches your actual inventory in the admin, because it reads real stock and I have no interest in shipping a fake counter.
If any of that does not hold up, email me at hello@runmodulo.com and I will either fix it or say so publicly in the changelog. That email lands in my inbox with no triage layer in front of it. The reply is from me.
Seven weeks in, the thing I would tell anyone building a Shopify app alone is this: velocity is easy to demonstrate and hard to convert into trust. The 200+ got attention. The apology in the changelog on 14 July did more for the product.
Install on ShopifyIf you want to see what the catalog actually looks like before installing, the verified subset is at sections and blocks, and the pricing situation is spelled out on the pricing page.
