Design und Technik zusammendenken
Ein Entwurf, der sich nicht sauber bauen lässt, ist kein guter Entwurf. Ein System, das niemand bedienen mag, ist keine gute Technik. Beides entsteht gemeinsam, nicht nacheinander.
Über mich
Antonio Lapsker — Fullstack Developer und technischer Partner für kleine und mittlere Unternehmen. Websites, interne Tools, Automatisierung und klare Systemlogik.
01Weg hierher
Angefangen habe ich mit dreizehn — über Spiele. Erst wollte ich verstehen, wie sie funktionieren, dann selbst etwas bauen.
Geblieben ist die Frage nach dem Wie. Aus dem Basteln wurde Handwerk, aus dem Handwerk ein Beruf: Nach der Schule bin ich direkt in die Selbständigkeit gegangen, erst als Freelancer, heute als Kleinunternehmer.
Kein Umweg über eine Agentur, in der man drei Jahre lang Tickets abarbeitet. Das heißt auch: Ich habe von Anfang an mit den Folgen meiner eigenen Entscheidungen gelebt — mit Systemen, die ich ein Jahr später selbst wieder anfassen musste. Das prägt, wie ich baue.
Ich sitze in Dresden. Gearbeitet wird bundesweit, remote und unkompliziert — für ein Projekt in Hamburg oder München ändert sich nichts außer der Zeitzone, und die ist dieselbe.
02Schwerpunkt
Mein stärkstes fachliches Interesse liegt bei Cybersecurity — wegen der Vielfältigkeit des Themas und weil der interessantere Teil die Prävention ist, nicht die Reparatur.
Das ist kein Werbesatz, sondern der Grund, warum diese Website so gebaut ist, wie sie gebaut ist: strikte Sicherheitsrichtlinie ohne Ausnahmen, kein einziger externer Server im Spiel, IP-Adressen nur als nicht rückrechenbarer Prüfwert, ein eigener Testsatz, der Angriffsversuche gegen die eigene Entwicklungsumgebung fährt.
Bei einem Projekt heißt das: Validierung, Zugriffsschutz und Datensparsamkeit werden mitgeplant und nicht hinterher aufgesetzt. Nachträglich angebrachte Sicherheit ist Flickwerk — und meistens teurer als die saubere Variante von Anfang an.
03Nebenher
Ich bin Mitgründer von Hypertrophy Cult, einer SaaS-Plattform für Fitness-Coaches und deren Kunden.
Dort verantworte ich die Technik: Datenmodell, Rollen, Betrieb und Weiterentwicklung. Kein abgeschlossenes Projekt, sondern ein laufendes Produkt.
Für ein Kundenprojekt ist das aus einem Grund relevant: Ich lebe mit meinen eigenen Architekturentscheidungen weiter. Wer nur ausliefert, merkt nie, welche Abkürzung sich nach zwei Jahren rächt. Ich merke es.
04Arbeitsweise
Ein Entwurf, der sich nicht sauber bauen lässt, ist kein guter Entwurf. Ein System, das niemand bedienen mag, ist keine gute Technik. Beides entsteht gemeinsam, nicht nacheinander.
Eine Technologie kommt ins Projekt, wenn sie einen nachvollziehbaren Vorteil bringt — nicht, weil sie gerade besprochen wird. Was Sie in drei Jahren noch betreiben können, ist mehr wert als das, was heute beeindruckt.
Technische Begriffe sind erlaubt, aber sie müssen erklärt werden. Eine Schnittstelle ist eine definierte Stelle, an der zwei Systeme sicher Daten austauschen. Wenn ich das nicht in einem Satz sagen kann, habe ich es selbst nicht verstanden.
Bei einem Fehler wird reproduziert, gemessen und die Ursache bestimmt — und erst dann eingegriffen. Danach kommt ein Test dazu, damit genau dieser Fehler nicht wiederkehrt.
Zur Einordnung
Das sage ich vorher, nicht auf Nachfrage. Es bedeutet: Ich nehme weniger Projekte an und formuliere Zusagen vorsichtig. Eine Reaktionszeit von 24 Stunden heißt Rückmeldung innerhalb eines Werktags, nicht Behebung. Wenn ein Vorhaben eine Verfügbarkeit braucht, die ich nicht halten kann, sage ich das — vor dem Angebot, nicht danach.
05Passt das?
Gut geeignet
Weniger geeignet
Kontakt
Antwort in der Regel innerhalb von 24 bis 48 Stunden.