Klarer Prozess.
Besseres Resultat.
Verstehen. Planen. Bauen. Wachsen. Vier Phasen, die aus einer Idee etwas machen, das bleibt – und ein ehrliches Gespräch am Anfang, in dem sich entscheidet, ob überhaupt gebaut werden soll.
Keine Magie.
Einfach sauber gemacht.
Jedes Projekt durchläuft dieselben vier Phasen, ob kleines internes Werkzeug oder System, an dem ein Betrieb hängt. Wie lange eine dauert, hängt vom Projekt ab – dass sie stattfindet, nicht.
Verstehen
Wir beginnen beim Problem, nicht bei der Lösung. Für wen ist es, was steht im Weg, und was wäre tatsächlich besser?
Planen
Umfang, Architektur, Budget. Wir zeichnen die Route, bevor jemand Code schreibt – so bleiben Überraschungen klein.
Bauen
Kurze Iterationen, lauffähige Software, keine Blackbox. Die Sache wächst vor aller Augen, statt am Schluss enthüllt zu werden.
Wachsen
Der Launch ist der Anfang. Wir messen, verfeinern und halten das Produkt lange nach dem ersten Release am Leben.
Zuerst das Problem,
dann die Idee.
Im ersten Gespräch beschnuppern wir uns gegenseitig. Worum geht es, und sind wir die Richtigen für die Umsetzung? Wenn nicht, ist das früh gesagt für alle billiger, als es spät zu merken.
Und wir wollen mehr als die Idee – wir wollen die Abläufe dahinter. Erst wenn man die sprichwörtlichen hundert Schritte in fremden Schuhen gegangen ist, lässt sich sagen, was gebaut gehört und was man besser lässt.
Wir widersprechen
In dieser Phase sind wir Sparringspartner, nicht Auftragnehmer. Wir denken mit und widersprechen, wenn wir einen besseren Vorschlag haben – und drehen den Ansatz so lange um, bis alle überzeugt sind, den richtigen gefunden zu haben.
Ein Richtpreis, bevor es losgeht
Sobald klar ist, worum es geht, machen wir eine erste Schätzung für einen Richtpreis. Passt die Grössenordnung, geht es weiter. Passt sie nicht, hat das Gespräch trotzdem etwas gebracht.
Die Route zeichnen,
bevor jemand losfährt.
Im Kick-off-Workshop klären wir den Umfang, erarbeiten gemeinsam die Details, setzen Meilensteine und legen eine Zeitplanung fest. Was dabei entsteht, ist kein Papier für die Ablage, sondern die Grundlage für eine verbindliche Offerte.
Aus der Schätzung wird eine Offerte
Mit dem gemeinsam erstellten Pflichtenheft wird die erste Preisschätzung präzisiert, Fehlendes ergänzt und die definitive Offerte gerechnet. Zwei Stufen statt einer Zahl aus dem Bauch – und die zweite hält.
Architektur ist auch Planung
Wie weit muss es wachsen? Welche Form haben die Daten? Was muss angebunden werden? Diese Fragen gehören hierhin und nicht in die dritte Entwicklungswoche, wo die Antwort teuer wird.
Sichtbar wachsen,
nicht hinter dem Vorhang.
Erst Wireframes, dann Mockups und Prototypen, immer in enger Zusammenarbeit. Danach wird fortlaufend entwickelt und getestet, neue Ideen werden besprochen und aufgenommen statt auf eine zweite Phase vertröstet, die nie kommt.
Es gibt keinen Moment, in dem etwas Fertiges enthüllt wird. Es gibt viele Momente, in denen etwas Halbfertiges besprochen wird. Das ist unbequemer und führt zu besseren Ergebnissen.
Geprüft, nicht angenommen
Wenn wir glauben, richtig zu liegen, prüfen wir es mit echten Nutzern. Wir schauen bei jedem Schritt zu und sehen, wo es hakt – meistens an einer Stelle, die niemand vermutet hätte, und genau deshalb lohnt sich das Zuschauen.
Wer baut, redet auch mit
Keine Beratungsschicht dazwischen, keine stille Post zwischen Briefing und Entwicklung. Fragen gehen direkt an die Person, die es schreibt – der Hauptgrund, warum kleine Teams schneller sein können als grosse.
Der Launch ist
der Anfang.
Nach dem Testing geht das Produkt live. Danach halten wir es am Laufen und entwickeln es weiter – kein Zusatzangebot, sondern der Teil, in dem sich entscheidet, ob sich die Investition gelohnt hat.
Betrieb gehört dazu
Updates, Monitoring, Backups und eine Nummer, an der jemand abnimmt. Das meiste, was wir bauen, läuft auf unserer eigenen Infrastruktur in der Region Bern – deshalb ist die Antwort auf «wer kann jetzt nachsehen» selten kompliziert.
Die besten Erweiterungen kommen aus dem Gebrauch
Nicht aus einem Roadmap-Workshop, sondern aus einem Satz, der bei der Arbeit nebenbei fällt. Das sind die Ergänzungen, die benutzt werden, weil sie vorher jemand vermisst hat.
Lieber einmal mehr
gezeigt als beschrieben.
Bevor etwas gebaut wird, machen wir es sichtbar: Skizzen, ein klickbares Mockup, ein Prototyp, der sich schon ungefähr so verhält wie das fertige Produkt. Das ist Zusatzaufwand am Anfang, und den nehmen wir gern auf uns – eine Entscheidung vor etwas, das man tatsächlich sieht, fällt anders aus als eine Entscheidung vor einer Beschreibung.
Eine Änderung im Prototyp kostet eine Stunde. Dieselbe Änderung in der fertigen Software kostet eine Woche. Das ist das ganze Argument.
Was dabei herauskommt
Derselbe Weg,
egal was gebaut wird.
Eine Website, eine App, ein System, an dem ein Betrieb hängt, ein Stück KI in einem bestehenden Ablauf – an den vier Phasen ändert das nichts. Nur an der Länge der einzelnen.
Was wir bauenWomit wir uns sonst
noch beschäftigen.
Es beginnt mit
einem Gespräch.
Keine Vorbereitung nötig, kein Pflichtenheft verlangt. Beschreib, was im Weg steht – der Rest ist unsere Aufgabe.