Apps erlauben Shopify Benutzern, ihren Shopify Online-Shop um weitere Funktionen zu erweitern. Es gibt tausende Apps für verschiedene Bereiche eines Webshops wie etwa Designelemente für das Frontend oder Arbeitserleichterungen, -automatisierungen und Integrationen zu anderer Software im Backend.

Wir haben ausgiebige Erfahrung in der Entwicklung von Shopify Apps – sowohl durch unsere 

 im Shopify App Store, als auch durch Projekte mit unseren Kunden. In diesem Blogartikel teilen wir unsere Erfahrung und beschäftigen wir uns damit, was es bedeutet eine Shopify App zu entwickeln und welche Aufwände und Kosten dabei auf Sie zukommen.


Für andere Shopsystem ist die Bezeichnung “Plugin” gebräuchlicher als der Begriff einer “App”. Shopify Apps unterscheiden sich aber nicht nur ihren Namen von Plugins. Im Gegensatz zu Plugins werden Shopify Apps nicht in einem einzelnen Webshop fest installiert. Stattdessen dient die App als externer Cloud-Service, der über eine Programmierschnittstelle (API) mit Shopify kommuniziert.

Das klingt zunächst einmal sehr ähnlich, hat in der Praxis aber erhebliche Auswirkungen auf die grundsätzliche Funktionsweise einer App. Im Gegensatz zu einem Plugin wird eine App beim App-Anbieter gehostet und derselbe (Cloud-)Server bedient i. d. R. alle Nutzer der App. So kann es keine Probleme aufgrund von verschiedenen Versionsnummern oder Update-Prozesse geben.

Shopify Apps  können nur über den Shopify App Store angeboten werden, es gibt keine alternativen Vertriebsmöglichkeiten. Für die Zulassung zu App Store ist ein Review durch Shopify nötig, in dem die App aus Anwendersicht getestet wird. Die einzige Ausnahme von dieser Regel bieten Custom Apps, die nur Zugriff auf einen einzigen Shopify Store erhalten (dazu weiter unten mehr).

Auf der anderen Seite muss eine App permanent vom App-Anbieter gewartet werden. Das bedeutet insbesondere auf die regelmäßigen Updates der Shopify-Plattform mit eigenen Updates der App zu reagieren. Außerdem muss der App-Anbieter sicherstellen, dass seine App mit sehr hohen Lastspitzen der Shops seiner Kunden klarkommt.

Sollte ein App-Anbieter den Betrieb einstellen oder es versäumen, Änderungen umzusetzen, ist die App auf einen Schlag für sämtliche Kunden nicht mehr verfügbar. D. h. es gibt in diesem Szenario auch keine Alternative wie etwa den Weiterbetrieb einer alten Version wie es oft bei Plugins der Fall ist.

App-Anbieter verarbeiten die Daten ihrer Kunden und besitzen auch sehr sicherheitskritische Informationen, wie etwa Tokens, mit denen ein Shop in gewissen Rahmen ferngesteuert werden kann. Da App-Anbieter die Tokens aller ihrer Kunden meist zentral speichern, sind entsprechende Sicherheitsmaßnahmen und laufende Updates diesbezüglich unabdingbar.

Der Fakt, dass die Entwicklung einer Shopify App also nie wirklich abgeschlossen ist und eine permanente Weiterarbeit und Wartung erforderlich ist, zwingt App Anbieter dazu monatliche Abonnements anstatt Einzelkäufe als Vertriebsform zu wählen. Nur so können sie – eine entsprechend große Kundenbasis vorausgesetzt – die laufend anfallenden Aufwände der App finanzieren.



Shopify stellt für die Erstellung einer App zwei Betriebsmodi zur Verfügung: Custom Apps und Public Apps. Nur Public Apps können im Shopify App Store angeboten werden. 

 sind für den Betrieb mit einem einzelnen Shopify Online Shop vorgesehen. In der Regel geht es hierbei um individuelle, von einer Agentur oder einem Shopify Freelancer erstellte Funktionen. Oft sind individuelle Schnittstellen zu ERP-Systemen oder anderen Datenpunkten, die keine Shopify App für den App Store bereitstellen. Auch individuelle Entwicklungsprojekte wie etwa ein aufwendiger Bundle-Builder oder ein detailliertes Dashboard für Kunden sind übliche Beispiele für eine Custom App.

Custom Apps funktionieren technisch ähnlich wie Public Apps. Sie können sich optional ebenfalls über einen recht aufwendigen oAuth Prozess gegenüber dem Webshop und der Shopify Plattform authentifizieren und sehr viele und komplexe Daten speichern und verarbeiten.

Sie können aber auch den oAuth Prozess umgehen, indem sie mit einem einmalig generierten Token arbeiten. Das erlaubt eine erhebliche Verkürzung des Authentifizierungsprozess.

Da eine Custom App für lediglich einen Shop funktioniert, kann sie 

 Bis zum Januar 2022 gab es neben “Custom Apps” noch “Private Apps”, denen ein Betrieb ohne oAuth vorbehalten war. Shopify ermöglicht seit Februar 2022 nicht mehr die Entwicklung neuer Private Apps, dafür sind Custom Apps nun auch ohne oAuth erstellbar.

 funktionieren technisch sehr ähnlich wie Custom Apps, dürfen aber Zugriff auf beliebig viele Shopify Onlineshops erhalten. Dies führt zu Entwicklungsaufwänden, die bei Public Apps erheblich höher sind als bei Custom Apps.

Der Hintergrund ist, dass Public Apps ggf. rund um die Uhr tausende von Shopify Händlern technisch unterstützen müssen, was wesentlich höhere Anforderungen an Skalierbarkeit, Fehlerfreiheit und Sicherheit darstellt. Im Vergleich müssen Custom Apps mit nur einem Händler lediglich ein Bruchteil dieser Anforderungen erfüllen.

Im Gegenzug dürfen Public Apps auch im Shopify App Store angeboten werden. Vor der Einreichung müssen sie einen Review-Prozess von Shopify durchlaufen und werden dabei von Shopify aus Anwendersicht getestet.

