Aber beginnen wir dort, wo man beginnen sollte: am Anfang.

Betrachten wir so ein Unternehmen mal wie ein Projekt, was würden wir als erstes tun? Richtig, ein Ziel definieren. Diese Zieldefinition sollte eine Beschreibung der Idee sein und wie die Beteiligten ihre Rolle auf dem Weg zur Erreichung sehen. Damit hätten wir zumindest den Gegenstand unseres Handelns und uns selbst definiert. Dies muss nicht in einem Pamphlet biblischen Ausmaßes enden, wenn man in der Lage ist, alles in knackigen Worten in einen Absatz zu bekommen. Das Machwerk names Businessplan kommt später.

Wenn wir also wissen, was zu machen ist, müssen wir jetzt klären, wie wir es anstellen. Dazu sollte die zweite Phase unseres Projektes dienen: die Planung. Das umfasst, wie sich unsere zwei Protagonisten organisieren sollten (sowohl grundsätzlich, also als Firma, und bezogen auf die Aufgabe der Umsetzung der “technischen” Idee, also die Projektorganisation). Da der grundsätzliche Organisationsteil meist mit weitreichenden Folgen verbunden ist, sollte man hier wenn möglich jemanden zu Rate ziehen. Die Projektorganisation sollten beide hinbekommen, da sie aus dem Projektumfeld kommen.

So, wir wissen jetzt was wir wie tun wollen. Dann geht es jetzt an das Umsetzen. Für diese Phase gibt es, außer ein paar gut gemeinten Ratschlägen und der Hinweis zum Einhalten der selbstgesteckten Grundsätze, wenig zu sagen. Es wird die erste Nagelprobe der beiden werden. Und ob einfach wirklich einfach ist. Auf alle Fälle sollten die beiden getreu dem Grundsatz der “Getting Real”-Bewegung häufig und schnell etwas Online stellen.

Das führt uns aber zum nächsten Punkt (wenn wir davon ausgehen, dass die Testphase Bestandteil der Realisierung ist): der Transition (in gutem Neudeutsch). Also die Überführung der entwickelten Idee in den Betrieb. Jetzt wird der ein oder andere anmerken, dass wir doch kein großen IT-Projekt mit tausenden involvierten Mitarbeitern in Produktion bringen. Richtig, vordergründig würde man sofort an diese Größenordnung denken. Aber egal welche Größe ein Projekt hat, eine Transition sollte in jedem Fall durchgeführt werden. Fällt sie halt nicht so kompliziert aus. Einfach ist das Zauberwort. Bei agilem Entwicklungsansatz wird sich diese Transition sowieso in Portionen immer wieder wiederholen. Das trainiert.

Jetzt kann das Geldverdienen losgehen. Und auch das will mit Bedacht getan werden. Mir fällt zwar keine Phase mehr ein, aber sicher finden sich auch hierfür ein paar schlaue Worte.

Jetzt sollten wir doch den groben Fahrplan haben, oder? Ins Detail gehe ich dann in den Fortsetzungen. Und zwar Schritt für Schritt. Andere entwicklen in der Zeit zwar komplette, funktionierende System (siehe letzter Railsrumble), aber stehen dann da mit ihrem System und haben keine Organisation drumrum

Wir werden sie begleiten und ihnen versuchen, eine Checkliste zu erstellen, die es ihnen ermöglicht, ihre simple Idee auch simple seien zu lassen.

Lasst mich kurz die Ausgangssituation beschreiben, damit die anstehenden Aufgaben klar werden.

Also, unsere zwei Protagonisten haben eine einfache Web-Idee, die wenig Entwicklungsaufwand für den Start erfordert. Sie haben sich dabei dem sogenannten agilen Entwicklungsweg verschrieben. Aus ihren anderen Web-Aktivitäten haben sie die notwendige Technik parat, die eigentlich nur noch zum Zusammenspiel koordiniert werden muss. Somit sollte die technische Seite in der Tat das geringste Problem darstellen.

Aber zu einem Unternehmen gehört mehr. Und zwar Geld. Ausgerechnet das haben die zwei aber nicht, zumindest nicht in Form exorbitanter Budgets. Somit wollen sie das Bisschen, das sie haben, auch effizient einsetzen.

Sie müssen sich um eine Organisationsform kümmern, die einfach und preiswert ist, sie im Fall des Misserfolgs aber nicht in den Abgrund reisst.

Und dann sind da noch die tausend anderen Kleinigkeiten, die das Leben so prickelnd machen und für einen immer währenden Strom der Freude und Arbeit sorgen.

Aber dazu mehr im zweiten Teil unseres Reports.

Nachdem ich gestern über BusinessModelle und Finanzierungen geschrieben habe und diese Hürde genommen würde geht es weiter mit der Infrastruktur.

Gerade hier zeigt sich, ob es sich beim Startup um eine Klitsche handelt, die gerade so überleben wird oder ein Startup das für mehr zu haben ist.

