10 Wege bei der Entwicklung deiner Online-Plattform zu scheitern (und einer der funktioniert)

Veröffentlicht am: 5. November 2021
Aktualisiert am: 18. November 2021
Lesezeit: 28 min
Preis: € 0,00

10 Wege bei der Entwicklung deiner Online-Plattform zu scheitern (und einer der funktioniert)

Inhalt

Du hast eine vielversprechende Idee für ein Online-Business und möchtest schnell heraus finden, ob sie auch in der Praxis etwas taugt? Ich kann dir dabei helfen.

Ich bin Michael, 37. Seit ich 15 bin entwickle ich Webseiten. Genauer gesagt komplette Online-Plattformen mit Datenbank und allem was sonst noch dazugehört. Viele meiner früheren Projekte waren erfolgreich. Darunter eine Online Musik Community, ein B2B Shopsystem für einen großen Druckerhersteller und ein Content Management System für Obamacare (healthcare.org).

Mein letztes großes Herzensprojekt “Substance” hat mir aber vor allem eines gezeigt: Was bei der Entwicklung einer Web-Plattform alles schief gehen kann, technisch sowie zwischenmenschlich. In diesem Erfahrungsbericht zeige ich dir 10 Wege, mit denen es wahrscheinlich nicht klappt. Und einen Ausweg.

Mit Ken (der Plattform, auf der du gerade diese Zeilen liest) habe ich es schlussendlich geschafft, meine Idee einer Online Schreibplattform umzusetzen und ich möchte dir zeigen, wie ich das gemacht habe. Du bekommst von mir jene Komplettlösung, die für mich und mein Projekt funktioniert hat und höchstwahrscheinlich auch für dich passt, speziell wenn du ganz am Anfang stehst.

Dieser Text ist vorwiegend an Unternehmer gerichtet, nicht an Entwickler. Wenn du technisches Verständnis mitbringst, super. Wenn nicht, wirst du nach dem Lesen die richtigen Fragen an deinen potentiellen IT-Dienstleister stellen können und heraus finden ob es ein Match ist.

Aber fangen wir mit dem unangenehmen Teil an…

So klappt es sehr wahrscheinlich nicht

Wir wollten die Wissenschaft revolutionieren. Zumindest den Austausch von Wissen. Dafür haben ich, mein Partner und ein Mitarbeiter fast 10 Jahre investiert, und uns zunächst mit wissenschaftlichen Verlagen zusammen getan. Es ging uns zu langsam und schließlich haben wir auf unsere bisherige Arbeit aufbauend begonnen “Substance” als eigenes Produkt zu entwickeln. Aber auch hier lief vieles nicht nach Plan. Hier einige meiner Learnings aus dieser Zeit, und der Zeit davor.

Weg 1: Standard-Software

Oft scheint es sehr naheliegend eine fertige Lösung (z.B. ein Shopsystem) zu verwenden und an deine Bedürfnisse anzupassen. Das Verlockende daran ist, dass du anfangs rasend schnell vorankommst und dabei ganz offensichtlich, wie vom Anbieter versprochen, extrem viel Zeit sparst.

Dieses Gefühl hält solange, bis du mit deinem Projekt an den Punkt gekommen bist, wo du etwas Neues, innovatives hinzufügen möchtest. Dann wirst du mit an Sicherheit grenzender Wahrscheinlichkeit fluchen. Zumindest mir ging es immer so, wenn ich versucht habe, Standard-Software anzupassen.

Selbst wenn die Standardlösung erweiterbar oder gar Open Source ist (Wordpress, du bist gemeint!) und du Änderungen vornehmen kannst, musst du oder dein Programmierteam erst einmal verstehen, wie alles im Detail funktioniert. Und bis dann dieses eine extra Popup so sitzt wie du es wolltest, haben deine Programmierer bereits mehrere Tage Zeit investiert.

Versteh mich nicht falsch. Es gibt gute Standardsoftware. Allerdings nur für Endbenutzer (Twitter, Airbnb, Google Docs, Ken 😉). Ich habe jedoch noch keine gefunden, die dir wirklich hilft, wenn du etwas Neues erschaffen willst, für eine Zielgruppe, die aus “normalen Menschen”, also nicht aus Technikern, besteht.

Weg 2: Standard-Software (die sich als Custom-Software tarnt)