Die Entwicklung einer App für Shopify ist in den meisten Fällen deutlich komplexer als die Entwicklung eines Plugins für andere Shopsysteme.

Das liegt daran, dass Shopify Apps cloudbasierte SaaS-Anwendungen sind, die regelmäßig gewartet werden und für tausende Händler rund um die Uhr zur Verfügung stehen müssen.

Auch der Authentifizierungsprozess gegenüber Shopify sowie die Integration von Datenbanken für verschiedene Zwecke wie das Speichern sicherheitskritischer Daten fallen in dieser Form bei Plugins für andere Shopsysteme nur äußerst selten an.

Und auch bei Custom App und Private App unterscheiden sich die Entwicklungsprozesse deutlich, da diese für verschiedene Einsatzszenarien entwickelt werden.

Nachfolgend beschreiben wir den Prozess, den wir bei Especial bei der Entwicklung von Apps befolgen. Wir werden auch insbesondere auf die jeweiligen Mehraufwände für Public Apps eingehen.

Sowohl Custom Apps als auch Public Apps erfordern eine entsprechende Planungsphase, in der die Anforderungen erfasst und in einen entsprechenden Lösungsansatz überführt werden. Hier findet auch meist die Erstellung eines UX Designs statt, bei der Designer mit Wireframes das zukünftige User-Interface sowie die Abläufe innerhalb der App skizzieren.

Public Apps erzeugen bei der Planung deutlich Mehraufwand. Neben den funktionalen Anforderungen müssen bei Public Apps auch Themen beachtet werden, die im Zusammenhang mit dem Multi-Benutzer-System stehen. Dazu zählen beispielsweise Login- (Startbildschirm), Registrierungs- und Zahlungsabwicklung.

Auch die Unterstützung von verschiedenen Themes und die Wechselwirkungen mit anderen Apps müssen beachtet werden, da Public Apps von jedem Shopify User installiert werden können. Daher steht die zukünftige Anwendungsumgebung im Gegensatz zur Custom App nicht eindeutig fest.

Im Visual Design Prozessschritt werden die Wireframes aus der Planung in vollumfängliche Designdateien und Prototypen für Desktop, Tablet und Smartphone übersetzt.

Wenn Sie möchten, dass Ihre App möglichst nativ aussieht, können Sie hier auch einfach 

, die Grundlage für das Shopify eigene Admin Design, zurückgreifen.

 Da Public Apps im App Store gelistet werden, sind zusätzliche Assets wie z. B. ein App-Icon und Werbegrafiken nötig. Außerdem benötigt eine App ein stärkeres Branding, wenn Sie im Apps Store herausstechen soll. D. h. im Design Prozess muss stärker auf ein einheitliches und ästhetisches Design gesetzt werden. Dies ist entgegengesetzt zu dem Fall einer Custom App, da diese meist mit einem sehr funktionalen Design ohne jegliches Branding auskommt.

Nachdem Planungs- und Designphasen abgeschlossen sind, kann mit der Programmierung der Shopify App begonnen werden. Wie hoch hierbei die Aufwände sind, kommt sehr auf die individuelle App und ihren Funktionsumfang an. Gewisse Funktionalitäten wie Registrierung und Authentifizierung, die für Shopify Apps stets nötig sind, fallen jedoch immer und abhängig vom Komplexitätsgrad und Anforderungskatalog der App an.

Das führt dazu, dass der Anteil des Aufwands für sehr einfache Apps oft hauptsächlich in der obligatorischen Technik für Shopify Apps anfällt. Für komplexe Apps hingegen stellt die Kernfunktionalität den größten Teil der Arbeit dar.

Für Public Apps ergeben sich hohe Mehraufwände in der Programmierung. Kernfunktionen müssen beispielsweise so strukturiert werden, dass sie mit möglichst vielen Shopify Shops funktionieren. Dazu zählen die diversen Themes und Kompatibilität mit anderen Apps.

Auch die Softwarearchitektur muss für Public Apps anders gedacht werden: Es müssen auch Datenspeicher und komplexe, automatisierte Registrierungs-, Zahlungs- und Authentifizierungsverfahren für eine größere Nutzerbasis implementiert werden. Im Falle einer Custom App können diese im Vergleich sehr einfach ausfallen, da sie eben nur für einen Nutzer/Store funktionieren muss oder sogar gar kein oAuth als Authentifizierungsprozess implementieren müssen.

Die Einbettung verschiedener Zahlungsmodelle sind ebenfalls Public Apps vorbehalten und können relativ viel Arbeit erfordern.

Schritt 4: Testing & QA (Qualitätssicherung)

Testing & QA finden größtenteils während der Programmierung statt. Dennoch ist es uns wichtig, die Unterschiede zwischen einer Custom und einer Public App in einem eigenen Abschnitt ausreichend für Testing & QA zu beleuchten.

Im Testing & QA werden automatisierte und manuelle Tests der App durchgeführt, um etwaige Probleme aufzudecken, bevor Sie im Live Betrieb auftreten. Üblicherweise werden Testszenarios für die wichtigsten Funktionen einer App erstellt und anschließend die Funktionsweise von QA Engineers und automatisierten Tests für verschiedene Anwendungsszenarien überprüft.

Testing & QA sind ein sehr weites Feld innerhalb der Softwareentwicklung. Es ist möglich, äußerst viele Ressourcen in das Testing selbst kleinster Apps zu investieren. Daher ist es wichtig, im Projekt das richtige Maß zu finden – man spricht dabei oft von der “Testabdeckung”, die in Prozent angegeben wird.


 Apps für den Shopify App Store müssen deutlich intensiver und vollumfänglicher als Custom Apps getestet werden. Nicht nur gibt es deutlich mehr Testszenarios aufgrund verschiedener Konfigurationen der verschiedenen Shopify Stores. Es gibt auch deutlich mehr Wechselwirkungen mit verschiedenen Themes und Apps, die beachtet werden müssen.

