Es gibt einen Punkt, an dem No-Code-Tools und Standardsoftware nicht mehr reichen — wenn die Abläufe eines Unternehmens zu spezifisch werden, um sie in eine generische Lösung zu zwängen, oder wenn die Lizenzkosten für eine Software, die zu 70 Prozent passt, höher sind als eine massgeschneiderte, die zu 100 Prozent passt. Custom Software Engineering von Innopulse setzt hier an: Web-Plattformen, interne Werkzeuge, APIs und Datensysteme, gebaut für genau Ihren Anwendungsfall, EU-gehostet und so gebaut, dass der nächste Entwickler sie in einem Jahrzehnt noch warten kann.
Nicht jedes Problem braucht eine Eigenentwicklung. Authentifizierung, Zahlungsabwicklung, E-Mail-Versand — das sind gelöste Probleme, die man integriert, nicht nachbaut. Individualsoftware lohnt sich dort, wo ein Ablauf Ihre Differenzierung ausmacht: ein Kundenportal mit Ihrer spezifischen Logik, ein internes Tool, das einen manuellen Prozess ablöst, eine Datenpipeline, die genau Ihre Quellen zusammenführt. Die ehrliche Build-vs-Buy-Entscheidung ist Teil unserer Beratung, bevor wir eine Zeile Code schreiben — wir empfehlen auch mal, eine Standardlösung zu kaufen, wenn das die wirtschaftlichere Wahl ist.
Der Auslöser ist oft einer von dreien: Ein Unternehmen ist aus seinen Excel-Tabellen und manuellen Abläufen herausgewachsen, eine Standardsoftware passt zu schlecht oder ist zu teuer, oder ein neues Geschäftsmodell braucht ein digitales Produkt, das es noch nicht gibt. In allen drei Fällen geht es nicht um Technik um ihrer selbst willen, sondern um eine konkrete geschäftliche Wirkung: schnellere Abläufe, weniger Fehler, neue Umsatzquellen.
Unser Liefermodell ist senior-only. Die Ingenieure, deren Namen im Angebot stehen, schreiben den Code — es gibt keine Übergabe an ein Offshore-Implementierungsteam nach der Unterschrift. Das ist teurer pro Stunde und günstiger pro Projekt, weil die teuersten Fehler in der Lücke zwischen dem entstehen, der das Problem verstanden hat, und dem, der es umsetzt. Wer beides in einer Person hält, eliminiert diese Lücke.
Konkret heisst das: Sie sprechen mit den Leuten, die bauen. Architektur-Entscheidungen werden mit Ihnen besprochen, nicht über Ihren Kopf hinweg getroffen. Und wenn im Betrieb ein Problem auftaucht, weiss die Person am anderen Ende, wie das System funktioniert, weil sie es gebaut hat.
Unser Default-Stack ist bewusst opinionated: Next.js mit App Router für das Frontend und die API-Schicht, PostgreSQL als Datenbank, TypeScript durchgehend, gehostet auf Vercel oder in EU-Containern. Diese Wahl ist nicht die neueste, sondern die wartbarste. Next.js und PostgreSQL haben grosse Communities, langfristige Unterstützung und einen tiefen Pool an Entwicklern, die sie kennen — entscheidend, wenn das System Sie überleben soll. TypeScript fängt eine ganze Klasse von Fehlern ab, bevor sie in Produktion gehen.
Wo ein Projekt einen anderen Stack braucht, bekommt es einen. Aber die Default-Wahl folgt einem Prinzip: Technologie wird nach langfristiger Wartbarkeit gewählt, nicht nach technischer Neuheit. Eine Anwendung, die in fünf Jahren noch problemlos erweiterbar ist, ist mehr wert als eine, die heute mit dem neuesten Framework glänzt und morgen niemand mehr pflegen kann.
Für DACH-Unternehmen ist Datenresidenz keine technische Fussnote, sondern eine Compliance- und zunehmend eine Vertriebsfrage. Wir bauen Datenresidenz in der EU oder der Schweiz von der ersten Tabelle an in die Architektur ein — nicht als nachträgliche Schicht. DSGVO und revDSG werden auf Datenmodell-Ebene berücksichtigt: Datenminimierung, Verschlüsselung, Mandantentrennung über Row-Level-Security und ein Datenexport, der dem Betroffenenrecht in Sekunden nachkommt. Das ist deutlich billiger, wenn es von Anfang an mitgedacht wird, als wenn es nachträglich eingebaut werden muss.
Das Spektrum reicht von Web-Anwendungen und Kundenportalen über interne Tools und Admin-Dashboards bis zu APIs, Integrationsschichten und Datenpipelines. Wir modernisieren auch Legacy-Systeme — die heikelste Disziplin, weil sie verlangt, ein laufendes System zu ersetzen, ohne den Betrieb zu unterbrechen. Unsere eigene Produkterfahrung hilft hier: Wir haben sieben SaaS-Produkte gebaut und betrieben und kennen die Muster, die im echten Betrieb halten — von der Authentifizierung über das Billing bis zur Observability.
Die meisten Softwarekosten entstehen nicht bei der ersten Entwicklung, sondern in den Jahren danach — bei jeder Änderung, jeder Erweiterung, jedem neuen Entwickler, der sich einarbeiten muss. Wartbarkeit ist deshalb keine Eigenschaft, die man am Ende hinzufügt, sondern eine Reihe von Entscheidungen, die durch das gesamte Projekt ziehen: klare Modulgrenzen, durchgehende Typisierung mit TypeScript, automatisierte Tests an den richtigen Stellen, lesbarer Code statt cleverer Code, und eine Dokumentation, die erklärt, warum etwas so gebaut ist, nicht nur wie. Wir bauen so, dass der nächste Entwickler — ob bei Ihnen intern oder bei uns — das System in einem Jahr noch versteht und sicher ändern kann.
Sicherheit ist kein Feature, das man verkaufen kann, sondern eine Voraussetzung, deren Fehlen erst beim Vorfall auffällt — dem teuersten möglichen Zeitpunkt. Jedes System, das wir bauen, startet auf einer Sicherheits-Baseline, unter die wir nicht gehen: Mehr-Faktor-Authentifizierung als Standard, Verschlüsselung in Ruhe und Transport, Secrets ausserhalb des Codes, aktuelle Abhängigkeiten und getestete Backups. Bei Anwendungen mit mehreren Mandanten kommt strikte Trennung über Row-Level-Security dazu, sodass die Daten eines Kunden technisch nicht in die Reichweite eines anderen gelangen können. Diese Disziplin ist unspektakulär und genau deshalb wirksam.
Software, die monatelang im Verborgenen entsteht und dann auf einen Schlag ausgeliefert wird, birgt das grösste Risiko: Erst am Ende zeigt sich, ob das Gebaute trifft, was gebraucht wird. Wir liefern iterativ in zwei- bis vierwöchigen Sprints, mit funktionierender Software am Ende jedes Sprints. Sie sehen echten Fortschritt, nicht Statusberichte, und können früh nachsteuern, wenn sich Anforderungen klären — was sie während fast jedes Projekts tun. Diese Arbeitsweise senkt das Risiko dramatisch und sorgt dafür, dass das fertige Produkt das löst, was es lösen soll, nicht das, was im ursprünglichen Konzept stand.
Warum Innopulse für Softwareentwicklung Viele Entwicklungsdienstleister liefern Code und verschwinden. Innopulse denkt in Lebenszyklen. Wir bauen Software, die wir selbst betreiben würden — und in vielen Fällen tatsächlich betreiben, denn unser eigenes Portfolio läuft auf denselben Mustern. Das verändert die Anreize: Wer ein System langfristig betreibt, baut es wartbar, sicher und beobachtbar, statt nur die Abnahme zu bestehen. Unsere Kunden profitieren von Engineering-Entscheidungen, die mit dem zweiten und dritten Jahr im Blick getroffen werden, nicht nur mit dem Liefertermin. Dazu kommt die Senior-Only-Lieferung: Sie arbeiten mit erfahrenen Ingenieuren zusammen, von der ersten Architektur-Skizze bis zum Go-live, ohne Übergabe an ein anonymes Implementierungsteam. Und Sie behalten die volle Kontrolle — Quellcode, Zugangsdaten und Dokumentation gehören zu jedem Zeitpunkt Ihnen, ohne Lock-in. Für ein Unternehmen, das Software als langfristige Investition versteht und nicht als Wegwerfprodukt, ist diese Haltung der entscheidende Unterschied. Wir bauen nicht das, was am schnellsten abnahmefähig ist, sondern das, was über Jahre trägt.
Wenn Sie eine Software brauchen, die es so noch nicht gibt, oder ein bestehendes System, das Sie ausbremst, ersetzen wollen, lassen Sie uns reden. Schreiben Sie an info@innopulse.io — wir scopen ehrlich, nennen einen realistischen Rahmen und sagen Ihnen auch, wenn eine Standardlösung die bessere Wahl wäre.