Image 1 — How fast can a Shopify app be delisted? I had 20 days to fix mine
Image 2 — How fast can a Shopify app be delisted? I had 20 days to fix mine
Image 3 — How fast can a Shopify app be delisted? I had 20 days to fix mine

How fast can a Shopify app be delisted? I had 20 days to fix mine

Seven months ago, I posted here about my Shopify app failing to find traction.

At the time, Saku had 31 merchants and ran entirely on free infrastructure. I ended that part of the story with a simple conclusion:

>Costs me nothing. So it stays up.

After that, I put the app into maintenance mode. I stopped building features. I still fixed urgent bugs and supported merchants, but otherwise left it alone.

For a while, my conclusion seemed right. Hosting stayed near zero and merchants kept installing.

Then, over the past three months, the obligations started stacking up.

Shopify flagged the app twice. The second email, shown above, arrived on July 2. That gave me 11 days until demotion and 20 days until delisting. A two-week vacation starting then would have meant returning to a demoted app. After three weeks, it could already have been delisted.

The App Store is Saku's main acquisition channel. Missing one action-required email could damage its rankings and eventually cut off new installs.

I fixed the issue before the deadline. Shopify was right to flag it. A high-quality bar protects merchants from broken or abandoned apps.

The warning was only one part of the maintenance burden that had started to surface. During the same period, Mantle, which Saku uses for billing, announced it would wind down. A new Shopify requirement means existing public apps must adopt expiring offline access tokens before January 1, 2027.

Merchants also sent 51 support requests. I resolved all of them.

None of this is unreasonable on its own. Together, it exposed something I had missed: there is no frozen state for a public Shopify app. You can stop developing it. You cannot stop operating it.

That would be manageable if the app funded the work. But despite growing from 31 to 132 merchants without active promotion, Saku has only four paying merchants. At $9 each, that is a 3% paid conversion rate and $36 MRR.

At the same paid conversion, reaching basic MRR milestones would require roughly:

  • $100 MRR: 370 merchants
  • $500 MRR: 1,850 merchants
  • $1,000 MRR: 3,700 merchants

Net growth has averaged about 14 merchants per month. Even if that continued and paid conversion held, reaching $500 MRR would take roughly 10 years.

The problem is not that merchants dislike Saku. It has seven reviews and a 4.9 rating. The first review explains the business-model problem better than I could:

>This app replaces the paid version of Linktree, so I'm saving $10 a month.

That is a good product review and a bad business-model review.

The free plan solves the main job. Saku can attribute purchases, but that value is less immediate than a bundle or upsell app showing added revenue. Most merchants create a page once and have little reason to return, let alone upgrade.

So the app is useful. The current business model is not.

Open sourcing it did not change that equation. I hoped the public code would act as a trust signal. As far as I could tell, it had no effect on merchant adoption or upgrades.

My original conclusion was incomplete: an app can cost almost nothing to host and still become a liability.

For me, that leaves two responsible paths: change the product and business model until it can fund the work, or sunset it properly. Leaving it unchanged would only let that liability grow.

For other solo Shopify app developers: where is that threshold for you? If this were your app, would you change the product or sunset it?

u/BennoDev19 — 20 hours ago
▲ 46 r/tauri

How hard is it to make a Tauri app look native on macOS?

If you want to build a polished macOS app with Tauri, there is one tradeoff worth knowing early: Tauri gives you a webview, not a library of native UI components.

In Tauri, a button, switch or segmented control is still HTML and CSS inside WKWebView. There is no equivalent layer that turns the components in my React interface into native macOS controls (like in React Native), so I needed to build and style that component system myself.

I knew that when I chose Tauri for Abstand, an open-source app and website blocker for macOS. Desktop apps can be quite custom anyway and I was happy to make that tradeoff to keep working with React and Rust.

The above GIF scrolls through the shared components I ended up building: buttons, switches, sliders, toggles, segmented controls, inputs, menus, dialogs and settings rows.

They use accessible web primitives for behavior, but the visual layer is designed specifically for macOS. That meant defining the small details myself:

  • control sizes and spacing
  • light, dark and system colors
  • hover, pressed, focused and disabled states
  • typography and icon sizes
  • animation and interaction feedback

None of those details is especially difficult alone. The work comes from rebuilding the full set and making every component and state feel consistent. At least for me, getting from a functional web interface to something that feels at home on macOS took time.

The upside is that I still get React, CSS and fast UI iteration. I can shape components more freely than native controls allow and the same component system now makes new screens much faster to build.