Zudem kann man sich bei einer im Shopify App Store veröffentlichten App schlichtweg weniger Fehler leisten, da kein direkter, beidseitiger Kommunikationskanal mit den Nutzern besteht. Über alle Shops hinweg gesehen muss eine App ggf. sehr hohe Lastspitzen von zehntausenden bis Millionen von gleichzeitigen Shopbesuchern handhaben. Dies erfordert eine entsprechend ausgeklügelte Infrastruktur.

Dies alles führt zu deutlich längeren und intensiveren Tests & QA Prozessen.

Schritt 5: Shopify Listing & Reviewprozess (nur Public Apps)

Nachdem die Arbeiten an der ersten Version der App abgeschlossen wurden, kann sie im Falle einer Custom App direkt in einem einzelnen Shopify Store installiert werden.

, die auf dem Shopify App Marketplace angeboten werden sollen, ist der Ablauf anders:

Zuerst muss ein Listing, mit Bildern, Screenshots und Werbetexten, für den App Store erstellt werden – ggf. in verschiedenen Sprachen. Zudem empfiehlt es sich, Bedienungsanleitungen und ein Supportcenter für die zukünftigen Nutzer zu erstellen. App Anbieter bieten Interessenten auch oft Werbevideos ihrer Shopify App an.

Ist das Listing einsatzbereit, muss die Public App an für ein Review übermittelt werden. Dabei testet eine Mitarbeiterin von Shopify die App aus der Perspektive eines Anwenders. Das heißt, die Review-Mitarbeiterin bei Shopify wird den Code und entsprechende Sicherheitssysteme nicht überprüfen, sondern bewertet die App ausschließlich aus der Sicht eines zukünftigen Users.

Das führt dazu, dass App Reviewerinnen auch oft Verbesserungsvorschläge für die App haben und auf die Implementierung dieser Verbesserungsvorschläge bestehen, bevor die App für den App Store freigegeben wird.

Dies führt zu einem geänderten Anforderungskatalog und es müssen neue Designs erstellt werden sowie der Programmierungs- und Testingprozess erneut für die neuen Features durchlaufen werden.

Aus unserer Erfahrung können die Feature-Wünsche der App Reviewer oft recht umfangreich sein. Wir wurden beispielsweise schon dazu aufgefordert eine komplette Analytics & Reporting Komponente inkl. CSV-Export von Daten in die App zu integrieren, obwohl dieses Feature nie von uns geplant war.

Ist die App einmal in Betrieb, startet die Phase der permanenten Wartung und Supports. Im Fall von Custom Apps geht es meist nur um Änderungen am Code, wenn Shopify Änderungen an ihrer Plattform und APIs vornehmen. Dies geschieht sehr häufig und Shopify gibt Entwicklern in der Regel 12 Monate Zeit neue Anforderungen umzusetzen. Je nach technischem Aufbau der App können diese technischen Änderungen an der Shopify App innerhalb weniger Stunden erledigt sein oder benötigen mehrere Tage oder gar Wochen Entwicklungsaufwand.

 Im Fall von Public Apps müssen nicht nur technische Updates vorgenommen werden, die im Fall von Public Apps oft auch deutlich komplexer umzusetzen sind. Public Apps benötigen stetigen Support durch den App-Anbieter, da es trotz intensiven Testings sehr üblich ist, dass eine App Probleme oder Funktionseinschränkungen in bestimmten Shopify Shops hat. Dies ist meistens durch das individuelle Setup eines Shopify Händlers begründet. Beispielsweise können diese unzählige andere Apps installiert haben, die sich negativ auswirken, indem sie beispielsweise bestimmte Funktionen der App überschreiben. Oder sie nutzen ein sehr exotisches Theme, für das die App entsprechend angepasst werden muss.

Regelmäßig gibt es jedoch auch Support-Anfragen von Nutzern, die eine Fehlfunktion der App nur vermuten, in der Praxis jedoch andere Faktoren wie eine Fehlbedienung oder falsche Einstellungen des Shops das Problem verursachen. Hier entsteht dann dennoch Support-Aufwand, um das Problem zu klären.

Wie Sie sehen, hängen die Kosten einer App neben der Kernfunktionalität vor allem davon ab, ob es sich um eine Custom App für einen Shopify User oder um eine Public App für den App Store handelt.

Um Ihnen eine ungefähre Vorstellung von dem Kostenunterschied zwischen Public und Custom App zu vermitteln, haben wir hier ein Beispiel vorbereitet.

Die App in diesem Beispiel hat eine relative einfache Kernfunktion. Z. B. das Einblenden eines dynamischen Popups im Shop der App-User.


In der Summe entstehen in unserem Beispiel etwa 

 für eine Custom App, während die Public App für den gleichen Kernfunktionsumfang etwa 

 bedeutet. Bei einem Stundensatz von 100 € ergeben sich hierbei 

von etwa 8.000 € für die Custom App und etwa 24.000 € für die Public App

Überdies ist der Support und die Wartung für die Custom App auf jährlicher Basis mit 12 Tagen deutlich geringer als 60 Tage bei der Public App. Die Werte für Support & Wartung basieren auf unserer eigenen Erfahrung von Apps mit mehreren hunderten Usern im Shopify App Store. Hierbei entfallen viele Stunden auf Support-Arbeiten, die meistens nicht von Entwicklern, sondern Support-Mitarbeitern mit deutlich geringeren Stundensatz übernommen werden.

Die Entwicklung einer Shopify App ist kein simples Unterfangen. Sie sollten sich stets bewusst sein, dass Sie eine SaaS-Software entwickeln, die im Fall von Shopify auch gut skalieren muss. Dies bedeutet, dass der Entwicklungsprozess sehr professionell ablaufen sollte, um sinnvolle Ergebnisse zu erzielen.

Die Entscheidung, ob Sie eine Custom App oder eine Public App benötigen, ergibt sich von allein aus der Frage, ob die App allen Shopify Usern oder nur einem einzigen zur Verfügung stehen soll. Die Kosten resultieren ebenfalls aus dieser Entscheidung.

