Individuelle Softwareentwicklung, die Ihren Prozessen folgt, nicht umgekehrt.

Was ist individuelle Softwareentwicklung, und wann reicht Standardsoftware?

Individuelle Softwareentwicklung heißt: Wir entwickeln eine Anwendung genau für Ihre Prozesse, Ihre Daten und Ihre Nutzer, statt Ihr Team an ein fertiges Produkt anzupassen. Das Ergebnis heißt Individualsoftware. Standardsoftware nutzen dagegen viele Firmen in derselben Form, denn sie ist für den Durchschnitt gebaut. Typische Beispiele für Individualsoftware sind ein Kundenportal, ein Admin Panel für interne Abläufe oder ein eigenes SaaS Produkt.

Ehrlich gesagt brauchen viele Unternehmen keine eigene Software. Denn für Buchhaltung, E-Mail, Chat oder einen üblichen Vertriebsprozess ist eine fertige Lösung meist günstiger und schneller startklar. Individualsoftware lohnt sich vor allem, wenn einer dieser Punkte zutrifft:

• Ihr Prozess ist Ihr Wettbewerbsvorteil und passt in kein Standardprodukt.
• Ihr Team pflegt dieselben Daten in drei Tools und zusätzlich in Excel.
• Lizenzen pro Nutzer wachsen schneller als der Nutzen.
• Sie brauchen Schnittstellen, die kein Anbieter vorsieht.

Wirtschaftlich lohnt sich ein Vergleich über drei bis fünf Jahre. Stellen Sie Lizenzen pro Nutzer, Zusatzmodule und manuelle Arbeit den Kosten für Entwicklung, Hosting und Wartung gegenüber. Zudem zählt, was keine Tabelle zeigt: doppelte Dateneingabe, Fehler beim Übertragen und Abläufe, die das Standardprodukt schlicht nicht abbildet.

Außerdem grenzen wir sauber ab. Die Unternehmenswebsite entsteht im Webdesign, Apps für iOS und Android in der App Entwicklung und der Onlineshop in der E-Commerce Beratung. Schwanken Sie zwischen einem Baukasten und eigener Entwicklung, hilft zudem unser Vergleich WordPress oder individuelle Website bei der Einordnung.

Welche Anwendungen entwickeln wir: Portale, SaaS, interne Tools und APIs?

Unsere Projekte haben eines gemeinsam: Hinter der Oberfläche stehen Geschäftsregeln, Rollen und Daten, die zuverlässig zusammenspielen müssen. Diese Anwendungstypen bauen wir am häufigsten:

• Kundenportale und Händlerportale: Bestellungen, Dokumente, Tickets und Auswertungen an einem Ort, mit eigenem Zugang pro Kunde.
• Admin Panels und interne Tools: Freigaben, Planung, Lager oder Außendienst an einer Stelle statt in verstreuten Tabellen.
• SaaS Produkte: mandantenfähige Anwendungen mit Abos, Rollen und getrennten Daten pro Kunde.
• APIs und Integrationsschichten: Dienste, die Ihre Systeme verbinden oder Partnern Daten sicher bereitstellen.
• Modernisierung von Altsystemen: Ablösung alter Software in Etappen, ohne den laufenden Betrieb zu stoppen.

Konkret kann das je nach Branche so aussehen: in der Logistik ein Portal für Sendungsstatus und Lieferscheine, in einer Versicherungsagentur ein Angebotsprozess mit Freigaben, in der Produktion die Verwaltung von Arbeitsaufträgen. Das sind allerdings Beispiele für Aufgaben, keine Referenzprojekte.

Wenn Sie eine Webanwendung entwickeln lassen, läuft sie im Browser, braucht keine Installation und erhält Updates zentral auf dem Server. Braucht Ihr Team die Anwendung zusätzlich unterwegs, ergänzen wir eine PWA oder eine native App über unsere App Entwicklung.