Wenn dir jemand ein Software-System anbietet, und Teile des User-Interfaces erinnern dich stark an Excel-Tabellen, dann ist das ein schlechtes Zeichen. Wenn dann angemerkt wird “das sehen ja eh nur die Admins…” ist es höchste Zeit dich aus dem Staub zu machen. Du hast es wahrscheinlich mit einer dieser “flexiblen” Lösungen zu tun, die “alle Stückerl spielen”, aber “keines gscheit”. Du musst verstehen: Wenn dir Firmen Softwarelösungen anbieten, haben sie ein wichtiges Ziel: Mit möglichst wenig Mehraufwand möglichst viele Kunden (=Use Cases) zu bedienen. Eine Art das zu schaffen, ist ganz viele Konfigurationsparameter ins System einzubauen. An denen schraubt man dann rum, bis es für den neuen Kunden (z.B. für dich) passt. Nicht selten zahlst du dafür dann einen großen Batzen Geld, obwohl eigentlich nur ein Standard-Produkt für dich konfiguriert, dabei aber nichts für dich entwickelt oder gestaltet wird.

Nehmen wir an, du äußerst einen Anpassungswunsch: “Ich hätte hier daneben gern Information X angezeigt.” Und du hörst: “Uuhh, das geht nicht so ohne weiteres. Aber hier auf der Detail-Seite könnten wir es einblenden.” Gratulation, du bist gerade dabei, deine Online-Plattform um die Bedürfnisse deiner Software-Bude herum zu bauen. Deine User werden jauchzen vor Freude!

Ich muss gerade in zwei Unternehmen miterleben, welche schmerzliche Erfahrung dieser Weg bedeuten kann. In einem Startup mit einer genialen Idee haben die Gründer einen 6-stelligen Betrag für eine Erstentwicklung verbrannt und müssen nun de facto von vorne starten. Im zweiten Fall zwingt ein Konzern seinen Mitarbeitern in Europa ein neues Standard ERP-System auf, das nach 8 Jahren voller Pannen in der Entwicklung endlich ausgerollt wird. Das wirklich tragische daran ist, dass die Mitarbeiter bereits ein über 15 Jahre speziell für sie entwickeltes und ständig verbessertes System verwenden. Sie können es nicht fassen, ihre seit Jahren geschätzte Arbeitsumgebung jetzt gegen ein seelenloses Monstrum von Standardsoftware tauschen zu müssen.

Weg 3: Alles selber machen

Okay, also am Besten alles selber machen. Richtig?

Falsch.

Vor allem erfahrene Programmierer bevorzugen oft diese Variante, da man die volle Kontrolle über die Programmabläufe behält und immer und überall eingreifen kann. Das ist grundsätzlich super, aber was dabei oft übersehen wird ist, dass man definitiv mit einer viel längeren Entwicklungszeit rechnen muss. Und es viel schwieriger für neue Entwickler wird sich zurecht zu finden.

Bei unserem Projekt Substance haben mein Partner und ich so gut wie alles selbst gemacht. Nachdem sich unsere Wege schließlich trennten, wurde mir bewusst, dass jede Zeile selbst produzierter Code eine enorme Verantwortung bedeutet. Nicht weil unser Code schlecht war, sondern weil die Belastung für mich zu groß gewesen wäre diese Menge an Code weiter zu warten, habe ich mich von den Ergebnissen von 7-Jahren leidenschaftlicher Arbeit verabschiedet. Das war echt bitter und es hat gedauert bis ich das verdaut habe. Ich habe dann auf einige wenige Frameworks und Libraries gesetzt, selbst wenn diese Einschränkungen mit sich brachten. Aber ich war entlastet und konnte mich den Kernproblemen widmen.

Weg 4: Alle coolen Frameworks und Libraries verwenden

Frameworks und Libraries sind also die Lösung? Leider wieder falsch.

Vor allem weniger erfahrene Entwickler stürzen sich oft von einem coolen Tool ins nächste (been there, done that). Zugegeben, es ist auch wirklich schwer den Überblick zu behalten und eine gute nachhaltige Technologiewahl zu treffen. Wenn du schon mal zu Web-Frameworks recherchiert hast, weißt du es gibt viele Optionen, und jede einzelne wird sowohl religiös verehrt als auch von anderer Seite süffisant belächelt.