Planen Sie mit einer Beta-Phase, um die App unter Live-Bedingungen zu testen und zu verbessern. Sie können im Fall von Shopify Apps ihr Listing auf “unsichtbar stellen”. Dadurch ist die App nur für Personen installierbar, die von Ihnen den Link erhalten.

Oft ist es auch ein guter Ansatz, ein neues Konzept erst als Custom App zu testen und bei Erfolg dann in eine Public App umzuwandeln. In der Summe ergibt sich dadurch ein leicht höherer Aufwand als wenn Sie direkt eine Public App entwickeln, sie können aber ihre App-Idee zunächst validieren.

Überstürzten Sie nicht die Planungs- und Designphase. Das Auslassen oder starke Verkürzen bestimmter Prozessschritte mag anfangs für ein subjektiv gutes Gefühl sorgen, da subjektiv schnell Fortschritte erzielt werden. Tatsächlich bauen Sie jedoch 

 auf, deren Lösung Sie später erheblich mehr Zeit und Geld kosten wird.

Die Konkurrenz auf dem Shopify App Store ist inzwischen sehr hart. Denken Sie auch über etwaige Marketing-Möglichkeiten nach und beschäftigen Sie sich mit App Store SEO, um ihre Sichtbarkeit zu erhöhen. Ihre App sollte auch eindeutige USPs besitzen, wenn Sie sich in Konkurrenz mit großen Apps begeben möchten.

Shopify Apps allow Shopify merchants to add more functionality to their Shopify online shop. There are thousands of apps, each one providing features to different parts of a web shop. This includes design elements for the front-end side or automation tasks and integrations with other software on the back-end side.

We have extensive experience in developing Shopify apps – both through our 

in the Shopify App Store and through projects with our customers. In this blog post, we will share our vast experiences and deal with what it means to develop a Shopify app. We also want to make a concise effort to include the costs and how the process will look when you start an app development journey in an effort to help you understand how to build Shopify apps.

For other shop systems, the term “plugin” is more common than the term “app”. Shopify's apps don't just differ from plugins in their names. Unlike plugins, Shopify apps are not permanently installed in a single web shop. Instead, the app serves as an external cloud service that communicates with Shopify via an application programming interface (API).

This sounds very similar to a plugin at first, but has a significant impact on the basic functionality of an app in practice. In contrast to a plugin, an app is hosted by the app provider and the same (cloud) server usually serves all users of the app. One benefit of this approach is that troubles because of CMS updates usually can't come up.

Shopify Apps can only be offered through the Shopify App Store, there are no alternative distribution options. A review by Shopify is required for admission to the App Store. During the review, the app is tested from the user's point of view. The only exception to this rule are custom apps, which only get access to a single Shopify store. But wait, we are getting ahead of ourselves, there will be more on that below.

An app must be constantly maintained by the app provider. This means that they will need to react to the regular updates of the Shopify platform with their own app updates. In addition, the app provider must ensure that its app can cope with very high peak loading periods in its users' shops.

If an app provider shuts down operations or fails to implement changes, the app suddenly becomes unavailable to all customers. There is no alternatives for this scenario, such as continuing to use an old version, as it is often the case with plugins.

App providers process their customers' data and also have very security-critical information, such as tokens, with which a shop can be remotely controlled to a certain extent. Since app providers usually store the tokens of all their customers centrally, appropriate security measures and ongoing updates are essential in this regard.

The fact that the development of a Shopify app is never really finished and that constant work and maintenance is required forces app providers to choose monthly subscriptions instead of individual purchases as a form of distribution. This is the only way they can – going on the premise that there is a correspondingly large customer base – finance the ongoing expenses of the app

Shopify provides two modes of operation for creating an app: Custom Apps and Public Apps. Only public apps can be offered in the Shopify App Store.



are designed to work with a single Shopify online store. Typically, these are custom features created by an agency or a Shopify freelancer. Often there are individual interfaces to ERP (Enterprise Resource Planning) systems or other data points that do not provide a Shopify app for the app store. Individual development projects such as a complex bundle builder or a detailed dashboard for customers are also common examples of a custom app.

Technically, custom apps work in a similar way to public apps. They can optionally authenticate to the web shop and the Shopify platform using a fairly complex oAuth process and save and process a lot of complex data.

But Custom Apps can also bypass the oAuth process by working with a one-time generated token. This allows to reduce the work for implementing an authentication process by a lot.

Since custom apps only work for one shop, they can not be offered in the Shopify App Store .

Until January 2022, in addition to “Custom Apps”, there were also a third app type: “Private Apps”. Private Apps were able to implement authentication without oAuth. Shopify no longer allows the development of new private apps since February 2022, but custom apps can now also operate without oAuth.

work in the same way as custom apps, but may have access to any number of Shopify online shops. This leads to development efforts that are significantly higher for public apps than for custom apps.

Public apps may have to provide technical support to thousands of Shopify merchants around the clock, which places much higher demands on scalability, accuracy and security. In comparison, custom apps with just one retailer only have to meet a fraction of these requirements.

However, public apps are the only app type that can be offered in the Shopify App Store. Before submission, they must go through a Shopify review process and are tested by Shopify from a user perspective.

In most cases, developing an app for Shopify is much more complex than developing a plugin for other shop systems.

That's because Shopify Apps are cloud-based SaaS applications that require regular maintenance and are available 24/7 to thousands of merchants.

The authentication process for Shopify and the integration of databases for various purposes, such as storing security-critical data, are also extremely rare in this form for plugins for other shop systems.

The development processes also differ significantly for a custom app and for a private app.

Let's delve into what we do here at Especial when it comes to developing apps, shall we? Of course, we will also put highlight the additional costs for public apps.

From experience we have learnt that both custom apps and public apps require a corresponding planning phase. This is the part where requirements are recorded and converted into a corresponding solution. This is also the part where the UX design usually takes place. During this phase, our designers use wireframes to outline the future user interface and the processes within the app.