Den Technologiestack wählen wir nach Anforderungen, nicht nach Gewohnheit. Ein typischer Stack ist Laravel, React und PostgreSQL; je nach Projekt setzen wir auch Node.js oder MySQL ein. Wie wir Sprachen und Architektur abwägen, zeigt zum Beispiel unser Vergleich von Python und Go. Auf welcher Technik Ihre heutige Website läuft, prüfen Sie dann mit unserem CMS Checker.

Warum beginnt jedes Projekt mit einer Discovery Phase?

Die Discovery ist der günstigste Moment, um Fehler zu finden, weil sie dort noch auf Papier stehen und nicht im Code. Deshalb berechnen wir sie separat zu einem Festpreis. Beauftragen Sie uns danach mit der Entwicklung, rechnen wir den Betrag voll an.

In drei bis vier Wochen entstehen diese Ergebnisse:

• Workshops: Gespräche mit den Menschen, die den Prozess heute ausführen, nicht nur mit der Geschäftsführung.
• Prozesslandkarte: Abläufe, Rollen, Sonderfälle und Freigaben auf einer Seite.
• Datenmodell und Architektur: Welche Daten liegen wo, und wie sprechen die Systeme miteinander?
• Klickbarer Prototyp: die Kernabläufe zum Ausprobieren, bevor Code entsteht.
• Umfangsdokument und Festpreisangebot: Funktionen, Abnahmekriterien, Annahmen und Ausschlüsse.

Außerdem benennen wir Risiken offen, etwa Schnittstellen ohne Dokumentation, unklare Zuständigkeiten oder Daten in schlechter Qualität. Jedes Risiko erhält im Umfangsdokument eine Annahme oder einen Plan B.

Oft fragen Kunden nach Lastenheft und Pflichtenheft. Kurz gesagt beschreibt das Lastenheft, was Sie als Auftraggeber brauchen. Das Pflichtenheft legt dann fest, wie der Auftragnehmer es umsetzt. Ein fertiges Lastenheft müssen Sie nicht mitbringen, denn eine Seite mit Zielen, Nutzern und Problemen genügt. Unser Umfangsdokument übernimmt danach die Rolle des Pflichtenhefts.

Wie Sie Ihr Vorhaben vorab strukturieren, zeigt unser Beitrag zum Planen ohne strategische Fehler. Die Prinzipien gelten für Software ebenso.

Wie grenzen wir ein MVP sinnvoll ab?

Ein MVP (Minimum Viable Product) ist die kleinste Version Ihrer Software, die den Kernnutzen im echten Betrieb beweist. Es ist also kein Prototyp zum Wegwerfen, sondern die erste produktive Ausbaustufe mit sauberer Architektur. Der teuerste Fehler ist, jede Idee aus allen Abteilungen in diese erste Version zu packen.

Zwei verwandte Begriffe klären wir dabei gleich mit. Ein Proof of Concept prüft, ob eine technische Idee überhaupt funktioniert, etwa eine heikle Schnittstelle. Ein Prototyp zeigt dagegen, ob Nutzer den Ablauf verstehen. Das MVP beweist schließlich, dass die Software im echten Betrieb Nutzen stiftet.

Darum sortieren wir alle Anforderungen in der Discovery in drei Gruppen:

• Pflicht: Ohne diese Funktionen läuft der Kernprozess nicht.
• Nächstes Release: wichtig, aber erst sinnvoll, wenn die ersten Nutzer arbeiten.
• Später oder nie: Wünsche, deren Nutzen noch niemand gemessen hat.

Zum Beispiel gehören bei einem Portal für Händler Login, Bestellung, Status und Rechnungsdownload in die erste Version. Rabattlogik pro Region, Chat und Auswertungen für die Geschäftsführung warten dagegen auf Release zwei. Somit fließt Ihr Budget zuerst in Funktionen, die Menschen täglich nutzen.

Danach entwickeln wir in Sprints von zwei Wochen. Nach jedem Sprint testen Sie eine lauffähige Version und priorisieren dann gemeinsam mit uns neu. Wie dieses Vorgehen im Alltag funktioniert, erklärt unser Beitrag zu agilem Projektmanagement mit Scrum und Kanban. Vor dem Livegang hilft außerdem unsere Checkliste für Tests vor dem Livegang.

