---
title: "Next.js- und React-Entwickler für Dashboards, Admin-Panels und interne Tools"
description: "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."
url: https://riteshkc.com.np/de/services/product-interfaces
source: https://riteshkc.com.np/de/services/product-interfaces.md
updated: 2026-08-26
site: "Ritesh KC"
---
# 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.

- Layer: 01 / oberfläche
- Builds: 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)
- Tools: Next.js, React, TypeScript, Tailwind CSS, React Query, Node.js, Core Web Vitals
- React in Produktion seit 2022
- Alleiniger Entwickler einer Plattform mit drei Rollen
- Design-System-Primitive, auf denen ein Frontend-Team aufbaut

## 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.

## 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.

## Idee, Oberfläche, Produkt.

01. verstehen — wer den Screen benutzt, was die Person zu Ende bringen will, und wo der aktuelle sie verliert
02. formen — Informationsarchitektur und Interaktionsmuster, entschieden bevor irgendetwas gezeichnet wird
03. bauen — React, Next.js und TypeScript im Strict Mode, auf einem Komponentensystem statt daneben
04. ausliefern — deployed und gemessen — Bundle-Größe, Core Web Vitals, Kontrast, und jeder Weg, den eine Tastatur nimmt

## 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

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`.

![The same builder surrounded by distinct interface panels — an analytics chart, a kanban board, a data table, a settings form and a stack of notifications — wired together with thin lines into one connected product.](https://pub-0d70e426aadb4f069a19cb045dfe20f4.r2.dev/media/product-interfaces-builds.avif)

## 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.

## Proof

- none listed