Public apps generate significantly more effort during planning. In addition to the functional requirements, public apps also have to consider issues related to the multi-user system. This includes, for example, login (start screen), registration and payment processing.

The support of different themes and the interactions with other apps must also be taken into account, since public apps can be installed by any Shopify merchant.

Therefore, in contrast to the custom app, the future application environment is not clearly defined. 

In the visual design process step, the wireframes from the planning are translated into complete design files and prototypes for desktop, tablet and smartphone.

If you want to keep your app in line with the Shopify admin design, you can easily do so, by using 

 during the visual design and coding phase.



Since public apps are listed in the App Store, additional assets such as an app icon and advertising graphics are required. Also, an app needs stronger branding if it is going to stand out in the App Store. In the design process, more emphasis must be placed on a uniform and aesthetic design. This is the opposite of custom apps, as these usually get by with a very functional design without any branding. 

After the planning and design phases have been completed, the coding of the Shopify app can begin. The amount of effort pumped in here depends very much on the individual app and its range of functions. However, certain functionalities such as registration and authentication, which are always necessary for Shopify apps, always arise and depend on the degree of complexity and the catalog of requirements of the app.

As a result, the portion of the effort for very simple apps is often mainly in the mandatory technology for Shopify apps. For complex apps, on the other hand, the core functionality represents the largest part of the work.

There is a lot of additional effort in programming for public apps. For example, core functions must be structured in such a way that they work with as many Shopify shops as possible. These include the various themes and compatibility with other apps.

The software architecture also has to be thought of differently for public apps: data storage and complex, automated registration, payment and authentication procedures must also be implemented for a larger user base. In the case of a custom app, these can be very simple in comparison, since they only have to work for one user/store. Additionally, custom apps can opt in for a token based authentication which is much simpler to implement.

The embedding of different payment models is also reserved for public apps and can require a relatively large amount of work.

Testing & QA mostly takes place during coding. What is really important to us is to shine a spotlight on the differences between a custom and a public app in a separate section for testing & QA.

In Testing & QA, automated and manual tests of the app are carried out to uncover any problems before they occur in live operation. Usually, test scenarios are created for the most important functions of an app and then the functionality is checked by QA engineers and automated tests for different application scenarios.

Testing & QA are a very broad field within software development. It is possible to invest huge amounts of resources into testing even the smallest apps. It is therefore important to find the right balance in the project – this is often referred to as "test coverage", which is given as a percentage.

Apps for the Shopify App Store have to be tested much more  than custom apps. Not do significantly more test scenarios due to different configurations of the different Shopify stores exist. There are also significantly more interactions with different themes and apps that need to be considered.

In addition, with an app published in the Shopify App Store, you can simply afford fewer mistakes because there is no direct, two-way communication channel with users. Looking across all shops, an app may have to handle very high peak loads of tens of thousands to millions of simultaneous shop visitors. This requires a correspondingly sophisticated infrastructure.

All this leads to significantly longer and more intensive tests & QA processes.

Step 5: Shopify Listing & Review Process (Public Apps Only)

After work is completed on the first version of the app, in the case of a custom app, it can be installed directly in a single Shopify store.

to be offered on the Shopify App Marketplace, the process is different:



First, a listing with images, screenshots and advertising texts must be created for the App Store – maybe even in different languages. It is also wise to create a manual and a support center for future users. App providers also often offer promotional videos of their Shopify app.

If the listing is ready for use, the public app must be sent over to Shopify for a review. A Shopify employee tests the app from the perspective of a user. This means that the reviewer at Shopify will not check the code and security systems, but will only evaluate the app like a regular app user would do.

This means that app reviewers often have suggestions for improvements to the app and insist on implementing these suggestions before the app is released on the App Store.

This leads to a change requests and new designs that have to be created. The coding and testing process has to be run again, to account for the new features.

In our experience, the app reviewers' feature requests can often be quite extensive. For example, we have already been asked to integrate a complete analytics & reporting component including CSV export of data into the app, although we never planned this feature.

Once the app is in operation, the permanent maintenance and support phase begins. In the case of custom apps, it's mostly just code changes as Shopify makes changes to their platform and APIs. This happens very often, and Shopify typically gives developers 12 months to implement new requirements.

Depending on the technical structure of the app, these technical changes to the Shopify app can be completed within a few hours. It may also take several days or even weeks of development effort, it really just depends. 

 In the case of public apps, technical updates have to be made, which are often much more complex to implement in the case of public apps. Public apps require constant support from the app provider because despite intensive testing, it is very common for an app to have problems or functional limitations in certain Shopify shops.

This is mostly due to the individual setup of a Shopify merchant. For example, they may have countless other apps installed that have a negative impact, for example by overwriting certain app functions. Or they use a very exotic theme for which the app has to be adapted accordingly.

However, there are also regular support requests from users who only suspect a malfunction of the app, but in practice other factors such as incorrect operation or incorrect shop settings cause the problem. In this case, there is still support effort to clarify the problem.

As you can see, in addition to the core functionality, the cost of an app depends primarily on whether it is a custom app for a Shopify user or a public app for the App Store.

To give you a rough idea of the cost difference between public and custom app, we have prepared an example here.

The app in this example has a relatively simple core function. For example, displaying a dynamic pop-up in the app user's shop.

for a custom app, while the public app means about 

6 weeks of work for the same core functionality

. At an hourly rate of €100, this results in 

of about €8,000 for the custom app and about €24,000 for the public app 

In addition, the support and maintenance for the custom app on an annual basis is 12 days, significantly less than 60 days for the public app. The support & maintenance values are based on our own experience of apps with several hundred users in the Shopify App Store. Many hours are spent on support work, which is usually not taken on by developers but by support staff at a significantly lower hourly rate.

Developing a Shopify app is not a simple undertaking. You should always be aware that you are developing SaaS software which, in the case of Shopify, must also be able to scale very well. This means that the development process should be done very professionally to get meaningful results.

The decision as to whether you need a custom app or a public app is based on the question of whether the app should be available to all Shopify users or just a single one. The costs also result from this decision.