Wie binden wir ERP, CRM und Buchhaltung an?

Individualsoftware entfaltet ihren Wert erst, wenn sie mit Ihren bestehenden Systemen spricht. Konkret tauscht eine Schnittstelle, kurz API, Daten nach festen Regeln aus. Zum Beispiel fließen Aufträge ins ERP, Kontakte ins CRM und Rechnungsdaten in die Buchhaltung. Eine Schnittstelle, die nur im Normalfall funktioniert, ist allerdings ein Risiko. Daher planen wir jede Anbindung mit diesen Bausteinen:

• Dokumentierte Verträge: Felder, Formate und Zuständigkeiten stehen schriftlich fest.
• Webhooks und Warteschlangen: Ereignisse kommen zeitnah an, und Lastspitzen blockieren nichts.
• Idempotenz: Eine doppelt gesendete Nachricht erzeugt keinen doppelten Auftrag.
• Wiederholungen und Alarme: Fällt ein System aus, holt die Anbindung Nachrichten später nach und meldet dauerhafte Fehler.
• Protokolle: Jeder Datenaustausch bleibt nachvollziehbar.
• Anmeldung über Firmenkonten: Für interne Tools binden wir auf Wunsch Single Sign On an, etwa mit Microsoft oder Google.

Außerdem prägt die Qualität der Gegenseite den Aufwand stark. Ein modernes ERP mit sauberer REST API lässt sich schneller anbinden als ein Altsystem, das nur CSV Exporte kennt. Deshalb prüfen wir Zugänge und Dokumentation schon in der Discovery. Einen Überblick über typische Anbindungen gibt unser Leitfaden CRM, ERP und Chatbot anbinden. Für Portale, die Leads direkt weitergeben, lohnt zudem unser Beitrag zur CRM Anbindung der Website.

Wer erhält die Rechte am Quellcode?

Bei Software entscheidet der Vertrag, nicht die Rechnung. Das Urheberrechtsgesetz schützt Computerprogramme in jeder Gestalt, einschließlich des Entwurfsmaterials (§ 69a UrhG). Schreibt ein Arbeitnehmer das Programm im Rahmen seiner Aufgaben, stehen die vermögensrechtlichen Befugnisse nach § 69b UrhG dem Arbeitgeber zu. Für eine externe Agentur gibt es allerdings keine solche automatische Regel. Deshalb muss der Vertrag festhalten, welche Nutzungsrechte Sie erhalten.

Unser Standard sieht so aus:

• Ausschließliche Nutzungsrechte: Am individuell für Sie entwickelten Quellcode erhalten Sie vertraglich ausschließliche, zeitlich und räumlich unbeschränkte Nutzungsrechte.
• Einzeln benannte Nutzungsarten: Bearbeiten, Vervielfältigen, Weitergeben und Weiterentwickeln stehen ausdrücklich im Vertrag. Sonst bestimmt nach § 31 Absatz 5 UrhG der Vertragszweck, wie weit die Rechte reichen.
• Repository und Konten ab Tag eins: Git Repository, Cloud Konto und Domain laufen auf Ihren Namen. Unser Team arbeitet über Rollen, daher brauchen wir Ihr Passwort nie.
• Liste der Open Source Lizenzen: Bibliotheken bleiben unter ihren eigenen Lizenzen, und die vollständige Liste erhalten Sie mit der Übergabe.

So stellt sich die Frage nach der Herausgabe des Quellcodes gar nicht erst, weil er nie woanders lag. Den Vertrag prüfen Partneranwälte im eigenen Mandat oder Ihre eigene Rechtsberatung; eine Rechtsberatung durch uns findet nicht statt. Wie Sie Domains, Konten und Zugänge insgesamt in der eigenen Hand halten, zeigt unser Beitrag zur Verwaltung digitaler Assets. Starke Zugangsdaten für Ihr Team erzeugt unser Passwort Generator.

