svaroxlabs
alle LeistungenPRODUKTENTWICKLUNG

Ein Stack von der Datenbankbis aufs Telefon.

Die meisten Produkte brauchen früher oder später drei Dinge: eine mobile App, eine Web-App und ein Backend, das beide versorgt. Der klassische Weg sind drei Technologien, drei Codebasen und faktisch drei Teams, in denen jedes Feature zweimal entsteht und jede Änderung über alle hinweg abgestimmt werden muss. Wir bauen alle drei in einer Sprache.

Produkt besprechen

WAS ENTHALTEN IST

Frontend-Entwicklung

  • React, Next.js, TypeScript
  • Server Components, SSR & ISR
  • REST-APIs, React Query
  • Tailwind CSS, Designsysteme
  • Core Web Vitals & SEO

Mobile Apps

  • React Native, Expo
  • iOS & Android aus einer Codebasis
  • Native Module & Geräte-APIs
  • Push-Benachrichtigungen, Deeplinks
  • Offline-First-Daten
  • Releases im App Store & Play Store

Backend-Entwicklung

  • Nest.js, Express.js, Node.js
  • TypeScript durchgängig
  • REST-APIs, Auth & Berechtigungen
  • PostgreSQL, MySQL, MongoDB
  • Prisma, TypeORM, Mongoose
  • Hintergrundjobs & Integrationen

QA & Automatisierung

  • Technisches Testen
  • Funktionales Testen
  • Exploratives Testen
  • Plattformübergreifendes Testen
  • Barrierefreiheitstests
  • Automatisiertes Testen
  • Performance-Tests

Was wir bauen

Frontend, Mobile, Backend und Testing, von einem Team statt von dreien.

  • Frontend: React, Next.js und TypeScript, Server Components, SSR und ISR, Core Web Vitals
  • Mobile: React Native und Expo, iOS und Android aus einer Codebasis, Push-Benachrichtigungen, Deep Links, Offline-First-Daten, Releases im App Store und Play Store
  • Backend: Nest.js, Express und Node.js, REST-APIs, Auth und Berechtigungen, PostgreSQL, MySQL und MongoDB, Background Jobs und Integrationen
  • QA: funktionales, exploratives, plattformübergreifendes, barrierefreies, Performance- und automatisiertes Testen

Warum eine Sprache sich im Budget zeigt

Web in Next.js, Mobile in React Native, Backend in Nest.js, alles TypeScript, in einem Repository mit gemeinsamen Paketen dazwischen. Es gibt genau eine Definition davon, was ein Produkt, eine Bestellung oder ein Nutzer ist, und alle drei importieren sie. Ändert das Backend ein Feld, lassen sich Web- und Mobile-Code, die davon abhängen, sofort nicht mehr kompilieren, mit einer präzisen Liste jeder betroffenen Stelle.

In der Praxis sind 30–50 % des Codes geteilt, und zwar genau der Teil, in dem Fehler am teuersten sind: die Datendefinitionen, die Regeln, die Berechnungen. Die Screens bleiben getrennt, denn eine gute mobile und eine gute Web-Oberfläche unterscheiden sich tatsächlich.

  • Ein Team für Web, Mobile und Backend, ohne Warten auf Übergaben
  • Features kosten weniger: die Logik wird einmal geschrieben, pro Plattform entstehen nur die Screens
  • Änderungen sind sicherer: der Compiler findet jede betroffene Stelle über alle drei Apps hinweg
  • Mobile-First zu starten bleibt günstig: eine später ergänzte Web-App erbt Typen und Logik am ersten Tag

Brauchen Sie wirklich ein eigenes Backend?

Oft nicht. Und jede Agentur, die es in jedem Projekt empfiehlt, optimiert ihre Rechnung, nicht Ihre Runway.

Wenn Ihre App vor allem Daten speichert und anzeigt und die Regeln einfach sind, ist ein verwaltetes Backend wie Firebase oder Supabase die richtige Wahl. Das spart einen spürbaren Teil des Baus und ein bis zwei Wochen. Wenn Ihr Produkt zuordnet, berechnet, auszahlt, freigibt oder sich mit anderen Systemen verbindet, planen Sie ein eigenes Backend von Tag eins ein.

  • Verwaltet genügt: Notizen, Gewohnheiten, Workouts, gespeicherte Einträge, einfache Profile, Nutzer sehen ihre eigenen Daten
  • Eigenes nötig: komplexe Geschäftslogik, Geld über einen einfachen Checkout hinaus, mehrere Rollen mit wirklich unterschiedlichen Rechten, Integrationen mit anderen Systemen, Daten, die Ihnen vollständig gehören müssen

Ein bestehendes Produkt übernehmen

Wir übernehmen auch bestehende Codebasen: Apps von einem Vorgängerteam, Produkte, die einem verwalteten Backend entwachsen sind, Frontends, die neu gebaut werden müssen, ohne alles dahinter neu zu schreiben. Die Migration von Firebase auf ein eigenes Backend ist ein normales, planbares Projekt und kein Neuschreiben Ihrer App.

Häufige Fragen

Können Sie für iOS und Android gleichzeitig bauen?

Ja, und genau deshalb bauen wir in React Native: eine Codebasis, die auf beiden Plattformen nativ läuft, was spürbar günstiger und schneller ist, als dasselbe Produkt zweimal zu bauen.

Übernehmen Sie Code, den jemand anders geschrieben hat?

Ja. Wir beginnen mit einer kurzen Sichtung des Bestands und einer Einschätzung, was Erhalten gegenüber Ersetzen kosten würde. Diese Einschätzung bekommen Sie, bevor Sie sich zu etwas Weiterem verpflichten.

Brauchen wir ein eigenes Backend, oder reicht Firebase?

Wenn die App Daten mit einfachen Regeln speichert und anzeigt, reicht Firebase oder Supabase wirklich und spart Geld wie Zeit. Wenn sie zuordnet, berechnet, auszahlt, freigibt oder integriert, planen Sie ein eigenes Backend ein. Im Zweifel verwaltet starten und die Migration als Meilenstein einplanen, nicht als Notfall.

Mit welchen Datenbanken arbeiten Sie?

Am häufigsten mit PostgreSQL, dazu MySQL und MongoDB, angebunden über Prisma, TypeORM oder Mongoose, je nachdem was das Projekt braucht.

Wer testet?

Wir: funktional, plattformübergreifend, auf Barrierefreiheit, Performance und automatisiert, auf echten Geräten, alten wie neuen, auf beiden Plattformen, nicht nur im Simulator.

PASSENDE PROJEKTE

FLOTTENMANAGEMENT

Camasys: Autovermietung und Flottenmanagement, durchgängig

Buchungen, Flotte, Verträge, Rechnungen und Auswertungen in einer Oberfläche, dazu die Buchungsseite für Kunden und die Mobile-App, mit der die Filiale arbeitet.

DOKUMENTENWORKFLOW

Acadsys: Von der fotografierten Rechnung zum erteilten Zahlungsauftrag

Eine Plattform für Freigaben und Digitalisierung, konfigurierbar genug, um zum internen Prozess jedes Kunden zu passen. OCR übernimmt das Tippen, die Prüfspur behält den Überblick.

PASSENDE ARTIKEL

WEITERE LEISTUNGEN

Websites & LandingpagesDesignMVP-Entwicklung