Plan with a beta period to test and improve the app in live conditions. In the case of Shopify Apps, you can make your listing “invisible”. This means that the app can only be installed by people who receive the link from you.

It is often a good approach to first test a new concept as a custom app and then convert it to a public app if successful. All in all, this results in a slightly higher effort than if you develop a public app directly, but you can validate your app idea first

Don't rush the planning and design phase. Omitting or greatly shortening certain process steps may initially create a subjectively good feeling, since subjectively progress is made quickly. In fact, you're building up 

that will cost you significantly more time and money to resolve later.

The competition on the Shopify App Store is now very tough. Also think about any marketing opportunities and engage in App Store SEO to increase their visibility. Your app should also have clear USPs if you want to compete with big apps.

In den vergangenen Monaten haben wir uns bereits mit den 

 auseinandergesetzt. Das zweite große agile Framework ist die Kanban Methode.

Der Begriff Kanban kommt aus dem japanischen und bedeutet so viel wie Signalkarte. Der Ursprung des Frameworks liegt nämlich beim Autohersteller Toyota, der mit Kanban Mitte des 20. Jahrhunderts begann, seine Produktionsprozesse zu optimieren. Um auch in IT-Projekten eingesetzt werden zu können, wurde das Framework natürlich angepasst, aber im Kern befinden sich viele Ideen, die auch Toyota zum Erfolg verholfen haben.

Das allgemeine Ziel von Kanban ist die Visualisierung und das Einführen von klaren Strukturen, um die Übersicht über Projekte und Prozesse zu wahren. So können auch Engpässe und Potenziale für Verbesserungen entdeckt werden.

Im Kanban Framework gibt es klare Regeln, die für Struktur sorgen und damit zum Erreichen der Ziele beitragen.

Um eine Übersicht zu gewinnen, ist der erste Schritt, das Projekt zu visualisieren. Dafür gibt es das wichtigste Instrument im Kanban Framework: das Kanban Board. Dabei handelt es sich im Kern um eine Tabelle mit mindestens den folgenden drei Spalten:

In der klassischen Ausführung ist das Kanban Board tatsächlich eine Wand, oder Tafel, auf der die Aufgaben mittels Klebezetteln eingetragen werden. Auf den Klebezetteln stehen wiederum die im Projekt anfallenden Aufgaben mit einer detaillierten Beschreibung und allen weiteren Informationen. Die Klebezettel wandern dann von links nach rechts über das Kanban Board, bis Sie als erledigt eingestuft und archiviert werden.

Da ein physisches Board erfordert, dass das gesamte Team sich an einem Ort befindet, erfreuen sich heute übrigens auch digitale Boards wie beispielsweise das Tool 

Damit kein Chaos entsteht, muss klar definiert werden, wie viele Aufgaben sich zu einem Zeitpunkt in einer der Spalten des Kanban Board befinden dürfen.

Es ist wichtig Kennzahlen, wie die Warteschlange, oder die Verweildauer der Aufgaben in den einzelnen Spalten messen. So erkennt man Engpässe und kann die Begrenzung der einzelnen Spalten ganz nach Bedarf erhöhen und senken.

Damit es zu keinen Missverständnissen oder Fehlern kommt, muss allen Beteiligten ein einheitliches Verständnis von Begriffen und Prozessen vorliegen. Zum Beispiel muss genau geklärt sein, welche Punkte zutreffen müssen, damit eine Aufgabe als erledigt gilt.

Wie bereits erwähnt ist ein wichtiges Ziel von Kanban die kontinuierliche Verbesserung durch Einsatz der Regeln und Instrumente, um Bearbeitungszeiten und die Ergebnisse immer weiter zu optimieren. Dabei ist übrigens auch wichtig, dass alle Beteiligten unabhängig Ihres Ranges in der Firma Probleme und Ideen offen ansprechen können. Dies führt automatisch zu flacheren Hierarchien und mehr Verantwortung für die Mitarbeiter.

Kanban ist ein sehr flexibles Framework. Daher kann auch das Kanban Board ganz auf den individuellen Bedarf angepasst werden.

So kann es beispielsweise sinnvoll sein, die Anzahl der Spalten des Boards zu erhöhen. Das ist besonders praktisch, wenn es klare Freigabe-Prozesse oder unterschiedliche Bearbeitungsstufen im Projekt gibt, die so besser veranschaulicht werden können.

Eine weitere beliebte Methode ist das Einsetzen von unterschiedlich eingefärbten Klebezetteln. So kann zum Beispiel markiert werden, welche Aufgabe welcher Abteilung zufällt, oder ob es sich um kritische oder optionale Aufgaben handelt.

Das Kanban Board als Instrument kann übrigens auch sehr flexibel in anderen Situationen eingesetzt werden, um eine bessere Übersicht zu erhalten. Im Scrum Framework kann man mit einem Kanban Board zum Beispiel Backlog und Sprint-Inhalte vortrefflich visualisieren.

Oft wird die Frage nach dem Unterschied zwischen Kanban und Scrum gestellt. Aber schon daran, dass das Kanban Board eine gute Ergänzung zum 

 darstellt, kann man erkennen, dass Scrum und Kanban keine gegensätzlichen Methoden darstellen. Vielmehr beschäftigen sich die beiden Frameworks mit unterschiedlichen Aspekten eines Projektes: Während Scrum vorwiegend die Zusammenarbeit des Projektteams regelt, beschäftigt sich Kanban damit, die Übersicht über ein Projekt zu wahren und Optimierungspotenziale aufzudecken.

Kanban ist ein einfaches aber effektives Framework, mit dem man Projekte und Prozesse visualisieren, kontrollieren und steuern kann. Aufgrund seiner Flexibilität kann Kanban auch andere Methoden und Frameworks wie beispielsweise Scrum ergänzen und klaren Mehrwert liefern.

Schreiben Sie uns daher gerne eine E-Mail an 

oder kontaktieren Sie uns über unser Kontaktformular.

 about a software development method called ‘Scrum’. It’s a massively agile method, and we’ve outlined the great benefits of this. 