CSS was enough for most of what you see in the GIF. I only reached for Swift and AppKit when macOS behavior itself became part of the feature, such as window levels, transparent overlays and system font metrics.

Liquid Glass introduced another tradeoff. Making WKWebView transparent over the native glass effect currently requires a private KVC key. That works for a directly distributed, signed and notarized app. An App Store build would need to disable that path and use the fallback instead.

For Abstand, the tradeoff has been worth it. The result can feel native while still giving me the flexibility of the web stack. It just takes deliberate component work to get there.

GitHub: https://github.com/builder-group/abstand

Components: https://github.com/builder-group/abstand/tree/develop/apps/desktop/src/components

If you have tried to make a Tauri app feel native: did you build your own components, use an existing system, or accept a more web-like interface?

u/BennoDev19 — 9 days ago
▲ 12 r/ProductivityApps+1 crossposts

I built a free, open-source Cold Turkey-style blocker for macOS

I used Cold Turkey Blocker for a long time and honestly, big love to it.

I was still using it while building my own blocker because it did the job.

But the longer I used blockers and activity tools, the more I kept thinking about trust.

An app blocker is not a normal productivity app. To work well, it may need to know which app is active, which window is open, which website you are on and when you are trying to bypass a boundary you set earlier.

That is a lot of power to give to software, even when the software is good.

So I built Abstand.

It is a free, open-source macOS app and website blocker. The basic idea is familiar: decide ahead of time what should be unavailable, when the block should run and how strict it should be.

Right now Abstand can:

  • block selected apps and websites
  • allow only selected apps and websites
  • block the whole Mac behind a full-screen overlay
  • run manually or on a schedule
  • use casual, balanced, or strict enforcement
  • optionally record foreground activity on-device
  • expose that activity through a command line tool

That last part is mostly for my own workflow right now. I like RescueTime-style visibility into where my day went, but I wanted the raw data to stay on my Mac and be scriptable. Sometimes I use that local data for a daily summary, but the important part for me is that the app itself is not a black box collecting it.

I think of it as somewhere between Cold Turkey, SelfControl and RescueTime: blocking apps and websites, keeping activity data local and staying open source.

The other product choices are smaller, but mattered to me:

  • macOS-native feeling UI
  • no browser extension required for website blocking
  • open source under AGPL v3

It is also built around "Intentions". Instead of only thinking in blocks or timers, an Intention is a boundary you set while clear-headed. When the time comes, the app holds that boundary so you do not have to negotiate with yourself again.

For now, the only shipped Intention type is Block. Later I would like to explore breaks, wind-down routines and other boundaries if people care about that direction.

It is macOS only and still early, so I would call it a usable beta rather than a polished replacement for every Cold Turkey feature.

Website: https://abstand.app/

GitHub: https://github.com/builder-group/abstand

I am curious how people here think about this category:

For blockers and activity-tracking productivity apps, do you care whether the app is open source and local-first, or is reliability the only thing that really matters?

And if you use Cold Turkey, RescueTime, Freedom, SelfControl, or something similar, what would make you switch?

u/BennoDev19 — 1 month ago

I built a free app and website blocker for setting boundaries before you get distracted

I recently wrapped up the first usable beta of Abstand, an open-source macOS app and website blocker.

I built it because I kept making the same mistake:

I would decide to focus, then the moment I got tired, bored, or stuck waiting on something, I’d “quickly check” X, Reddit, YouTube, or random tabs.

The idea behind Abstand is simple:

The best time to decide what should be blocked is before you are already one click away from a distraction.

In Abstand, those planned boundaries are called Intentions.

An Intention says when it starts, when it ends, and what kind of boundary Abstand should enforce.

Right now the shipped Intention type is Block.

A Block Intention can:

  • block specific apps and websites
  • allow only selected apps/websites
  • block your whole Mac behind a full-screen overlay
  • run on a schedule or manually
  • use casual, balanced, or strict enforcement

Later, I’m exploring other Intention types like screen breaks or adaptive flow sessions. But the current beta is about blocking well.

It is macOS only for now. Data stays local, there is no account, and the app is open source under AGPL v3.

The current beta is free and the version you download now will keep working.

Download: https://abstand.app
GitHub: https://github.com/builder-group/abstand

I’d love feedback:

Does the “Intention” framing make sense, or would you rather a blocker just stay simple and literal?

And what kind of Intentions would you want Abstand to enforce? Deep work, writing, wind-down, screen breaks, digital detox, or something else?

u/BennoDev19 — 2 months ago