Inhalt:

• Serversicherheit für Startups
• Ausfallsicherheit von Web2.0 Startups
• Entwicklungs-, Test-, Produktionsumgebungen
• Automatisierte Tests
• Automatisches Deployment

Hört sich vielleicht erstmal hochtrabend an, aber es wird sicherlich jeder verstehen auch die VC’s und Unternehmensberater – quasi “Unternehmensberater ready”

Serversicherheit

Angriffe von Hackern, Crackern oder was auch immer, ob von innen oder außen. Hierüber muss man eigentlich keine Worte verlieren, außer vielleicht, wenn der Server nicht erreichbar ist, dann sind die Einnahmen gleich NULL. Sei dies nun durch einen Angriff oder aus irgendwelchen anderen Gründen.

Ausfallsicherheit

“Hast du für dein Startup eine Verfügbarkeitsanalyse?” oder noch schöner “Wie lange dürfen deine Seiten offline sein” oft wird dann mit Begriffen wie NIE oder “das geht gar nicht” hantiert.
Aber eine Hochverfügbare Weblösung braucht dann gewisse standards, die sich Web-Startups so gut wie nie leisten können. Hochverfügbarkeit hat ihren Preis. Die Administratoren hierfür auch. Redundante Server, Redundante Switche, doppelte Stromversorgung, USV, Backup und und und.
Also muss man irgendwo abstriche machen. Entweder an der Verfügbarkeit oder man muss sich eine andere Lösung überlegen mit der man halbwegs Leben kann

Entwicklungs- und Testumgebungen

Einige der neuen Web2.0 Startups arbeiten mit RubyonRails. Der Vorteil dieses Frameworks ist die Geschwindigkeit mit der entwickelt werden kann und vor allem viele kleine Tools, die bereits im Framework enthalten sind, die man bei anderen Sprachen, wie z.B. J EE das Tools ANT, extra mit in die Entwicklungsenviroments einbinden muss.

Auch die Entwicklungs und Testumgebunden bringt Rails von Hause aus schon mit. So kann man jeweils eine Datenbank für Development, Test und Produktion anlegen und auch verwenden.

Rails bringt sogenannte Migrations mit, die passend zu jeder Datenbanktabelle eine Migrationsscript mitbringt mit dem man auf die entsprechende Datenbankversion migrieren kann und weitere Tests durchführen kann/sollte !

Rundum sauber und sicher ist es dann wenn man mit den entsprechenden automatisierten Tests arbeitet. Jedes Modul, jede Funktion hat seinen eigenen Test. Verwendet man externe Module, dann kann man in der Regel davon ausgehen, dass diese bereits ausgiebig getestet wurden. Oder einfach erneut die mitgelierten Tests starten. Vertrauen ist gut – Kontrolle ist besser.

Automatisierte Tests

Integrtionstest, Modultests sind mehr als wichtig. Denn jedes Modul sollte bevor es von der Entwicklungsumgebung über die Test auf die Produktion kommt aus

Automatisches Deployment

Das automatische Deployment also die Anwendung vom Testserver auf den Staging Server und dann auf die Produktion zu spielen kann ganz easy mit GIT und Rake bzw. Capistrano gemacht werden. Manche Leute kennen sich mit Git,Rake,Capistrano wirklich verdammt gut aus. Sind aber im wirklichen Leben unbezahlbar – Danke

Ohne jetzt gleich wieder damit zubeginnen was Rails ist.

Rails ist cool

klar ist Rails cool und die Entwickler sowie die gesamte Community ist cool. Aber auch hier ist der schnöde Mammon, der der alles bestimmt. Konferenzen und Schulungen kosten mehr als ich in der Woche zum Leben habe.
Aber die Community steht zusammen und das Railscamp ist ein Beweis dafür, dass es auch günstiger gehen kann. (Leider schon ausgebucht)

Rails ist teuer

Naja nicht Rails an sich ist teuer. Sondern die Entwickler sind teuer. Denn immerhin bekommt man in der Regel keine PHP Scriptkiddies, die sinnlosen Spaghetticode zusammenbauen und sich dann freuen, dass es funktioniert.

Als die Railswelle hier nach Deutschland schwappe waren es überwiegen die J EE Entwickler, die bisher ihre Anwendungen mit JSF, JSP, Servlets oder Struts gebaut haben, die auf den Zug aufgesprungen sind. Agile Entwicklung kannte man bis dahin schon. Aber dass es auch so einfach sein kann, war genial. Man stürtze sich auf Active Record, Objektorientierte Programmierung und Migrations, weil es genial war iterati zu Entwicklen.

Rails kann solide sein

Wer gut programmiert kann auch gute Railsapplikationen schreiben. Das Grundprinzip von sauberem und vor allem wartbaren Code gilt hier wie überall anders auch. Wenn die Basis stimmt, dann kann man mit Rails sehr sehr guten Code entwickeln, mit sehr weniger Aufwand. Aus diesem Grund ist …. Rails verdammt schnell.