There is a second framework that we’d like to introduce to you, which is called ‘Kanban’. It is also majorly agile and has many benefits too, which we will get into below.

Let’s take it back. Welcome to a small History class.

The term Kanban comes from the Japanese and means something like a ‘signal card’. The origin of the framework comes from the famous car manufacturer we know as Toyota. Toyota began to optimize its production process with Kanban in the middle of the 20th century. The framework was of course then further adapted so that it could also be used in IT projects, but there are many ideas at the core that have also helped Toyota to be successful.

Kanban has one main focus – to bring clear structure. Through Kanban and its methods, you will better understand the structure of projects as they are visually represented. This allows for increased overview of processes and clarity for everyone involved in the project. With this method, bottlenecks and the potential for improvements will also be discovered.

Like with most things that bring about structure, they also tend to come with a set of rules. It is no different with the Kanban Framework. Here you will find clearly determined rules that ensure structure and thus contribute to the achievement of goals.

To get an overview, the first step is to visualize the project. The most important tool in the Kanban Framework for this is what is called ‘The Kanban Board’. At its core, this is a table with at least the following three columns:

1) ToDo
2) In Process
3) Done

In the classic version, the Kanban board is actually a wall or board on which the tasks are entered using sticky notes. The sticky notes contain the tasks to be performed in the project, with a detailed description and all other information. The sticky notes then travel from left to right across the Kanban board until they are classified as complete and archived. It’s a very clever system that keeps everything in check.

Since a physical board requires the entire team to be in one place and is a bit harder to manage, digital boards such as the 

In order to avoid chaos, set boundaries. Be sure to distinguish between tasks appropriately. The number of tasks in each column must be clearly defined. It makes little sense to create a wonderfully organized board if you end up simply jam-packing it with too many tasks.

It is important to measure key figures. There are things such as the queue or the dwell time of tasks in individual columns. This will allow you to avoid bottlenecks or the backlog of tasks. You might even be able to foresee where you have set too many tasks, and so you can immediately decrease or disperse the tasks to make for a more manageable workload.

To ensure that there are no misunderstandings or errors, everyone involved must have a uniform understanding of terms and processes. Consistency in understanding within the team is crucial for the success of the Kanban method. For example, before being able to set a task in the ‘completed’ or ‘done’ column, there needs to be a checklist of sorts that each team member can mentally go through to ensure that their task is indeed 100% done.

We’ve mentioned this a bit above, but we’d like to reiterate the importance of the rules and the tools that are needed to ensure that the Kanban method works at its highest level. Kanban is meant to continuously improve and optimize your business processes and ultimately, its results too.

It is also important that everyone involved, regardless of their rank in the company, can openly address problems and ideas. This automatically leads to flatter hierarchies and more responsibility around employees.

Kanban is a very flexible framework. Due to this flexibility, a Kanban board can also be adapted and tweaked to suit individual needs.

For example, it may make sense to increase the number of columns on the board, depending on your personal business model. This is particularly useful if there are clear approval processes or different processing stages in the project. This will allow for a more accurate visual representation of a project's progress.

Another popular method is the use of differently colored sticky notes. For example, it can be marked which task belongs to which department. The color can also show the level of importance, so whether a task is critical or an optional task.

The Kanban Board as an instrument can also be used very flexibly in other situations in order to get a better overview. In the Scrum Framework, for example, you can use a Kanban board to visualize backlog and sprint content excellently.

The main question you get asked when you bring up the word ‘Kanban’ is ‘’But how is it different from Scrum?’’.

Well, the two frameworks each deal with different aspects of a project. Scrum primarily regulates the cooperation of the project team, Kanban deals with maintaining an overview of a project and uncovering optimization potential.

They are not the same, but they are also not on opposite ends of the spectrum. They’re simply two frameworks that deal with optimization and bring in organization, but in two completely different spheres within the same project. For example, Kanban is a good addition to the Scrum framework. See how we said ‘addition’, not ‘substitute’ – they can work together for ultimate success.

Kanban is a simple but effective framework for visualizing and controlling projects and processes. Due to its flexibility, Kanban can also complement other methods and frameworks such as Scrum and provide clear added value.

If you would like to know more why not pop us an email on 

In der Software-Entwicklung setzen heute viele Unternehmen erfolgreich agile Methoden ein, um Ihre Projekte flexibel zu halten und nutzerorientierte Lösungen zu entwickeln. Dabei kommen unterschiedliche Frameworks zum Einsatz, die dabei helfen, die Zusammenarbeit in agilen Teams zu strukturieren.

Eines der international beliebtesten agilen Frameworks ist Scrum. Scrum ist eine bewährte, skalierbare Projektmanagement- und Entwicklungsmethode und wird erfolgreich in Großprojekten mit bis zu mehreren Hundert Team-Mitgliedern eingesetzt. Es funktioniert daher für Teams nahezu jeder Größenordnungen und umfasst konkrete Artefakte (Tools), Rollen und Rituale (Meetings mit klaren Regeln), die die Zusammenarbeit ordnen. Im Folgenden stellen wir die Grundregeln und Elemente von Scrum vor. Dabei steigen wir direkt mit dem ersten Artefakt, dem Product Backlog, ein:

Das Product Backlog ist im Prinzip eine Liste der offenen Aufgaben in einem Scrum Projekt. Auf dieser Liste befinden sich alle Kundenanforderungen sowie bekannte Bugs zusammen mit einer klaren Priorisierung aller Themen. So ist immer klar definiert, welche Themen durch die beteiligten Teams als Nächstes in Angriff genommen werden sollen.

Das Backlog wird zunächst zum Start des agilen Scrum Projektes mit allen absehbaren Aufgaben gefüllt. Im Laufe des Projektes können dann neu erkannte Anforderungen jederzeit hinzugefügt werden.