Wie sichern wir Webanwendungen nach OWASP ab?

Sicherheit lässt sich nicht am Ende hineintesten, sie entsteht im Design. Deshalb nutzen wir als Grundlage zwei Standards der OWASP Foundation. Die OWASP Top 10 beschreiben die häufigsten Risiken für Webanwendungen; in der Ausgabe von 2025 stehen fehlerhafte Zugriffskontrolle, Fehlkonfiguration und Schwachstellen in der Lieferkette der Software ganz oben. Der OWASP ASVS in Version 5.0.0 liefert zudem prüfbare Anforderungen in drei Stufen.

In der Praxis heißt das:

• Zugriffskontrolle auf dem Server: Jede Anfrage prüft Rolle und Mandant, nicht nur die Oberfläche.
• Anmeldung: sichere Regeln für Passwörter, ein zweiter Faktor für Admins und kurzlebige Sitzungen.
• Eingaben und Abfragen: Jede Eingabe prüft der Server, und Datenbankabfragen nutzen Parameter statt zusammengesetzter Texte, denn so bleibt Injection außen vor.
• Geheimnisse: API Schlüssel liegen in einem Tresor oder in Umgebungsvariablen, nie im Repository.
• Lieferkette: Abhängigkeiten prüfen wir automatisch auf bekannte Schwachstellen.
• Protokolle und Backups: Sicherheitsrelevante Ereignisse bleiben nachvollziehbar, und Wiederherstellungen testen wir regelmäßig.

Welche ASVS Stufe Ihr Projekt anstrebt, halten wir im Umfangsdokument fest. Eine Garantie auf Sicherheit gibt dagegen niemand seriös. Bei sensiblen Daten empfehlen wir daher zusätzlich einen unabhängigen Penetrationstest. Die zehn Risiken erklärt unser Beitrag zu den OWASP Top 10 ausführlich. Ob das Zertifikat Ihrer heutigen Domain korrekt eingerichtet ist, zeigt unser SSL Check.

DSGVO, AVV und BFSG: Was gilt für Ihre Software?

Verarbeitet Ihre Software personenbezogene Daten, gilt die DSGVO von der ersten Tabelle an. Artikel 25 verlangt Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Konkret heißt das bei uns: nur nötige Felder, Rollen mit minimalen Rechten, Löschfristen im Code und Protokolle ohne unnötige Personendaten.

Hostet oder wartet unser Team eine Anwendung mit personenbezogenen Daten, verarbeiten wir diese in Ihrem Auftrag. Dann braucht es einen Vertrag zur Auftragsverarbeitung (AVV) nach Artikel 28 DSGVO. Er regelt Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der Daten und die Pflichten beider Seiten. Außerdem setzen wir weitere Unterauftragsverarbeiter nur mit Ihrer schriftlichen Genehmigung ein. Weil unser Unternehmen seinen Sitz in der Türkei hat, kommen zudem die Standardvertragsklauseln der Europäischen Kommission hinzu.

Beim Barrierefreiheitsstärkungsgesetz (BFSG) lohnt ein genauer Blick. Es gilt für bestimmte Dienstleistungen an Verbraucher, etwa im elektronischen Geschäftsverkehr oder im Bankwesen, und zwar seit dem 28. Juni 2025. Kleinstunternehmen, die Dienstleistungen erbringen, nimmt es zudem aus. Ein reines B2B Portal oder ein internes Tool fällt daher in der Regel nicht darunter. Trotzdem planen wir Oberflächen nach WCAG 2.2 AA, weil barrierefreie Software für alle Nutzer besser funktioniert.

Kontraste prüfen Sie mit unserem Kontrastrechner. Unsere Beiträge zur barrierefreien Website nach BFSG und zum DSGVO Leitfaden vertiefen beide Themen. Rechtstexte und AVV erstellen Partneranwälte im eigenen Mandat.

Festpreis oder Aufwand: Wie rechnet man individuelle Softwareentwicklung ab?