Zur Erklärung: Ein Web-Framework gibt Entwicklern ein Grundgerüst vor - man spart sich viel Zeit und kann gleich mit der Produktentwicklung loslegen. Libraries sind Software Komponenten, die eine bestimmte Aufgabe lösen und die man zu einem Gesamtsystem zusammensetzen kann. Viele Internet Startups sind überhaupt erst möglich geworden, weil sie auf Frameworks und Libraries zurückgreifen konnten. Als Beispiel fällt mir hier Github ein, welche als Framework Ruby on Rails verwendet haben, um das Versionierungssystem Git über eine grafische Weboberfläche zugänglich zu machen.

Die Nachteile von Frameworks und Libraries zeigen sich oft erst später. Frameworks geben manchmal zu viel vor (Entwickler sagen dann “opinionated”) und machen es den Entwicklern schwer in bestimmte Programmabläufe einzugreifen. Man hört dann: “Das Framework ist wieder im Weg.” Sowohl bei Frameworks als bei Libraries kann es vorkommen, dass Fehler enthalten sind, die man nicht gleich bemerkt. Dann ist man oft auf die Hilfe der Autoren angewiesen.

Zusammengefasst: Frameworks und Libraries, ja. Ich plädiere aber dafür, sie sparsam und geschickt auszuwählen. Sie müssen gut zusammen passen. Und sobald du dich entschieden hast, lass dich nicht beirren und halte deinen Kurs!

Weg 5: Zu viel Technologie

Technologie hat in den letzten Jahren einen unglaublichen Hype erlebt. Ich glaube, das hat dazu geführt, dass wir versuchen so ziemlich jedes Problem mit Technologie zu erschlagen. Wahrscheinlich braucht dein Projekt keine Blockchain, und über Machine Learning kannst du dir ernsthaft Gedanken machen, sobald du hunderttausende Datensätze gesammelt hast.

Bei unserem Projekt Substance haben wir versucht unser Problem “wissenschaftliches Publizieren vereinfachen” mit Technologie zu lösen. Wir haben unsere ganz eigene Editor-Lösung von der Pike auf entwickelt, damit wir so etwas wie Google Docs für wissenschaftliche Publikationen bauen können.

Rückblickend bin ich überzeugt, es wäre besser gewesen einige technische Anforderungen vorübergehend zurückzustellen (Echtzeit-Editieren, Versionsmanagement, etc.) um ein Basisprodukt schneller in die Hände der User zu kriegen.

Weg 6: Software-Entwicklung nach Lehrbuch

Aus eigener Erfahrung traue ich mich behaupten, dass es einen falschen Platz für Software-Entwicklung nach Lehrbuch gibt. Und zwar in Startups.

Wenn du frisch von der Uni oder der FH kommst, bist du darauf vorbereitet in einem großen IT-Unternehmen an großen Projekten mitzuarbeiten. Requirements-Engineering, Test-getriebene Entwicklung und Scrum sind deine Toolsets um die Komplexität zu meistern. Nichts davon ist schlecht, aber in einem IT-Startup, in dem noch nicht klar ist wohin die Reise eigentlich geht, ist diese Herangehensweise vor allem eines - ein großer Bremsklotz.

Als Startup musst du dich an eine Lösung herantasten, und du musst einer Testgruppe von Benutzern so schnell wie möglich ein funktionales System bieten können. Sobald sich eine Lösung herauskristallisiert hat, ist es an der Zeit strikter auf Lehrbuch-Techniken zurückzugreifen.

Wie immer im Leben braucht es einen gesunden Mittelweg. Wenn du ein kleines Programmierteam hast, rate ich dir zunächst auf automatisierte Tests zu verzichten. Generell ist ein defensiver Programmierstil in dieser frühen Phase oft hinderlich. Um einen neuen Workflow an Usern zu testen, musst du nicht jeden möglichen Fehlerfall prüfen. Das kostet Zeit und ist zu einem späteren Zeitpunkt wichtig, aber erstmal geht es um eine Sache: Sichtbare Ergebnisse für den Benutzer und ausloten einer selbsterklärenden Benutzeroberfläche.

Auch mit Optimierungen solltest du unbedingt warten. Was bringt es dir, wenn du eine schnellere Ladezeit bei einem Prototypen heraus holst, das Konzept aber danach weg wirfst, weil ein anderes bei den Benutzern besser angekommen ist?

Weg 7: Keiner, der die Entscheidungen trifft