Jedes Scrum Projekt ist in sogenannte Sprints aufgeteilt, in denen die Aufgaben aus dem Product Backlog abgearbeitet werden. Die Länge der einzelnen Sprints ist in jedem Projekt immer gleich und zudem klar limitiert. Üblicherweise dauert ein einzelner Sprint 1–4 Wochen.

Das Besondere an der agilen Scrum Methode ist dabei, dass am Ende jedes Scrum Sprints ein funktionsfähiges Produkt oder Feature ausgeliefert wird. Das ist übrigens auch einer der wichtigsten 

Unterschiede der agilen Methode zum klassischen Wasserfallmodell

Die folgende Grafik zeigt, wie die Sprints in einem Scrum Projekt direkt ineinander übergehen: Auf eine Planungsphase folgt die Umsetzung, wie sie in IT-Projekten üblich ist in den Schritten Design, Entwicklung, Testen, Deployen, Review und Launch. Solange sich noch Themen im Produkt Backlog befinden, folgt darauf stets ein weiterer Sprint, bis das Produkt fertiggestellt ist.

Für ein besseres Verständnis kann ein Scrum Sprint auch in drei wichtige Phasen unterteilt werden:

Am Anfang jedes Scrum Sprints steht die Sprint-Planung. Dabei nimmt sich das Team maximal einen Vormittag Zeit, um den kommenden Sprint zu besprechen. Dabei wird unter anderem geklärt, welche Aufgaben aus dem Backlog in den nächsten Sprint aufgenommen werden, welche Arbeitspakete daraus entstehen und welche Teammitglieder für diese verantwortlich sind. Darüber hinaus ist es hier wichtig zu klären, welche Informationen und externen Ressourcen benötigt werden, um die Aufgaben erfolgreich abzuschließen.

Wenn es Bedenken von Teammitgliedern gibt oder wenn sie das Gefühl haben, dass sie bei einer ihrer Aufgabenzuweisungen die Unterstützung eines Vorgesetzten benötigen könnten, wäre dies der richtige Zeitpunkt, dies zu erwähnen.

Eine gute Sprint-Planung ist dabei von besonderer Bedeutung. Eine schlechte Planung kann zum Beispiel dazu führen, dass zu viele Themen aus dem Backlog in den Sprint aufgenommen werden, was schnell zu einem Problem werden kann.

Der eigentliche Scrum Sprint beginnt mit Abschluss der Sprint Planung. Da die Aufgaben geklärt sind, kann jedes Teammitglied mit der Arbeit beginnen. Die Arbeit wird lediglich durch ein tägliches Stand-up Meeting unterbrochen, in dem jeder Mitarbeiter kurz aufzeigt, was er am Vortag erledigt hat, woran er gerade arbeitet und ob es irgendwelche Barrieren gibt, die seinen Arbeitsfortschritt derzeit blockieren.

Der Name “Stand-up Meeting” kommt übrigens von der Idee, dass man das Meeting wortwörtlich im Stehen abhält, um automatisch sicherzustellen, dass das Meeting kurz und knapp bleibt. Tatsächlich sollte man versuchen, die Länge des Zusammenkommens auf circa 15 Minuten zu limitieren.

Am Ende jedes Scrum Sprints steht das Sprint-Review. Hier präsentiert das Team seine Arbeit und Erfolge im Rahmen einer Demonstration des fertiggestellten Produktes oder Features. Dabei soll tatsächlich nur die technische Lösung selbst gezeigt werden. Präsentationen in Form von Powerpoint Folien sind hier verpönt.

Auf das Review folgt noch die Sprint-Retrospektive. Hierbei setzt sich das Team zusammen und bespricht, was im Sprint gut und was schlecht gelaufen ist, um Probleme zu beheben und eine Wiederholung von Fehlern zu vermeiden. Genau wie mit dem Produkt ist es hier das Ziel, das Team mit jedem Sprint weiterzuentwickeln und größere Erfolge zu feiern.

Zusätzlich zu Backlog und Sprints sind bei Scrum die Rollen der Beteiligten von besonderer Bedeutung und klar geklärt. Scrum kennt die folgenden drei Rollen:

Der Product Owner ist dafür verantwortlich, die Projektanforderungen zu formulieren und zu priorisieren. Das bedeutet im Kern, dass er das Product Backlog befüllt. Dabei begibt sich der Product Owner nicht in den Bereich der Produktentwicklung, sondern formuliert lediglich die Herausforderungen der User, die es zu lösen gilt. Die Ausarbeitung der Lösung passiert nämlich durch das Scrum Team selbst.

Der Scrum Master unterstützt das Scrum Team und hilft Barrieren zu beseitigen. Er ist verantwortlich dafür, dass die Team Member Ihre Arbeit ungestört erledigen können. Damit ist er auch eine Art Projektmanager, da er darauf achtet, dass der tägliche Fortschritt gut dokumentiert wird und das Team sich an alle Regeln hält. Er ist zum Beispiel für die Koordination und Einhaltung von Ritualen wie dem täglichen Stand-up Meeting verantwortlich.

Die Team Member im Scrum Modell sind Mitarbeiter aus unterschiedlichen Fachdisziplinen, die gemeinsam an der Umsetzung der Anforderungen arbeiten. Dabei sind die einzelnen Teammitglieder oft nicht komplett auf einen einzelnen Aufgabenbereich spezialisiert, sondern übernehmen Aufgaben, die oft mit vielen unterschiedlichen Fachbereichen Berührungspunkte haben. So kann es zum Beispiel vorkommen, dass ein Programmierer das Produktdesign mit ausarbeitet, oder ein Webdesigner ein Produkthandbuch für die Nutzer schreibt. Diese große Abwechslung in den Aufgabenbereichen macht die Arbeit für die Mitarbeiter in Scrum Teams besonders interessant und spannend.

Adresse

Soziales

Kontakt

Tagged: Prozesse

Kosten & Prozess bei der Shopify App Entwicklung

Kanban – Methode der Softwareentwicklung

Agiles Projektmanagement: Scrum

Freelancer oder Agentur – Was passt besser zu mir?

Personas im E-Commerce: Wer kauft bei mir?