Block Cart

When I signed up for Shopify, I expected leverage. What I felt instead was work... not the kind that grows a business, but the kind that feels like managing another job.

From day one, the UI felt scattered. Products lived in one section of the nav, pages in another, themes somewhere else, and apps in their own layer entirely. If someone asked me how to use Shopify, I wouldn’t know where to start. I’d probably just log in and do it for them.

The moment I realized I genuinely disliked it was when I started configuring pages. The builder felt clunky and fragile, like a modernized version of something from 2010. It worked, but it didn’t feel cohesive. It felt like assembling parts rather than shaping a system.

The deeper issue was the mental model. Shopify starts as a base platform, and then you install apps to unlock real functionality. Digital delivery? App. Subscriptions? App. Advanced workflows? Probably another app. The more serious you get, the more fragmented the stack becomes.

Adding products was fine. There’s nothing fundamentally broken about it. But I would never want to manage products in Shopify from my phone. In Notion, I can update products on my phone without even thinking about it. That difference is everything when your brain thinks in structured databases.

The breaking point came when I sent someone my store link and got a 404. Desktop worked. Mobile didn’t. Everything was configured correctly. That was enough. I cancelled the account. To be fair, I was already building an alternative. Shopify was me studying the terrain. The error just made the decision easy.

The first store I launched with my alternative was my wife’s. It was fully powered by Notion. Initially, I treated the Notion API like a database and hit it directly. That worked until performance didn’t. So I built a Postgres buffer layer and added Redis product caching to eliminate live Notion API calls on every page load. Now Notion is the source of truth, but performance is stable.

Shipping was the first real failure. I hadn’t funded my ShipEngine account correctly. A customer retried checkout several times, Stripe processed multiple attempts, and we ended up refunding and eating fees. That mistake forced me to think like a real operator instead of just a builder.

What surprised me most was how satisfying it felt to update Notion and see the live site update instantly. The backend was my workspace. No syncing across apps. No duplicate entries. No fragmentation. Just update and go live.

Today, I can launch a white-label store in under ten minutes once content is ready. Plug in the Notion databases, configure pages, and publish. For my workflow, that’s dramatically faster than Shopify.

There are tradeoffs. There’s no coupon engine yet. There’s no massive app ecosystem. There’s no merchant-of-record layer for handling global VAT. Shopify is objectively better for enterprise scale, global compliance, and theme customization.

But Shopify is built for scale-first operators. What I built is built for speed-first operators; people who already run their business in Notion and want their storefront to feel like an extension of that system, not a separate universe.

That’s ultimately what became Block Cart: a Notion-native commerce engine I now use to run digital, physical, subscription, and event sales across multiple stores. It’s not trying to replace Shopify at enterprise scale. It’s built for a different kind of operator.

I’ve been deep in subscription support this week, and it’s been a good reminder that “subscriptions” are never just a pricing toggle.

It touches everything. Database models, product sync, checkout logic, webhooks, access control, customer dashboards, emails, and even how you validate carts so users don’t end up in broken states.

What’s made this work especially satisfying is that all of this data lives where the user already operates. Subscription state, access, and lifecycle aren’t hidden behind an external admin panel. They’re visible and understandable directly inside Notion.

Part of why I’m pushing this now is that I think subscriptions might reduce the commitment hurdle for early users. Building or switching an entire store is a big ask. Subscriptions and event-level commerce feel like a way to let people start smaller and grow into the platform.

It’s a lot of work for something users will experience as “this just works,” but that’s kind of the point.

I’m building a Notion-native ecommerce platform, and I’m starting to understand why getting the first paying users often takes longer than expected.

I’ve had a number of conversations with people who clearly get the product. They ask good questions, understand the value, and some have even commented on the quality and polish. One early user told me the UI reminded them of MacPaw and that they didn’t need onboarding cues.

That’s when it clicked that this probably isn’t a product-quality problem.

What seems harder is the decision itself. Asking someone to build out an entire store, or switch from an existing setup, is a real commitment. Even when the product makes sense, there’s inertia and perceived risk in starting or migrating.

Right now it feels less like a marketing problem and more like a timing and trust problem. People may need the right moment, not more persuasion.

So for now, I’m not trying to force it. I’m going to keep building. Over the next couple of months, I plan to launch two stores on the platform and ship subscriptions and event-level commerce along the way.

Still sitting with this stage and curious how others recognized it when they were in it.