Hierzu eine kleine Geschichte. Gemeinsam mit einer handvoll namhafter Open-Access Verlage haben wir das Substance Consortium gegründet. Unser Ziel war es, gemeinsam eine Open-Source Lösung “Texture” zu entwickeln, um den gesamten Publishing Prozess zu vereinfachen und zu beschleunigen. Wir, Substance, kümmerten uns um die technische Umsetzung, die Verlage um die Anforderungen. Ich war extrem stolz, so etwas mit auf die Beine gestellt zu haben. Wir würden demokratisch entscheiden, welche Dinge Sinn machen und in das Projekt aufgenommen werden und welche nicht. Einige Jahre lang lief es super. Mit wenig Budget haben wir eine tolle Lösung entwickelt. Ich würde sagen, wir waren zu 87,3% fertig.

Und dann wurde es kompliziert. Die Verlage hatten im Detail unterschiedliche Anforderungen (verschiedene Inhaltstypen und Darstellungsformen) und erst auf den letzten Metern des Projekts wurde uns bewusst, dass wir den Spagat, alle unter einer Technologie zu vereinen nicht mehr schaffen würden.

Wenn ich nochmal in derselben Situation wäre, wie zum Start des Projekts, würde ich von Anfang an mehr Verantwortung übernehmen. Es muss eine Person geben, die in letzter Konsequenz die Entscheidungen trifft, auch wenn diese mal für eine Partei unangenehm ist. Selbst wenn es dann gar nicht zum Start des Projekts gekommen wäre, wäre das immer noch besser als jahrelange intensive Arbeit ohne essbare Früchte.

Es ist ewig schade für alle Beteiligten, dass dieses vielversprechende Projekt auf den letzten Metern abgebrochen werden musste.

Weg 8: Deine Programmierer verstehen dich nicht (und umgekehrt)

Es gibt eher kreative, intuitive Menschen und eher analytische, rationale Menschen. Erstere Gruppe findet man meiner Erfahrung nach oft bei Unternehmern. Letztere öfter als nicht bei Ingenieuren und Technikern. In diesem Umstand lauert eine Gefahr, die meiner Schätzung nach 7 von 10 IT-Projekten das Leben kostet.

“Hört er oder sie mir überhaupt zu?” ist ein Gedanke, der bei einem Gespräch zwischen Unternehmern und Programmierern oft präsent ist. Und zwar bei beiden. Das Einzige was dann programmiert ist, sind eine Menge Missverständnisse und Frustration. Und nach einigen Monaten harter Arbeit, ein gescheitertes Projekt.

Eigentlich könnten diese beiden Typen sich perfekt ergänzen. Würde ein Unternehmer sein Projekt für einen Tag lang aus der Sicht seines Programmierers betrachten, würde er den Kunden erklären können, warum gewisse Wünsche und Anforderungen keine gute Idee sind. Und könnte der Programmierer für einen Tag in die Sicht des Unternehmers schlüpfen, würde er vielleicht beim nächsten Problem eine kluge Abkürzung wählen, anstatt blind eine technisch perfekte Lösung zu erarbeiten, die eigentlich gar nicht notwendig wäre.

Wenn du nicht das Gefühl hast dein Programmierer versteht dich, fangt gar nicht erst an zu arbeiten. Dasselbe gilt in umgekehrter Richtung. Vertrauen, Wertschätzung und die Fähigkeit zu verstehen wie der oder die andere ungefähr tickt sind essentiell für das Gelingen eines Software-Vorhabens.

Kommunikation ist bei solchen Projekten so wichtig, denn weder Produktdesign, noch Software-Architektur sind “harte Wissenschaften” in denen man auf irgendwelche Gesetzmäßigkeiten zurückgreifen kann. Du bewegst dich in einem Raum, in dem es nicht die eine richtige Lösung gibt. Vielmehr gibt es dort 10.000 Lösungen die funktionieren, und 9.000.000.000 Nicht-Lösungen die du erkennen musst, um sie frühzeitig in die Tonne zu treten und mit geschärftem Blick weiterzusuchen.

Weg 9: Du betreibst deine eigene Server-Infrastruktur

Es gibt keine Infrastruktur, die du selbst betreibst, die dir nicht auf den Kopf fallen könnte. Gerade in der Anfangsphase eines Projekts, kann dir das zum Verhängnis werden. Außer du kannst dir gleich ein zehn Personen starkes DevOps Team leisten.

Ab in die Cloud also mit deiner App. Aber das ist auch so leicht dahingesagt. Es gibt ja eine Unzahl an Technologien und Anbietern. Die Chance, dass du dich hier verrennst, ist in etwa gleich groß wie die, dass dir deine selbst betreuten Server um die Ohren fliegen. Im Kapitel Cloud-Hosting erfährst du wie ich mich bei Ken aus dieser Misere manövriert habe.

