01 / oberfläche · Produktoberflächen
Next.js- und React-Entwickler für Dashboards, Admin-Panels und interne Tools
Die Screens, die Ihre Kunden und Ihr Team den ganzen Tag benutzen. React, Next.js und TypeScript, gebaut so, dass der vierzigste Klick so schnell ist wie der erste.
- React in Produktion seit 2022
- Alleiniger Entwickler einer Plattform mit drei Rollen
- Design-System-Primitive, auf denen ein Frontend-Team aufbaut
was ich baue
Alles, wo ein Screen davor steht.
Zwei Formen decken das meiste ab: ein Werkzeug, das jemand stundenlang offen hat, und eine Seite, die in unter einer Sekunde da sein muss. Andere Aufgabe, andere Werkzeuge, gleicher Maßstab.
Dashboards
der Screen, den jemand den ganzen Tag offen hat, wo die zweite Interaktion alles entscheidet
Admin-Panels
interne Werkzeuge für die Leute, die das Geschäft betreiben, nicht für die Kunden
Kundenportale
die eingeloggte Hälfte Ihres Produkts, in der Ihre Kunden ihre eigene Arbeit erledigen
datenintensive Tabellen
Tausende Zeilen, die filtern, sortieren und blättern, ohne dass der Screen einfriert
KI-Produktoberflächen
gestreamte Antworten mit den Quellen daneben, und ein echter Zustand für den Fall, dass das Modell falsch liegt
Onboarding-Flows
die Strecke zwischen Registrierung und dem ersten nützlichen Moment
Design-Systeme
die Komponenten-Bibliothek, die verhindert, dass ein vierter Entwickler einen fünften Button erfindet
Marketing-Seiten
statisch und schnell, ohne Framework im Browser, nur um Text darzustellen
wie es abläuft
Idee, Oberfläche, Produkt.
Vier Schritte, in dieser Reihenfolge. Die teuren Fehler passieren alle, wenn einer davon übersprungen wird.
verstehen
wer den Screen benutzt, was die Person zu Ende bringen will, und wo der aktuelle sie verliert
formen
Informationsarchitektur und Interaktionsmuster, entschieden bevor irgendetwas gezeichnet wird
bauen
React, Next.js und TypeScript im Strict Mode, auf einem Komponentensystem statt daneben
ausliefern
deployed und gemessen — Bundle-Größe, Core Web Vitals, Kontrast, und jeder Weg, den eine Tastatur nimmt
warum react
React ist nicht der Punkt. Sondern das, was es mich versprechen lässt.
Ein Framework ist ein Mittel, um Zusagen zu machen. Das hier sind die, die sich lohnen — und der Grund, warum der vierte Screen weniger kostet als der erste.
- wiederverwendbare Komponenten
- ein Button, eine Quelle. Ihr vierter Screen wird Montage statt Erfindung.
- Zustand, über den man nachdenken kann
- eine Bestellung, die gleichzeitig bezahlt und unbezahlt ist, hört auf ein Bug zu sein, wenn der Typ sie gar nicht erst existieren lässt.
- Interaktion, die mithält
- Filter, die reagieren, während die Hand noch auf der Maus liegt — bei Zeile eins und bei Zeile viertausend.
- Daten zuerst auf dem Server
- Daten, die auf dem Server liegen, werden dort geholt. Der Browser lädt eine Seite statt eines Programms.
- Echtzeit-Oberflächen
- Streams, Subscriptions und optimistische Updates, ohne dass der Screen jemandem je eine bequeme Lüge erzählt.
- Architektur, die hält
- Grenzen, die im neunten Monat noch auffindbar sind, wenn nicht mehr ich sie bearbeite.
die probleme, die ich löse
Einen dieser Sätze haben Sie wahrscheinlich schon laut gesagt.
“Die App funktioniert, aber sie fühlt sich furchtbar an.”
Fast immer ein Problem mit Zustand und Data Fetching in optischer Verkleidung. Ich repariere zuerst die Interaktion, dann die Oberfläche.
“Das UI wird unwartbar.”
Fünf Buttons, drei davon fast identisch, und keiner sicher zu ändern. Ich fasse sie zu einem Komponentensystem zusammen, in dem jeder Zustand gezeichnet ist.
“Das Dashboard ist ein Haufen Komponenten, für die sich niemand zuständig fühlt.”
Ich baue es um die wenigen Muster herum um, die sich tatsächlich wiederholen, damit der nächste Screen montiert und nicht erneut erfunden wird.
“Der Prototyp kam aus einer KI. Jemand muss daraus etwas Echtes machen.”
Ich lese ihn, behalte was trägt, und baue den Rest neu — mit Typen, Grenzen und einem Deploy, den man zweimal laufen lassen kann.
“Es liegen Designs in Figma, die niemand gebaut hat.”
Ich baue sie originalgetreu, inklusive der Zustände, die niemand gezeichnet hat: leer, ladend, Fehler, und viel zu viele Daten.
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Query
- Node.js
- Core Web Vitals
Oberfläche zuerst, aber die Linie endet nicht am Browser. Wenn ein Screen einen Endpoint, ein Schema oder eine Queue dahinter braucht, baue ich das mit, statt ein Ticket zu schreiben und zu warten.
how I build it
TypeScript in strict mode, with types that describe your business rather than restating the shape of a JSON response. Most frontend bugs I get called in to fix were a state nobody should have been able to reach. An order that is both paid and unpaid. A form that is submitting and still editable. Those stop being bugs when the type refuses to let them exist.
Bundle size and data fetching get an owner on day one instead of a cleanup ticket the week before launch. Data that lives on the server is fetched on the server. Interactive components stay small and sit at the edges of the tree. Anything that wants to ship a library to the browser so it can render text has to make its case.
I care what it looks like, and I have opinions I can defend. Spacing on a scale instead of whatever number felt right. A type ramp that still reads at 360 pixels and at 1600. Colour that means something, used sparingly, so that when one thing is highlighted you know why. That is not decoration. It is the difference between a screen someone tolerates and a screen someone trusts.
Accessibility happens while I build, not in an audit afterwards. I read the markup and I tab the page. Focus rings stay visible. Semantics come from using the right element, not from an ARIA attribute patched over a div.
when a project needs more than me
When a project wants brand work or deeper product design alongside the build, I bring in designers I already work with. One arrangement, one schedule, and one person answerable for how it turns out.
wie die zusammenarbeit aussieht
Sie bringen es. Ich übernehme. Sie bekommen es besser zurück.
you bring
- eine Idee, ein laufendes Produkt oder einen generierten Prototyp
- die Designs, falls es welche gibt
- die Leute, die den Screen den ganzen Tag offen haben
I handle
- Frontend-Architektur und Komponentenstruktur
- UI-Umsetzung, bis hinunter zu den Zuständen, die niemand gezeichnet hat
- State Management und Data Fetching
- API-Anbindung, und die API selbst, wenn eine gebraucht wird
- responsives Verhalten ab 360px
- Bundle-Größe, Core Web Vitals, Barrierefreiheit
you get
- Ihr Code, in Ihrem Repository, ab dem ersten Commit
- eine Komponenten-Bibliothek, die der nächste Entwickler lesen kann
- eine Oberfläche, die in jeder Breite hält — am Standard gemessen statt nach Augenmaß beurteilt
Sie haben ein Produkt, das gebaut werden muss?
Dreißig Minuten über die Idee, die halbfertige App oder den Prototyp, den jemand generiert hat. Ich sage Ihnen, was ich damit machen würde und ob ich der Richtige dafür bin.