Rails ist schnell

Mit Rails kann man schnell Ergebnisse erzielen. Aber man kann ich auch sehr schnell auch ins Abseites schiessen, wenn man grundlegende Konzepte der Softwareentwicklung besonders aber der OOP außer acht läßt. Dann kann man schnell seinen Server überlasten. (ganz nebenbei, das konnte mein Wordpress aber auch)

In einer Zeit wo Web zwo Null Startups auf der Bildfläche erscheinen und genauso schnell wieder verschwunden sind wie sie da waren, sollte man auf ein Pferd setzen, dass nicht zuletzt guten Code abliefert. Da hinkt das Pferdebeispiel, denn da kommt hinten immer nur Mist raus. Aber egal.

Wir haben mit unsere Social News Plattform Poppster auf Rails gesetzt und bisher keine Minute bereut, dass wir es getan haben. Logisch ist aller Anfang schwer, aber das gestern beschriebene Deployment steht (vielleicht postet Fritz hier auch was dazu), der Server läuft stabil. Jetzt können die User kommen. Aber gerade genau hier liegt das Problem. Woher kommen die User? Woher der Traffic? Und vor allem welchen Sinn hat Poppster?

Das erfahrt ihr wenn ihr weiterhin brav mitlest.

Die Antwort darauf versucht jeder Glücksritter im Web zu finden. Hier ist nun die Wahrheit…

Zunächst einmal werden werden wir hier öffentlich unser Seelenleben ausbreiten. Und Euch daran teilhaben lassen, wie man von NULL auf 100 mit einem Startup startet. Manchmal mit ein paar riskanten Aktionen, manchmal mit solider Infrastruktur, die ein Supergau, wie beim Yigg Relaunch vermeiden sollte. Vor allem aber werden wir auf die wichtigsten Faktoren bei vielen Internet Startups eingehen.

Das Geld, Knete, Kohle, Zaster oder Cash genannt.

Oft – viel zu oft- wird hier auf externe Geldgeber oder BusinessAngels zurück gegriffen, die dann wiederum das weitere Geschehen bestimmen.

Wächst das Startup zu langsam foppen sich die Gründer selbst, startet es zu schnell, dann kommt man in die Lage, dass man mehr Arbeit als Arbeitskräfte hat und so beisst sich immer wieder die Katze in den Schwanz.

Wir wollen zwar nicht alles anders machen, aber ein paar Feinheiten haben wir hoffentlich gelernt. …..

Aber woran scheitern die meisten Startups im Internet und warum können einiges Startups nicht Fuss fassen andere hingegen umso besser?

Zunächst ist es erstmal wichtig, dass man sich überlegt ob und wie man seine Brötchen verdienen will. In vielen Fällen ist “Werbung” das Schlagwort. Richtig abhängigkeit von Google, Yahoo und anderen Werbepartner und die User sollens dann richten, in dem sie auf die entsprechenden Werbeads klicken.

Ständig fallen aber Klickraten, sprich die Unternehmen, die auf “werbefinanziert” gesetzt haben verdienen weniger. Die Kosten werden aber durch den Erfolg des Internetauftrittes höher und höher. Es reichen dann nicht mehr nur einfache Praktikanten, sondern es müssen dann richtig IT-Fachkräft ran. Oftmals liegt hier der Stundensatz bei Freelancern jenseits der 100 Euro pro Stunde, nach oben hin, wohlgemerkt.

Die Kosten werden höher die Einnahmen geringer. Man muss kein Prophet sein um zu wissen, dass dieses Rechenexempel letztlich vor dem Venture Capitalist oder beim Auktionator landet. Bekanntes Beispiel hierfür ist wohl Townster, steht jetzt bei Ebay zum Verkauf, für knapp 22.000 Euro (genau genommen sind es: 22.222 Euro) soll das ehemalige Vorzeigestartup bei Ebay verkloppt werden.

Aber was steckt denn jetzt an mehr BusinessModell in Townster als vorher? Wie soll man mit Townster Geld verdienen? Onlinewerbung?

FAkt ist dass man mit einer Community Geld verdienen kann, wenn man den richtigen Ansatz wählt. Wenn man allerdings darauf hofft irgendwann einen Geldgeber zu finden und keinerlei BusinessGedanken an das Startup verschwendet ist in Deutschland nicht wirklich gut aufgehoben.

Die Lösung wäre dann schon eher einen VC oder BusinessAngel zu suchen, der einen Unterstütz, aber was ist dann die Idee noch wert? Der VC sagt wo es lang geht man opfert sich für die eigene Idee und der VC bestimmt die Marschrichtung? Ein Startup ohne VC zu starten bedarf wirklicher Motivation und durchhalte vermögen. Manchmal kommt die Familie zu kurz häufig wird man zum genervten Manager und wirft alle Ideale über Board. zuletzt streitet man sich und landet bei Ebay.

Nichts desto weniger glaube ich an meine Idee ….