Hello Shopify Team,
I’m Subash from Digital Product Labs.
We recently submitted our app for the Built for Shopify badge and received valuable feedback, which we are actively working on to align with Shopify’s standards.
One of the points raised was to make the onboarding process optional. However, since our app is a marketplace app, the onboarding steps are critical for the core functionality and user experience. Without completing these steps, merchants won’t be able to properly use the app, which could lead to confusion or failure in setup.
Given this, making the onboarding process optional isn’t feasible for our use case. We’d really appreciate your guidance on how best to communicate this to the Review team or if there’s a recommended way to present this scenario within the submission so it can be better understood.
1 Like
Just sharing my experience,
From a merchant’s perspective, having skippable onboarding is helpful since it lets them dive in instead of following all the steps upfront.
In our app, we originally had a step-by-step onboarding process (like in the attached screenshot), where users had to complete each step one by one. But for BFS, we had to remove that and instead introduced a “pending state” on key pages.
For example, our first step required users to upload videos. After removing the onboarding flow, we added a persistent banner on all pages, prompting them to upload videos. This banner wasn’t skippable but allowed them to explore the app freely. Once they completed that step, the banner updated to the next step and remained visible across all pages. This ensured that merchants weren’t forced to complete onboarding immediately but still had clear guidance, reminding them that setup wasn’t fully complete until all steps were done.
Could you please let me know in detail why your previous step-by-step onboarding was not accepted? I see that we may dismiss it by click on to the More action icon? So it seems meet all the requirements?
We had to remove the onboarding UI for multiple reasons, mainly related to performance and web vitals.
The main issue was that if we allow users to dismiss the onboarding, we need to store that state in the database. Then, every time a user loads the page, we have to check whether they’ve dismissed it or not. This check requires a database call.
Now, doing this check server-side would let us render the UI with the correct state before sending it to the user, which avoids layout shifts. But we chose not to do SSR at all. Our app is fully served from a CDN, and all dynamic data is fetched through REST API calls after the initial page load.
The reason is performance: our servers are in the US, and if someone from Asia or other distant regions visits the site, a DB call during SSR would delay the entire page load (hence large LCP score). By avoiding SSR and using only static assets on the CDN, the initial page loads extremely fast regardless of where the user is. We then populate the data with API calls on the client side. This gives us much better LCP scores because users see the full UI instantly without waiting on server-side logic.
But, fetching the onboarding state client-side came with its own problem: CLS . If the user had dismissed the onboarding, we had to show a loader in that area while the REST call was in progress, and later remove it. That caused huge layout shifts. On the other hand, if the user had not dismissed it, and the onboarding UI appeared a couple of seconds after page load, it became the LCP element, which made our LCP score worse.
To avoid both issues, high LCP and layout shift, we decided to remove the onboarding UI entirely.
