Was gebaut wird: Web-App-Entwicklung mit Geschäftszweck
Vor allem Webanwendungen, denn dort treffen ein Geschäftsproblem und ein Browser aufeinander. Der rote Faden: Jede ersetzt etwas, das vorher von Hand, in einer Tabelle oder in einem Tool erledigt wurde, das fast gepasst hat.
- SaaS-Entwicklung: Multi-Tenant vom ersten Tag an, mit Abrechnung, Testphasen, Rollen und der Admin-Seite, die niemand einplant
- MVP-Entwicklung: die kleinste Version, die einem echten Kunden Geld abnehmen kann - gebaut, um erweitert zu werden, nicht um weggeworfen zu werden
- Interne Tools und Backoffices: Dashboards, Freigabeprozesse, Disposition, Reporting - die Software, mit der Ihr Team tatsächlich den ganzen Tag arbeitet
- Kundenportale und Self-Service: Konten, Dokumente, Bestellungen und Anfragen, verbunden mit dem System, in dem die Wahrheit liegt
- Prozessautomatisierung und KI-Automatisierung: Dokumenten- und Datenpipelines, Integrationen zwischen Systemen, und KI dort, wo sie echte Arbeit abnimmt, statt eine Chatbox hinzuzufügen
- E-Commerce an den Rändern: Headless-Storefronts, eigene Integrationen und die Apps, die ein PrestaShop- oder Shopify-Shop braucht, aber nicht kaufen kann
Individualsoftware von einer Person, die sie auch verkaufen muss
Ein Softwarehaus verkauft Ihnen einen Projektleiter, einen Designer, einen Entwickler und einen QA-Ingenieur - und übergibt Ihnen dann ein Produkt ohne Kunden. Die zwei Produkte, die mir gehören - svezapausal.rs für pauschalbesteuerte Selbstständige in Serbien und AdvokatX für Anwaltskanzleien -, habe ich entworfen, gebaut, bepreist, vermarktet und betreue sie bis heute. Beide gewinnen ihre Nutzer über kostenlose Tools und Ratgeber, die genau die Fragen beantworten, die Menschen bei Google eintippen - ein Marketing, an das ein Entwickler normalerweise nicht denkt und das ein Marketer normalerweise nicht bauen kann.
Das ist der Unterschied, den ich verkaufe. Die Architektur ist darauf ausgelegt, wie das Produkt gefunden und bezahlt wird, nicht nur darauf, wie es läuft. Das SEO steckt im ersten Commit. Das Onboarding schreibt die Person, die die Registrierung gebaut hat. Und wenn um neun Uhr abends etwas bricht, antwortet die Person, die es geschrieben hat.
So läuft ein Projekt: von der Idee zum ersten zahlenden Kunden
Es beginnt mit dem Problem, nicht mit der Feature-Liste: Wer hat es, was kostet es ihn heute, was würde er zahlen, um es loszuwerden. Daraus entsteht ein kurzes Architekturdokument - Datenmodell, Systemgrenzen, was gebaut und was gekauft wird - und ein MVP-Umfang, der klein genug ist, um in Wochen statt Quartalen live zu gehen.
Gebaut wird in Schritten auf einer Staging-Umgebung, die Sie öffnen können, jede Änderung in der Versionskontrolle und über eine Pipeline ausgeliefert - es gibt nie eine große Enthüllung. Der Launch ist eine Checkliste, kein Ereignis: Domains, Analytics, Search Console, Fehlerüberwachung, Backups, eine Support-Adresse. Danach messen wir, was Nutzer tun, und iterieren darauf - nicht auf Meinungen.
Der Code gehört Ihnen, in Ihrem Repository, dokumentiert. Nichts bindet Sie an mich, und die Leute, die ich für einen größeren Umfang dazuhole, sind solche, mit denen ich bereits geliefert habe. Umfang und Kosten hängen vom Problem ab, das vor mir liegt - deshalb gibt es keine Preistabelle. Nennen Sie mir das Problem, und ich sage Ihnen, was es braucht.
Prozessautomatisierung und KI, wo sie sich auszahlen
Die meisten Automatisierungsanfragen sind in Wahrheit der Wunsch, eine wiederkehrende Sache nicht mehr zu tun: Bestellungen neu eintippen, Dokumenten nachlaufen, Daten von einem System ins andere kopieren, Logs von Hand lesen. Das löst man mit Integrationen und kleinen Services, nicht mit Plattformen. Meine eigenen Werkzeuge baue ich genauso - ein Search-Console-Archiv, das Googles Aufbewahrungsfrist überlebt, ein Kommandozeilen-Tool zur Inhaltsanalyse, Log-Reader -, und derselbe Ansatz funktioniert im Unternehmen eines Kunden.
KI kommt dort hinein, wo sie echte Arbeit abnimmt: Dokumente klassifizieren und auslesen, aus strukturierten Daten Entwürfe erzeugen, aus einem bekannten Korpus antworten, Anfragen weiterleiten. Sie bleibt draußen, wo eine Regel reicht - denn eine Regel ist billiger, schneller und halluziniert nicht. Die Architektur entscheidet das pro Aufgabe, und ich sage Ihnen, was was ist.
Der Stack - und warum
Next.js und React, wenn das Produkt öffentlich ist und Suche zählt, weil Server-Rendering und Core Web Vitals eingebaut sind. Vue und Nuxt, wenn ein Team bereits dort zu Hause ist. Laravel, wenn das Produkt eine Geschäftsanwendung mit Rollen, Abrechnung und Reporting ist - AdvokatX läuft auf Laravel, Inertia und Vue. Node und Express für Services, Integrationen und Echtzeit. Darunter PostgreSQL oder MySQL, darüber AWS oder Vercel, und eine CI-Pipeline ab der ersten Woche.
Zehn Jahre damit, an Produkten, die noch laufen. Wer einen Laravel-Entwickler, einen Node.js-Entwickler oder einen Freelancer für Webentwicklung sucht, sucht - ehrlich gesagt - jemanden, der zwischen diesen Werkzeugen für sein Problem wählen kann. Genau dafür werde ich beauftragt.
