Backend Entwicklung beginnt
bei eurer Fachlichkeit.
Eure Regeln, eure Daten und die Anschlüsse nach außen. Gebaut auf einem Fachmodell statt auf Endpunkten über einer Datenbank.
Der Unterschied liegt darin, was falsch werden kann.
Eine Website stellt dar. Was dort steht, ist da oder eben nicht. Ein Produkt dagegen hält Zustände, die richtig oder falsch sein können. Eine Buchung, die es nicht zweimal geben darf. Ein Guthaben, das nicht ins Minus rutschen darf. Eine Freigabe, die eine Reihenfolge hat. Genau dort beginnt unsere Arbeit.
Endpunkte über eine Datenbank zu legen, kann heute jeder. Der Unterschied entsteht davor. Wir schreiben zuerst auf, welche Dinge es in eurem Geschäft gibt, welche Regeln zwischen ihnen gelten und wo ein Vorgang anfängt und aufhört. Erst aus diesem Modell wird Code, und nicht umgekehrt.
Die Struktur folgt danach eurer Fachlichkeit und nicht der Technik. Der Kern mit euren Regeln liegt innen, alles Austauschbare außen. Datenbank, Weboberfläche, Mailversand und Warteschlange sind Anschlüsse, keine Fundamente. Jedes dieser Teile lässt sich später tauschen, ohne dass jemand eure Regeln neu erfinden muss.
Was dabei entsteht, ist bewusst unspektakulär: lesbarer Standard-Code ohne versteckte Abhängigkeit zu uns. Die Web-Schicht bringen wir selbst mit, deshalb arbeitet das Modell mit jedem Framework und ebenso ohne. Gebt ihr eines vor, nehmen wir es. Über die Bauform entscheiden wir, und darauf setzt dann die Frontend Entwicklung auf.
Backend heißt bei uns nicht Server und Datenbank.
Sechs Teile, aus denen eure Fachlichkeit ein System wird.
Fachmodell
Die Dinge eures Geschäfts, ihre Regeln und ihre Zustände, schriftlich und von euch selbst abgenommen.
Domäne
Der Kern, in dem eure Regeln liegen. Er kennt weder Datenbank noch Oberfläche und bleibt tauschbar.
Schnittstelle
Der Zugang, über den euer Frontend arbeitet und über den andere Systeme bei euch andocken können.
Anbindungen
Zahlung, Mailversand, Nachrichten und Dateien. Fremde Systeme docken an, statt danebenzustehen.
Prüflauf
Statische Analyse, Testabdeckung und Tests gegen echte Infrastruktur, startbar auf euren Rechnern.
Betrieb
Umgebung, Container und Pipeline, damit die Anwendung dort läuft, wo ihr wollt, und nirgends festhängt.
Die Struktur entscheidet,
was jede Änderung kostet.
Ein Backend altert nicht sichtbar. Es altert daran, dass dieselbe Regel an immer mehr Stellen steht und irgendwann niemand mehr weiß, welche davon gilt. Ab diesem Punkt kostet jede Änderung mehr als die davor, bis ein Neubau billiger ist als eine Anpassung.
Genau dagegen ist unsere Bauform gebaut. Eure Regeln liegen an einer Stelle, sauber getrennt von Datenbank, Oberfläche und allem anderen Austauschbaren. Was sich fachlich ändert, ändert sich dort und sonst nirgendwo.
Deshalb kostet die zwanzigste Änderung ungefähr so viel wie die zweite. Was ihr beim Kauf seht, ist die Anwendung. Was ihr nicht seht, ist der Preis eurer nächsten Änderung.
Ein Backend sieht man nie. Man merkt nur, wenn es fehlt. Jardis® haben wir so gebaut und arbeiten täglich damit.
Jardis®
Ein Produkt, das andere Produkte baut. Vom internen Werkzeug zur eigenen Marke.
Axon
Eine Marke, die aussah wie ihre Branche. Und jetzt aussieht wie niemand sonst.
Ein Backend allein hilft niemandem. Deshalb steckt es in zwei Programmen, die das ganze Produkt bauen.
Headgent® Transform
Aus eurer Idee wird eine Marke und das Produkt. Von der Strategie bis zum Design, und ein Produkt, das live bei euch läuft.
Investition
Programm ansehen30.000€
Headgent® Build
Euer Produkt fehlt oder hält eurem Wachstum nicht mehr stand. Headgent® entwickelt es so, dass Wachstum über Jahre kein Problem mehr ist.
Investition
Programm ansehen22.000€
Was ihr zur Backend Entwicklung wissen solltet.
Offene Fragen?
Gerne beantworten wir euch alle Fragen in einem persönlichen Gespräch.
Mit PHP und unseren eigenen Bausteinen, dazu MySQL, PostgreSQL oder SQLite, je nachdem, was zu euch passt. Die Anwendung läuft containerisiert und ist an keinen Anbieter gebunden. Alles davon ist verbreitete Technik, für die ihr überall Leute findet.
Ja, Framework-Vorgaben nehmen wir an. Unser Fachmodell liegt darunter, es arbeitet mit jedem und ebenso ohne. Über die Bauform darüber entscheiden wir, denn genau daran hängt, ob eure zwanzigste Änderung noch so viel kostet wie die zweite.
Dass wir die Software um euer Geschäft herum bauen und nicht um die Technik. Zuerst entsteht ein Modell eurer Fachlichkeit, daraus die Struktur. Für euch heißt das, dass eine fachliche Änderung an einer Stelle landet statt an sieben, und dass ein neues Team die Zusammenhänge lesen kann.
Ja, aber nie ungesehen und nie als reine Zuarbeit. Vorab klären wir in einer bezahlten Analyse, was da ist, woran es hängt und welche Regeln euer System heute wirklich durchsetzt. Wie das abläuft, steht auf unserer Seite zur Software-Modernisierung.
Dort, wo ihr sie haben wollt. Wir arbeiten am liebsten mit Hetzner, weil die Server in der EU stehen und das Datenschutz-Gespräch damit erledigt ist. AWS oder ein Anbieter eurer Wahl geht genauso. Die Serverkosten laufen direkt über euch, ohne Aufschlag über uns.
Ihr könnt sie selbst nachsehen. Statische Analyse auf der höchsten Stufe, mindestens achtzig Prozent Testabdeckung im fachlichen Kern und Tests gegen echte Infrastruktur laufen als ein Prüflauf bei euch. Über zwanzig der Bausteine darunter haben wir frei veröffentlicht, ihr könnt sie euch also ansehen, bevor ihr uns beauftragt.
Ja. Der Quellcode liegt ab dem ersten Tag in eurem Repository, dazu die Modelle, aus denen er entstanden ist. Nur wenn ihr diese Modelle später selbst mit Jardis® weiterpflegen wollt, braucht ihr dafür eine eigene Lizenz. Das sagen wir vorher und nicht auf Nachfrage.
Build what's next.
Erzählt uns von eurer Idee. Gemeinsam legen wir den richtigen Umfang, Zeitrahmen und das passende Team fest.
Projekt starten