This is the first post -out of many more- talking about how we have faced the development of our first product.

I say it is the first one because we intend to post more articles of this kind, so as to tell you how we’ve done during this adventure and the problems/solutions we have been able to apply in each moment.

The Origin

Let’s start with a little story, one of those that hook you, to shape the events.

When we started Mushdesk, we knew, from the beginning, that we wanted to develop applications for the Shopify ecosystem. Not only was it a matter of curiosity, but also a matter of opportunity. The world was giving us the chance to tell something, so we got down to business creating the first application matrix, to be able to filter all those ideas that we kept noting down as “possible apps”.

One of the merchants’ big issues is that they need better tools in order to internationalise themselves. In that sense, Shopify is developing what they call Shopify Markets, which is, basically, the capacity to configure zones (countries) with different prices, different languages, etc. on your own shop, so that you can offer a more personalised experience to your clients, based on their geographical area. They also have an application for offering a model window to merchants, which enables asking the clients which version of the shop (by country) they want to access. Nevertheless, this is not enough to provide merchants with the necessary technology to carry out their internationalization successfully, since the app is not good enough to make the most of Markets and, basically, stays halfway.

It is at this point that we make our way in with ORBE, the geolocation app for Shopify. Why ORBE? Because merchants need the best technology so as to carry out their internationalisation. ORBE is an app which allows you to geolocalise the client in your shop (even if the client accesses the store with a VPN), and to offer them the best experience with a non-intrusive modal window, totally personalisable and compatible with Shopify Markets.

We get going

We already have the idea, the unresolved necessity and the market opportunity. We begin with the development. I have to say that, previously, we had never developed an app for Shopify, but we were inside the ecosystem as developers for third parties on a personalisation level and theme development, mainly. So we started:

• The development started on the first week of February, more concretely, on the 7th of February of 2022.
• The technological stack was simple:
• Backend: PHP with direct integrations to the API REST and API on Shopify’s GraphQL. We did it this way because it was the language that we had more experience with. 
• Frontend: since we wanted to implement a modal window and we needed to use JavaScript one way or another, we opted to do it with JavaScript Vanilla, based on a matter of efficiency and compatibility with any theme and navigator.
• In regards to timing, we worked part-time while we still developed for clients.

First bumps in the road

By the end of February, we had an obstacle in our path:

1. We couldn’t keep up with developments for clients and developing our product at the same time. Since we are two people, we had to make the decision to split the work, one of us dedicating his full time to the product, and the other one dedicating it to clients. This way, we wouldn’t die trying to do both things.

1. After achieving an attractive Figma and building part of the base code, we found out that Shopify just launched what they call Theme App Extensions. Basically, it is an application system (section-format) for Shopify that you can configure easily, which they take care of afterwards, rendering the front/back of the CRUD of your app. In other words, you can tell it that you want a form with 10 options, and Shopify generates it all automatically, native-like, inside their back office. Obviously, this made us dedicate the last week of the month to studying how we could take advantage of Shopify’s potential, regardless of the fact that we had to throw away part of the project. It may look like a step backwards, but actually, it was such a big step forward.

1. Shopify already has too many different technologies for creating an application. This is a little odd, and as a developer, baffles me a little. But Shopify seems to consider it positive to maintain the legacy of its products. You have API REST, API GraphQL, API ADMIN, a JS library for your app’s back office, Liquid as the language for the front, but only theme app extensions, webhooks, and developing tools that exclusively work with specific apps. And, finally, a CSS framework that, despite them assuring it works with JavaScript Vanilla, is not as advantageous as with ReactJS. All in all, even though the documentation is there, you have no idea about what you have to use until you have dived into the process completely. I would have liked to find something a little bit more guided.

1. Forget about thinking of a simple solution for the communication between the back-office and front-end. They are too closed. If you create a back-office with Python -to set an example- and you want to use data that you store in a database inside the store’s product card -to set another example- give yourself up for dead. You will have to make something up with meta fields through the API, from Python, and then read it with Liquid or with some other JavaScript from the front of the store.