Für die Abrechnung gibt es zwei gängige Modelle, und beide haben ihren Platz. Beim Festpreis steht der Umfang schriftlich fest, und der Preis gilt für genau diesen Umfang. Das passt vor allem, sobald die Discovery Prozesse, Schnittstellen und Abnahmekriterien geklärt hat. Neue Wünsche während der Entwicklung sind dann Änderungswünsche mit eigenem Angebot. Sie zahlen dabei in Etappen nach Meilensteinen, zum Beispiel nach Freigabe des Prototyps, nach wichtigen Sprints und nach dem Livegang.

Bei Abrechnung nach Aufwand, oft Time and Material genannt, zahlen Sie die tatsächlich geleistete Zeit, meist pro Sprint. Das passt zu Produkten, deren Richtung sich mit jedem Nutzerfeedback ändert, etwa bei einem neuen SaaS. Damit das Budget planbar bleibt, vereinbaren wir ein Kostendach pro Sprint oder pro Quartal. Den Verbrauch sehen Sie außerdem jederzeit offen im CRM.

In der Praxis kombinieren wir oft beides: Discovery und MVP zum Festpreis, danach Weiterentwicklung nach Aufwand mit Kostendach. Juristisch ordnen Fachleute solche Verträge meist als Werkvertrag oder Dienstvertrag ein. Welche Einordnung für Ihr Projekt passt, klären Sie bitte mit Ihrer Rechtsberatung. Ebenso gehört die Frage, wie Sie Individualsoftware bilanzieren und abschreiben, in die Hände Ihrer Steuerberatung.

Den Festpreis der Discovery, den Startpreis der MVP Webanwendung und die Basis für das Enterprise Paket finden Sie im Bereich Preise auf dieser Seite. Angebote vergleichen Sie am besten Position für Position; worauf es dabei ankommt, zeigt unsere Checkliste zum Vergleich von Angeboten.

Wartung, SLA und Übergabe: Was passiert nach dem Livegang?

Mit dem Livegang beginnt der längste Abschnitt im Leben einer Software. Denn Frameworks, Bibliotheken und Browser ändern sich laufend, und neue Schwachstellen in Abhängigkeiten tauchen jede Woche auf. Ein Wartungsvertrag deckt deshalb vier Arten von Arbeit ab:

• Korrektive Wartung: Fehler beheben, kritische zuerst.
• Adaptive Wartung: Updates von Framework, Laufzeit und Schnittstellen, wenn sich die Umgebung ändert.
• Präventive Wartung: Sicherheitspatches, Backups und Monitoring, bevor etwas passiert.
• Weiterentwicklung: neue Funktionen nach einer gemeinsamen Roadmap.

Monitoring gehört ebenso dazu: Fehlerberichte, Antwortzeiten und Auslastung beobachten wir laufend, damit wir Probleme oft bemerken, bevor Ihre Nutzer sie melden.

Ein SLA (Service Level Agreement) legt fest, wie schnell wir reagieren und bis wann wir eine Störung beheben wollen. Wichtig ist der Unterschied: Die Reaktionszeit misst die erste qualifizierte Antwort, das Lösungsziel die Behebung. Außerdem gehören Servicezeiten, Prioritätsstufen und Ausschlüsse in den Vertrag. Konkrete Werte vereinbaren wir im Enterprise Paket schriftlich, statt pauschale Prozentzahlen zu versprechen. Die Erreichbarkeit Ihrer Anwendung prüfen Sie jederzeit mit unserem Tool Ist die Seite down?.

Zur Übergabe gehören Repository, Dokumentation, Zugänge und eine Einweisung für Ihr Team oder einen neuen Dienstleister. Bevor Sie sich für einen Partner entscheiden, fragen Sie deshalb: Wo liegt das Repository? Wer hält die Rechte? Welche Tests und Sicherheitsstandards gelten? Wie sieht der Ausstieg aus? Unsere Arbeiten sehen Sie unter Referenzen, und über den Kontakt sprechen wir über Ihr Vorhaben.