Question 1

Wie funktioniert die wöchentliche Kündigung wirklich?

Accepted Answer

Beende jede Woche mit einer einzigen Nachricht. Keine Frist, kein Exit-Gespräch, kein Kleingedrucktes. Wir rechnen wöchentlich ab, du bist also maximal die laufende Woche gebunden.

Question 2

Was, wenn die Arbeit mich nicht überzeugt?

Accepted Answer

Es steht in deinem Vertrag: Sag es uns, und wir erstatten diese Woche. Keine Rückfragen, keine Rechnungen zum Streiten, keine Eskalationscalls. Einzige Regel: Erstattungen gelten für die letzte Woche.

Question 3

Warum trackt ihr keine Stunden?

Accepted Answer

Weil Stunden die falsche Metrik sind. Wenn wir auf abrechenbare Stunden optimieren, optimieren wir nicht auf dein Ergebnis. Der Deal ist einfacher: Jede Woche müssen wir die nächste verdienen. Wenn wir das nicht tun, zahlst du nicht. Wir können null Stunden oder sechzig investieren. Was zählt, ist, ob du umgehauen bist.

Question 4

Was bedeutet „Erwartungen losgelöst von der Realität“?

Accepted Answer

Wir arbeiten mit Operators, nicht mit Lottogewinnern. Wenn eine Anforderung Physik, Gesetz oder Drittanbieter-Systeme brechen würde, sagen wir das, und wenn wir uns nicht ausrichten können, gehen wir. Die Garantie ist gegenseitig: Du kannst uns jede Woche feuern; wir können uns auch selbst feuern.

Question 5

Welches Framework setzt ihr ein, und darf ich mitentscheiden?

Accepted Answer

Standard-Stack ist Next.js + NestJS + Postgres, weil er vom Prototyp bis zum Enterprise-Einsatz skaliert, ohne dass wir alles neu schreiben müssen. Mit React, Vue, Angular oder SvelteKit im Frontend und Node, Django, Rails oder Go im Backend sind wir genauso zu Hause. Wenn du schon einen Stack hast, nehmen wir deinen. Wir zwingen niemandem eine Migration auf.

Question 6

Wie geht ihr bei SPAs mit SEO und Performance um?

Accepted Answer

SSR oder SSG by default (Next.js, Nuxt, Astro), nie eine leere JS-Hülle beim ersten Rendern. Core-Web-Vitals-Ziele (LCP unter 2,5s, CLS unter 0,1) erreichen wir vor dem Launch. Bildoptimierung, Code-Splitting pro Route, Edge-Caching und sauberes Schema-Markup sind das Minimum, nicht das Premiumpaket.

Question 7

Übernehmt ihr auch bestehende Codebases oder nur Greenfield-Projekte?

Accepted Answer

Übernahmen sind eine echte Spezialität von uns. Unsere ersten 1–2 Wochen auf einem Brownfield-Projekt: Audit, Architektur dokumentieren, Quick Wins und strukturelle Risiken identifizieren, dann liefern wir einen schriftlichen Plan, bevor wir nennenswert Code anfassen. Wir haben Projekte in .NET Framework, PHP/Symfony, Python/Flask und Ähnlichem geerbt (kein Rails) und modernisiert, ohne Big-Bang-Rewrite.

Question 8

Wo läuft die App, und was passiert am Deploy-Tag?

Accepted Answer

Wir deployen dorthin, wo es zur Workload und zu deinem Ops-Team passt: Vercel, Netlify oder Cloudflare für Edge-lastige Frontends; AWS, GCP, Azure oder Hetzner für Backends; self-hosted Docker/Kubernetes, wenn es aus Gründen der Data Residency oder Compliance in deiner eigenen Infrastruktur bleiben soll. CI/CD steht ab Tag eins: Preview-Deploys pro Branch, automatisierte Tests als Gate für Production, Rollback mit einem Befehl. Du sollst nie Angst vor einem Freitags-Deploy haben müssen.

Question 9

Was kostet eine maßgeschneiderte Web-App end-to-end?

Accepted Answer

Internes Tool mit Auth, CRUD und sauberer UI: 15.000–30.000 €. SaaS-MVP mit Billing, Multi-Tenant-Daten und Marketing-Site: 30.000–80.000 €. Produktionsplattform mit Admin-Tools, SSO, Audit-Logs und SLA-tauglichem Ops: 100.000 €+. Hosting, Drittanbieter-APIs und laufende Wartung quotieren wir separat, damit das Build-Budget die Runtime-Kosten nicht stillschweigend mitschluckt.

Question 10

Wann sollten wir lieber eine SaaS- oder No-Code-Plattform erweitern, statt selbst zu bauen?

Accepted Answer

Wenn deine Differenzierung nicht im Workflow selbst liegt. Webflow, Retool, Airtable, Bubble und Supabase schlagen einen Custom-Build bei 80 % der internen Tools und 60 % der MVPs. Wir bremsen Gründer, die Custom Code für ein Problem wollen, das ein 99-€/Monat-SaaS schon gelöst hat. Custom bauen wir, wenn der Differenzierer echt ist: domänenspezifische Logik, Datenhoheit, Integrationen mit proprietären Systemen oder Compliance, die Off-the-Shelf nicht abdeckt.

Web-App-Entwicklung

Welche Technologien setzen wir ein?

Wie läuft unser Entwicklungsprozess?

Was bieten wir darüber hinaus?

Wie wir Software entwickeln

Discovery-Phase

Erste Iteration

Folge-Iterationen

Wartung

Weiterentwicklung / Übergabe

Beweise statt Versprechen

Was Kunden sagen

FAQs

Lern uns kennen