Weg 10: Du leistest dir keinen UI-Designer

Sogar wenn du selbst Designer bist, tu’s nicht! Du hast einen Tunnelblick auf dein Projekt. Und du wirst Sachen machen, die kein Mensch außer dir versteht. Garantiert. Ein ausgezeichneter Designer mit neutralem Blick ist eine der besten Investitionen, die du machen kannst. Der Zeitaufwand ist verglichen mit den Programmierkosten gering, der Mehrwert für deine Benutzer unbezahlbar.

Jetzt kennst du 10 Wege/Extreme, die für mich nicht zum Erfolg geführt haben. Aber wie sollst du es denn sonst angehen? Ich erzähle dir, wie ich es mit meiner Plattform Ken gemacht habe.

Ken - Diesmal hat es funktioniert

Mein langjähriges Projekt “Substance” war für mich zu Ende. Was jetzt? Und wie gehe ich es diesmal anders, besser an?

Nach wie vor fühlte ich mich dem Thema Wissensaustausch sehr verbunden. Ich wollte schon immer, dass es unkompliziert ist, sich leicht anfühlt und Spass macht. Das war beim komplexen wissenschaftlichen Diskurs nicht immer gegeben.

Irgendwann kam sie, die Idee: Was, wenn man Wissen in Form von persönlichen Erfahrungen weitergeben könnte, von Mensch zu Mensch?

Produktentwicklung

Okay, die Idee hat mir schon ziemlich gut gefallen, aber sie ist nichts wert, wenn ich sie nicht auch umsetzen und testen kann. Der letzten Idee (eigentlich waren es viele) bin ich fast 10 Jahre nachgegangen, und wenn daraus auch viele tolle Teillösungen hervorgegangen sind, sie wurde (zumindest bis heute) nicht real. 10 Jahre darf es diesmal nicht dauern, nein ich hatte nur ca. 1 Jahr Zeit. Und ich brauchte ein geeignetes Business-Modell.

Das Business Modell

Ich bin dieser Frage diesmal nicht wissenschaftlich nachgegangen. Es war mehr so ein Durchspielen von Szenarien, und viel mit anderen darüber diskutieren. Eine Sache war schnell klar, ein Marktplatz sollte es werden. Autoren schreiben ihre Erfahrungen auf und legen dafür einen Preis fest. Bei jedem Verkauf geht der Großteil des Umsatzes an den Autor, ein Teil davon als Plattform-Beitrag an Ken. Ein bisschen wie Airbnb, nur werden Erfahrungen statt Unterkünften gehandelt. Als nächstes brauchte ich einen Brand…

Brand

Ich habe zwar ein gewisses Gespür für Design und mich in der Vergangenheit selbst um das Branding meiner Projekte gekümmert. Bei Ken habe ich das erste Mal von Anfang an, eng mit einem Designer zusammengearbeitet und eines ist jetzt klar: Nie wieder ohne! Danke Stefan! 🙂 Es ist wie eine DNA, die sich überall wieder findet. Und es ist schon ein geiles Gefühl, wenn Leute berichten, die Plattform habe eine Art Persönlichkeit und man fühlt sich wohl wenn man damit arbeitet.

Mockups und Screendesigns

Mockups und später Screendesigns waren das primäre Kommunikationswerkzeug für uns während der gesamten Entwicklung. Die Aufteilung war so, dass ich die Mockups erstellt habe, und damit meine Ideen für das Produkt formuliert habe. Manchmal hat Stefan sie verstanden, manchmal nicht. 😉

Dann war es Zeit darüber zu diskutieren und ein paar Tage später bin ich dann mit neuen, besseren Ideen und Mockups wieder da gestanden. Für die Teile des Systems die schon schlüssig waren hat Stefan fertige Screendesigns erstellt.

Technische Umsetzung