The functioning

Let’s make an aside before we go on.

It sounds strange, but we are here to disembowel the whole process and I’m going to explain how curious the functioning of such an -apparently- simple app as ORBE is in Shopify. It was at this moment, approximately in March, when we discovered how to build the application, so we put this together.

ORBE is based on 3 legs:

• App Embed (the back-office)
• Theme App Extension (the modal that can be seen on the front)
• Geolocation API and Webhooks

App Embed

This is the Back-office of the app. Here, Shopify says you are free to work however you want because what they do is call your application through an iframe embedded in their pannel. It is a little bit like the sword of Damocles at the beginning. At first, you get excited and think positively because you can use any framework, front or backend since it is a web application that is afterwards embedded inside Shopify. But later, you will realise that, so as to take every advantage of it, the ideal thing to do is to use ReactJS, because the API REST that they have is not enough, and you will have to use other APIs, even JavaScript’s library, called App Bridge, which allows you to connect the iframe to log in. This login is via Oauth and here we come again, you can log in with the front end and the back end equally, although you will have to end up using their App Bridge because it is necessary for publishing on the App Store.

Theme App Extension

This is the modal window which allows the client that is visiting the store to interact and change their internationalisation experience. This window can be personalised through Shopify’s visual editor in a very easy way with a preview. Apart from the visual modal window, this app extension contains the JavaScript that requests the geolocation API and controls the language cookies to be able to redirect the client automatically to the country that best adapts to their location.

Geolocation API and Webhooks

We need a good, fast geolocation system. We do this with our own API, which we call from the JS of the modal script and it is the one that enables us to obtain the client’s geolocation as well as additional information that we can save in the database through the back-office, and which we have no way of sending to the front end.

As for Webhooks, which are SO important to implement, there are two types: obligatory to comply with the GDPR and optional to control events inside the store or the application. It is curious that the only way of controlling the installation state in your own database is through an optional Webhook that you receive when the user uninstalls the application. That is to say, it is, by no means, optional. But you will realise this when you get rejected during the revision process (which I will explain our experience with now).

Revision process

On the 25th of March, we uploaded the app to the App Store through the form that sends you to the queue for the revision of the app. The process itself is not too complex, as long as you meet the criteria they detail in the documentation. There are two parts to get successfully validated so the app can be available in the App Store: the functional part and the logical business part.

The functional part is basically whether the app works properly, that is to say, it can be installed, it can be accessed with Oauth, it can be uninstalled, etc. This process is checked by a bot with a series of tests done to the app. I have to say that, in our case, the first time we uploaded the app, we had it withdrawn within the first hour, because we needed to implement the optional webhook (again, nothing optional in it) that allows us to know if a shop has uninstalled the application to be able to carry out the process of reinstallation properly.

The logical business part is revised by someone once you have passed the bot test. I also have to say that we had tried twice with the bot before we reached the human checking because Shopify simply doesn’t have an area to try processes such as installation and uninstallation in a controlled way, as if you were a merchant. This being said, once we got to the human revision, it was all done via email. They try the app and see if everything is correct, if the payments work, etc.

It was at this point that we got rejected. We had different inspectors for one month. We tried like 6 or 7 times and each time the errors kept downsizing. On many occasions, those issues were very simple. For example, we forgot to add a “/” at the end of a URL or we wrote nothing on the price box of the tier free when we should have written “0”. I won’t lie to you, there were mistakes that they found -since they play beta testers- that were highly beneficial for us to be able to improve the application.

In short, they may be too scrupulous during the revision, but once you see the final result, you can see the quality of the app has improved too. Actually, the revision process as such was two months long, and one more for the constant testing process. Meaning that we started in February and, finally, in April, we launched the application.

Conclusions

We have launched our first application, ORBE, within -almost- three months, working on the App Store. We are preparing the next version and growing up on users and positions in the App Store. In the next articles, we will tell you how we are developing the product and the numbers.