Zum Hauptinhalt springen
Exostruction
Kontakt

// ÜBER UNS

Zwei Engineers,die liefern.

Exostruction ist ein kleines Engineering-Studio. Keine Agentur. Kein PowerPoint. Wenn du mit uns sprichst, sprichst du mit den Leuten, die deinen Code schreiben.

SCROLLEN

// WIE WIR HIERHER KAMEN

Vier Kapitel. Story.

  1. 01
    —

    KENNENGELERNT

    Wir haben uns während der Ausbildung kennengelernt — Juljan als Anwendungsentwickler, Alexander als Systemintegrator. Verschiedene Schwerpunkte, aber schnell war klar: wir mögen ähnliche Sachen. Sauber gebauten Code. Server, die nicht abrauchen. Und ehrliche Antworten auf technische Fragen, statt Marketing-Sprech. Aus dem Fachsimpeln in der Mittagspause wurde mit der Zeit mehr.

  2. 02
    —

    GENERVT

    Was uns weniger gefallen hat, sah man oft genug: stundenlange Meetings, die mit 'wir besprechen das nochmal' enden. Excel-Tabellen, die niemand pflegt und denen trotzdem alle vertrauen. Berater-Slides, die behaupten 'Innovation' zu erklären, aber keine einzige Zeile Code anfassen. Wir waren überzeugt, dass IT-Dienstleistung auch anders gehen kann — direkter, ehrlicher, näher am eigentlichen Problem.

  3. 03
    —

    GEGRÜNDET

    Also haben wir Exostruction gegründet. Ein kleines Studio, das genau das macht, was unserer Meinung nach in der IT zu selten passiert: erst zuhören, dann gut bauen, am Ende transparent abrechnen. Kein Account-Manager als Puffer zwischen euch und den Engineers. Keine Technologie-Entscheidungen, die niemand erklären kann. Wir wollten eine Bude, bei der wir selbst gerne Kunde wären.

  4. 04
    —

    HEUTE

    Heute bauen wir Web-Anwendungen, APIs und Linux-Server für Firmen, die verständliche statt überoptimierte Software wollen. Wir sind klein genug, dass bei jedem Projekt einer von uns selbst Code schreibt — und groß genug, dass wir auch komplexe Systeme stemmen. Nebenbei bauen wir eigene Open-Source-Tools wie ExoVote, weil wir gern selbst nutzen, was wir empfehlen.

// WER WIR SIND

Die Leute dahinter.

JBGRÜNDER · 01

CO-FOUNDER & ENGINEERING

Juljan Blischke

„Lesbarer Code ist eine Form von Respekt vor der Person, die ihn morgen wartet."

Fachinformatiker für Anwendungsentwicklung, ausgebildet bei einer Logistik-Firma in Bayern. Schreibt vor allem Backend-Code in C# und TypeScript, mag aber auch Frontend wenn die Anforderungen klar sind.

Interessiert sich für Software-Architektur, ehrliche APIs, und Tools die auch in fünf Jahren noch wartbar sind. Hat ExoVote gebaut weil keiner eine Open-Source-Abstimmungsplattform hatte, die DSGVO-konform war.

Liest gerne über Distributed Systems, Investitionen und schlechte Refactorings. Findet, dass 'best practices' überbewertet sind, wenn niemand erklärt warum.

C# / .NETTypeScriptReact / Next.jsPostgreSQLAPI-DesignSoftware-Architektur
LinkedIn
AKGRÜNDER · 02

CO-FOUNDER & INFRASTRUKTUR

Alexander Kreitmair

„Eine eigene Box, die seit drei Jahren läuft, ist mir lieber als jede SaaS-Promise."

Fachinformatiker für Systemintegration. Kümmert sich darum, dass die Infrastruktur läuft — Linux-Server, Docker-Setups, CI/CD-Pipelines, Backups.

Findet, dass die meisten Firmen viel zu viel für Cloud-Dienste ausgeben, die sie auch selbst betreiben könnten. Hat ein gesundes Misstrauen gegenüber Hosted-Services und ein gutes Verhältnis zu ssh.

Interessiert sich für Network-Security, Monitoring und alles was mit 'läuft das eigentlich noch?' zu tun hat. Mag Kommandozeilen mehr als GUIs.

Linux (Ubuntu, Debian)Docker / ComposeNetworkingCI/CDMonitoringSecurity-Hardening
LinkedIn

// WIE WIR BAUEN

Sechs Punkte, die unsere Arbeit prägen.

  1. Code, der lesbar bleibt

    Wir schreiben Code für die Menschen, die ihn in zwei Jahren warten — auch wenn das wir selbst sind. Kommentare wo nötig, Variablennamen die Sinn ergeben, Funktionen die EIN Ding tun.

  2. Testen, was wichtig ist

    Nicht jede Helper-Funktion braucht einen Unit-Test. Aber die Business-Logik, die kritischen Flows, die Bug-Patches — die schon. Wir hassen es, Bugs zweimal zu fixen.

  3. Eigene Infrastruktur, wo möglich

    Hetzner statt AWS, wenn die Anforderungen das hergeben. Self-Hosted Tools statt SaaS, wenn die Wartung machbar ist. Cloud ist großartig — wenn man weiß, was man bekommt und was man bezahlt.

  4. Open Source statt Lock-in

    Wir bevorzugen Tools, die unter offener Lizenz stehen. Damit ihr nie in der Situation seid, dass ein Anbieter euch in die Ecke treibt. Auch unsere eigenen Produkte (ExoVote) sind Open Source.

  5. Direkte Kommunikation

    Kein Ticket-System mit 48h-SLA dazwischen. Slack, Signal, Mail, Anruf — wir antworten wie echte Menschen, in der Regel innerhalb weniger Stunden während der Arbeitszeit.

  6. Ehrliche Schätzungen

    Wir geben Zeitschätzungen in Spannen, nicht in Fixpunkten. Software hat Unsicherheiten. Wir sagen das offen, lieber als falsche Sicherheit zu suggerieren.

// JETZT IHR

Klingt nach euch? Lasst uns reden.

Projekt besprechenhello@exostruction.com