Das haben wir auch einige Wochen so weiter gemacht. Aber parallel dazu ging es für mich schon an die Umsetzung. Meinen ersten Prototypen hatte ich in Windeseile fertig, da ich auf bestehendem Programmcode aufbauen konnte. An einem bestimmten Punkt wurde es allerdings eng, und ich musste mir eingestehen, dass ich mit der aktuellen technologischen Basis nicht weitermachen kann. Das war extrem schwierig für mich, da ich ca. 10 Jahre lang gemeinsam mit meinem früheren Partner eine eigene Technologie für Textbearbeitung entwickelt habe. Diese war auch sehr erfolgreich und hat uns und unseren Kunden gute Dienste erwiesen. Aber für mein neues Projekt passte es nicht mehr. Ich hatte geringere Anforderungen und musste Komplexität loswerden. Deswegen habe ich mich im Januar 2021 auf die Suche nach den besten und effektivsten Technologien gemacht, und mein Projekt auf komplett neue Beine gestellt. Das hat mich sicher 3 Monate extra Zeit gekostet, aber es hat sich zu 100% gelohnt.

Mit diesen Fragen habe ich mich intensiv auseinandergesetzt. Und ich widme jeder dieser Fragen ein ausführliches Kapitel.

  • Kerntechnologie: Es gibt eine Reihe von sogenannten “Technologiestacks”. Alle haben ihre Vor- und Nachteile. Ich will einerseits ganz schnell und Produkt-orientiert entwickeln können, andererseits brauche ich ein stabiles System, das mir nicht gleich nach dem Launch um die Ohren fliegt.

  • Datenbank: Wie speichere ich meine Daten zuverlässig? Ich will keinen Datenverlust, und ich will, dass die Datenbank auch bei vielen Anfragen nicht in die Knie geht.

  • Textverarbeitung: Das Schreiben eines Artikels soll sich ganz natürlich anfühlen. Leider ist das im Web bis auf wenige Ausnahmen nicht gegeben. Jeder der mal Inhalte fürs Web erstellt hat, weiß wie viele Nerven man hier oft liegen lässt.

  • Zahlungsabwicklung: Ken funktioniert wie gesagt wie ein Marktplatz. Es gibt Anbieter (Autoren) Und Käufer (Leser). Ich brauche also eine Lösung, in der ich sowohl Zahlungen von Lesern entgegennehmen, als auch Geld an Autoren auszahlen kann. Das Ganze soll vollautomatisiert ablaufen, denn ich will nicht manuell tausende Rechnungen schreiben und Überweisungen machen.

  • E-Mails: Ich brauche einen zuverlässigen Service um E-Mails über die Plattform zu versenden.

  • Bilder: Das Thema Bilder ist bei genauerer Betrachtung weniger trivial als man annehmen möchte. Meine User sollen ohne viel zu überlegen ein Bild hochladen können. Bei Profil-und Coverbildern soll, wenn notwendig, automatisch ein passender Bildausschnitt gewählt werden. Bei der Anzeige der Bilder sollen unterschiedlich große Versionen der Bilder angezeigt werden, je nachdem ob man gerade mit einem Smartphone oder einem Desktop Computer unterwegs ist. Beim Laden eines Artikels müssen Platzhalter für die Bilder dargestellt werden, damit die Seite beim Laden nicht rumspringt. Denn Google bewertet solche Eigenschaften und reiht Webseiten nach ihrer Usability-Performance. Die Darstellung von Bildern spielt hier eine sehr wichtige Rolle!

  • Videos: Ken User sollen ganz unkompliziert Videos hochladen können, egal in welchem Format. Die Videos sollen dann automatisch fürs Web aufbereitet werden. Ähnlich wie bei Bildern spielt hier die Performance eine große Rolle. Deswegen suche ich nach einer Lösung die Streaming erlaubt. Ich möchte mich bewusst nicht von Plattformen wie Youtube oder Vimeo abhängig machen.

  • Security: Das war ein schwieriger Balanceakt für mich. Denn ich wusste, wenn ich an alles denken will was potentiell schiefgehen kann, dann würde ich wohl noch 3 Jahre mit der Entwicklung brauchen. Gleichzeitig wollte ich ruhig schlafen können, sobald die Plattform online ist.

  • Cloud-Operation: Ich habe bei früheren Projekten meine eigenen Server betreut. Das hatte den Vorteil, dass ich viel Performance für wenig Geld bekommen habe. Und den Nachteil, dass ich oft sehr schlecht geschlafen habe. Ich will nie wieder für das Einspielen von Sicherheitsupdates verantwortlich sein und um 3:00 morgens einen Server neustarten, der aus welchen Gründen auch immer Schluckauf bekommen hat. Diesmal kommt alles in die Cloud, nach den modernsten Standards.

Das ist nicht das Ende

Hol dir die komplette Erfahrung und kontaktiere mich persönlich.

* Eröffnungsangebot. Nur für kurze Zeit. Keine Kreditkarte nötig.