Corevanix arbeitet nach einem Remote-first-Modell, und der Workflow hat sich seit den ersten Projekten deutlich weiterentwickelt. Dieser Artikel ist ein interner Einblick in unsere Arbeitsweise – Tagesablauf, Tooling, bewährte Gewohnheiten und Stolperfallen. Kein Manifest, sondern das, was wir tatsächlich tun. Die Erkenntnisse aus dem ersten vollen Jahr, plus die Feinjustierungen aus dem ersten Quartal 2026.
Wenn Sie gerade über ein Remote-Setup nachdenken oder Ihr aktuelles Setup verfeinern möchten – vielleicht finden Sie hier die eine oder andere Anregung. Aus der Corevanix-Perspektive, im Kontext des ungarischen Marktes.
Hintergrund
Die Struktur besteht aus einem durchgehend erreichbaren Core-Team und einem spezialisierten Partnernetzwerk (projektbezogen, mit Partnern je Fachgebiet). Beide arbeiten remote-first; die gemeinsame Arbeit erfolgt auf CET-Basis, mit Partnern in anderen Zeitzonen über ein definiertes Überschneidungsfenster.
Die Struktur Anfang 2026
- Core-Team: durchgehend erreichbar, vollständig remote; verantwortlich für Strategie, technische Entscheidungen und Kundenbeziehungen
- Partnernetzwerk: spezialisiertes Partnernetzwerk mit Partnern je Fachgebiet (SAP, Frontend, Mobile, Daten, KI), projektbezogen, unter NDA
- Zeitzone: Arbeitsrhythmus auf CET-Basis; mit Partnern in anderen Zeitzonen ein definiertes Overlap-Window
Das Core-Team arbeitet zu 100 % remote, auch die überwiegende Mehrheit der Partner arbeitet remote (einige teilweise in Co-Working-Spaces).
Warum remote?
Einige Gründe, die zu unserer Remote-first-Entscheidung geführt haben:
- Verfügbarkeit von Talenten. Der Budapester Tech-Pool war 2024 bereits eng – mit einem Remote-first-Modell hängt die Auswahl nicht mehr vom Wohnort ab.
- Kostenoptimierung. Ein Büro in Budapest kostet für ein kleines Core-Team 1–1,5 Mio. HUF/Monat. Remote: 0.
- Präferenz der Mitarbeitenden. 60–70 % des Tech-Pools von 2024 suchen bereits gezielt nach Full-Remote-Stellen.
- Kundenerreichbarkeit. Viele unserer Kunden sitzen außerhalb Budapests oder im Ausland – Remote-first-Kommunikation ist auch für sie naheliegender.
Daily Flow – ein typischer Tagesrhythmus
Nicht jeder hält sich exakt an diesen Rhythmus, aber das ist das grundlegende Muster:
8:30 Uhr – asynchroner Morning-Check-in in Slack
Wer online ist, notiert die 1–3 Prioritäten des Tages. Beispiel:
Morning! Today's priorities:
1. Kunde X – Zusammenfassung des Discovery Calls + Scope-Entwurf (Deadline: morgen)
2. Kunde Y – Code-Review für PR #142
3. Intern – Vorbereitung des wöchentlichen Retros
Available 9-17 CET. Heads up: 14-15 Uhr Kunden-Call.
Diese zwei- bis dreiminütige tägliche „Where I am"-Nachricht reduziert Fragen wie „Wo ist eigentlich X?" drastisch.
9:00 Uhr – erster Arbeitsblock
In der Regel Deep Work (Coding, Dokumentation, Architekturplanung). Slack-Benachrichtigungen aus, Kalender blockiert. 90–120-minütiger Block.
Der Mythos vom „vierstündigen Morning Deep Work" trifft bei uns nicht zu – zwischen Meetings und asynchronen Updates ist ein Block von 90–120 Minuten realistischer.
11:30 Uhr – asynchrones Update in Slack
Fortschritt bei den morgendlichen Prioritäten. „X fertig, Y in Arbeit, Z blockiert durch …" – ein bis zwei Sätze.
12:00–13:00 Uhr – Mittagspause
Ähnlich wie im Büro, mal 15 Minuten, mal eine Stunde. Niemand stoppt die Zeit.
13:00 Uhr – Meeting-Block am Nachmittag
Kunden-Call, internes Review. Wir planen maximal zwei Stunden ein, damit Raum für Fokus bleibt. Das „Back-to-Back-Meetings den ganzen Nachmittag"-Muster ist ein Anti-Pattern.
15:30 Uhr – zweiter Arbeitsblock
In der Regel Action Items aus Meetings, Code-Reviews, PR-Merges. Weniger „Deep Work" als am Morgen – oft eher reaktiv.
17:30–18:00 Uhr – asynchroner Wrap-up in Slack
Was heute fertig wurde, was auf morgen wartet. Zwei bis drei Minuten, ähnlich dem Morning-Check-in. Zum Beispiel:
Wrap-up:
✓ Kunde X – Scope-Entwurf fertig, morgen Review
✓ Kunde Y – PR-Review kommentiert
⏳ Internes Retro: morgen früh
🚫 Blocked: warte auf Antwort von Kunde Z
Der Tooling-Stack im Detail
Das Tooling ist das „Geheimrezept" jedes Remote-Teams. Unseres im ersten Quartal 2026:
Kommunikation
| Tool | Anwendungsfall | Kosten/Monat |
|---|---|---|
| Slack | Tägliches Standup, ad hoc, Projekt-Channels pro Kunde | 7 $/Nutzer |
| Google Meet | Meetings (max. 2–3 Teilnehmende) | (Teil von Workspace) |
| Zoom | Größere Meetings (4+ Teilnehmende) | 15 $/Host |
| Loom | Asynchrones Video (statt eines 25-minütigen Meetings eine 5-minütige Erklärung) | 12,5 $/Nutzer |
| Kundenkommunikation (nach Vorgabe) | 0 $ |
Projektmanagement
| Tool | Anwendungsfall | Kosten |
|---|---|---|
| Linear | Interne Projekte + agiles Ticket-Tracking | 8 $/Nutzer |
| Notion | Knowledge Base, Meeting-Notizen, Dokumente | 10 $/Nutzer |
| Google Drive | Verträge, Rechnungen, umfangreiche Dokumente | (Workspace) |
| Cal.com | Meeting-Buchungslink (eigenständig, für Kunden) | 12 $/Nutzer |
Entwicklung
| Tool | Anwendungsfall | Kosten |
|---|---|---|
| GitHub | Sämtlicher Code (private Repos, Branch Protection) | 4 $/Nutzer |
| Vercel | Staging- und Production-Deploys (Frontend) | 20 $/Nutzer (Pro) |
| Sentry | Error-Tracking | 26 $/Team (Team-Plan) |
| Cursor / Claude Code | KI-gestütztes Coding | 20–200 $/Nutzer |
Betrieb
| Tool | Anwendungsfall | Kosten |
|---|---|---|
| 1Password | Secret-Verwaltung auf Team-Ebene | 7,99 $/Nutzer |
| Granola | Meeting-Notizen (KI-Transkripte) | 14 $/Nutzer |
| Stripe | Abrechnung für Kunden | (pro Transaktion) |
| Mintos / Wise | Internationale Zahlungen an das Partnernetzwerk | 0–1 % Gebühr |
Gesamte Tooling-Kosten pro Kopf und Monat
Der gesamte Tooling-Stack pro Core-Team-Mitglied kostet rund 120–150 USD/Monat; die Gesamtsumme skaliert linear mit der Größe des Core-Teams.
Das ist nicht billig, aber die Investition lohnt sich – die Flexibilität des Toolings macht das Remote-Setup erst tragfähig.
Vier bewährte Gewohnheiten
1. Async by Default
Jede Information läuft standardmäßig als Text, Video oder Call gibt es nur, wenn es wirklich notwendig ist. Eine Loom-Nachricht ersetzt in 90 % der Fälle ein Meeting.
Konkretes Beispiel: Feedback zu einem Code-Review. Statt „lassen Sie uns 30 Minuten darüber sprechen" gibt es ein Loom-Video, in dem der Entwickler die komplexen Stellen durchgeht. Der Reviewer sieht es sich später an und kommentiert im PR.
Was bringt uns das?
- Asynchron – der Reviewer schaut es sich an, sobald er Kapazität hat
- Dokumentationscharakter – der Loom-Video-Link bleibt bestehen und ist später referenzierbar
- Zeitzonenfreundlich – Partner in anderen Zeitzonen sehen es sich innerhalb ihres eigenen Arbeitstages an
Wann funktioniert es nicht?
- Entscheidungen mit hoher Tragweite (Architecture Review)
- Konfliktlösung
- Die ersten zwei Wochen beim Onboarding neuer Teammitglieder
2. Doc-first
Vor jedem Meeting: Agenda plus relevantes Dokument in Notion. Während des Meetings ist das Dokument geöffnet und wird live bearbeitet. Nach dem Meeting ist das Dokument selbst das Protokoll – es gibt kein separates „Follow-up-E-Mail".
Das Muster:
1. Vor dem Meeting: Agenda + Context-Doc geteilt (24 Stunden Vorlauf)
2. Während des Meetings: Dokument geöffnet, Live-Bearbeitung
3. Nach dem Meeting: Dokument abgeschlossen, Abschnitt „Action Items" ausgefüllt
4. Follow-up: niemand schreibt eine separate E-Mail – das Dokument ist der Record
Was bringt uns das?
- Die Dokumentenbasis wächst und ist durchsuchbar
- Das Onboarding neuer Teammitglieder ist schnell (der Kontext steht vollständig in Notion)
- Der Meeting-Fokus ist besser (die Teilnehmenden bereiten sich im Voraus vor)
3. Wöchentliches Retro
Freitags ein 30-minütiges Retro: Was lief gut, was nicht, was ändern wir. Ein Dokument speichert sämtliche Retro-Ergebnisse, und alle zwei Wochen sehen wir uns wiederkehrende Themen an.
Das Retro-Format:
1. Wins this week (5 Min.) — was feiern wir?
2. Pain Points (10 Min.) — was lief nicht gut?
3. Improvement Actions (10 Min.) — was ändern wir?
4. Recurring Themes (5 Min.) — gab es ein Muster in den letzten zwei Retros?
Was bringt uns das?
- Psychologische Sicherheit – Probleme können beim Namen genannt werden
- Kontinuierliche Verbesserung – der Workflow bleibt nicht stehen
- Buy-in des Teams – jede Änderung beruht auf einer gemeinsamen Entscheidung
4. „Office Hours"-Buchungssystem
Statt „Darf ich X kurz stören?" gibt es für jedes Senior-Teammitglied einen öffentlichen Cal.com-Link. Buchbare 15- oder 30-Minuten-Slots, eine Agenda ist Pflicht.
Das Muster:
- Jede Senior-Person hat einen Cal.com-Link
- 15-Min-Slot: schnelle Frage, unklarer Scope
- 30-Min-Slot: tiefere Diskussion, technisches Review
- Agenda im Buchungsformular Pflicht (1–2 Sätze)
- Kein Walk-in
Was bringt uns das?
- Der Fokus der Senior-Teammitglieder ist geschützt (niemand stört mit einer spontanen Slack-DM)
- Junior-Teammitglieder wissen, wie sie Senior-Zeit bekommen
- Durch die Pflicht-Agenda ist das Gespräch produktiv
Drei Herausforderungen und Lösungen
Herausforderung 1: Einsamkeit / Isolation
Problem: Einige Teammitglieder litten in den ersten drei bis vier Monaten unter sozialer Isolation. Die isolierende Wirkung des Homeoffice ist nicht zu unterschätzen – bei manchen zeigten sich depressionsähnliche Symptome.
Lösung:
- Verpflichtender „Virtual Coffee" einmal pro Woche – 20 Minuten, ohne Agenda, einfach ein Gespräch. Monatliches Random-Pairing.
- Vierteljährliches persönliches Team-Treffen – zwei bis drei Tage, Teambuilding.
- Co-Working-Budget – 50.000 HUF pro Kopf und Monat, falls jemand gelegentlich in einem Co-Working-Space arbeiten möchte.
Ergebnis: Nach sechs Monaten kommt jedes Teammitglied gut mit dem Remote-Setup zurecht. Das Thema Isolation steht in der vierteljährlichen Umfrage nicht mehr an Position eins.
Herausforderung 2: Zeitzonenüberschneidung
Problem: Arbeitet ein Partner in einer um mehrere Stunden verschobenen Zeitzone, ist das Meeting-Fenster klein: Die frühen CET-Stunden sind bei ihm bereits Nachmittag.
Lösung:
- Definiertes Overlap-Window von 9:00–11:00 Uhr CET. Außerhalb davon ausschließlich asynchron.
- Zeitzonenbewusste Buchung – Cal.com rechnet Zeitzonen automatisch um.
- Hand-off-Dokument – bei jedem asynchron übergebenen Punkt ein Context-Doc „von CET → Partner-Zeitzone".
Ergebnis: Partner in anderen Zeitzonen arbeiten zu 80 % asynchron und zu 20 % in Overlap-Meetings. Die Produktivität bleibt stabil.
Herausforderung 3: Documentation Drift
Problem: Dokumente in Notion veralten – niemand aktualisiert sie. Ein drei bis sechs Monate altes Dokument liegt oft schon daneben.
Lösung:
- Monatliches „Doc Review" – jedes Dokument trägt ein „Last reviewed"-Datum. Ist es älter als drei Monate, prüft es der Owner.
- Gibt es keinen Owner → Archivierung (Verschieben in den Ordner „Archive").
- Feld „Doc Owner" bei jedem Dokument – der Name der verantwortlichen Person, die es aktuell hält.
Ergebnis: 70–80 % der Notion-Inhalte sind aktuell. Die restlichen 20–30 % legacy Inhalte werden zügig archiviert.
Tipp: Das Doc-Review sollte ein monatliches Ritual sein, kein Ad-hoc-Termin. Der „Doc-Review-Freitag" liegt am letzten Freitag jedes Monats von 14 bis 15 Uhr – ein einstündiger Block, den wir gemeinsam durchführen.
Alternativen zum Tooling-Stack
Einige alternative Tools, die wir in Betracht gezogen, aber nicht gewählt haben:
Alternativen zu Slack
- Microsoft Teams – enterprise-lastig, aber ohne die Flexibilität von Slack
- Discord – gut für junge Teams, aber nicht businesstauglich
- Mattermost (self-hosted) – DSGVO-Priorität, aber wartungsintensiv
Alternativen zu Linear
- Jira – komplex, für die Größe eines KMU mit zu vielen Features
- Asana – generisches Projektmanagement
- GitHub Issues – wenn alles an die Codebasis gebunden ist
Alternativen zu Notion
- Confluence – im Atlassian-Stack
- Obsidian – Markdown-first, auf Einzelnutzer ausgelegt
- Coda – ähnlich wie Notion, Dokument plus Datenbank
- Google Docs – bereits vorhanden, aber die Suche ist schwach
Die Wahl erfolgt projektbezogen, es gibt kein „One size fits all".
Für wen es passt, für wen nicht
Das Remote-Setup passt nicht zu jedem. Im Folgenden die Muster, die sich bei uns gezeigt haben:
Gut geeignet für Remote
- Selbststarter, strukturiert – kann eigenständig tägliche Prioritäten setzen
- Komfortabel in asynchroner Kommunikation – schätzt Loom-artige asynchrone Updates
- Starke schriftliche Ausdrucksfähigkeit (über 50 % der Kommunikation läuft als Text) – klares, prägnantes Schreiben
- Stabiles Homeoffice-Setup (Internet, ruhiger Raum, ergonomischer Stuhl)
- Kann Probleme eigenständig lösen und fragt bei Bedarf nach – wartet nicht grundlos auf Senior-Hilfe, weiß aber, wann sie sinnvoll ist
- Zeitmanagement im Griff – Pomodoro, Deep Work, „Bitte nicht stören"-Signale
Weniger geeignet für Remote
- Extrovertierte Personen, die soziale Kontakte auftanken – ein Videocall ersetzt nicht den Büro-Kaffee
- Neu im Fachgebiet (Junior – persönliches Mentoring ist deutlich effektiver) – in den ersten 6–12 Monaten ist persönliches Mentoring entscheidend
- Bevorzugt eine lockerere Tagesstruktur – die „mach ich später"-Haltung bremst im Remote-Kontext
- Häusliches Umfeld unterstützt den Fokus nicht (Kinder, Mitbewohner, Wohnungsgröße) – hohes Ablenkungsniveau
- Visuelle oder kinästhetische Lerntypen – Lernen per Videocall ist weniger effektiv
Wir halten keine dieser Eigenschaften für „schlecht" – das Remote-Setup passt einfach nicht zu jedem. Es gibt Partnerunternehmen, bei denen ein Hybrid- oder reines Büro-Setup besser funktioniert.
Die Hybrid-Alternative
Das Muster „ein bis zwei Tage Büro pro Woche, der Rest remote" funktioniert bei vielen unserer Partnerunternehmen. Wir selbst haben uns nicht dafür entschieden, empfehlen es aber in Kundenprojekten häufig denjenigen, die gerade den Übergang erwägen.
Eine Woche in der Praxis – Montag bis Freitag
Eine typische Woche bei uns:
Montag
- 8:30 Uhr Morning-Check-in
- 9–12 Uhr: Deep-Work-Block (Coding oder Dokumentation)
- 12–13 Uhr: Mittagspause
- 13–14 Uhr: wöchentlicher interner Sync (45-minütiges Standup, kleines Team)
- 14–17 Uhr: Kunden-Call oder Projektarbeit
- 17–18 Uhr: Wrap-up
Dienstag
- 8:30 Uhr Morning-Check-in
- 9–13 Uhr: Deep Work
- 13–16 Uhr: Kunden-Calls (1–2)
- 16–17 Uhr: Code-Review
- 17:30 Uhr Wrap-up
Mittwoch
- 8:30 Uhr Morning-Check-in
- 9–12 Uhr: Deep Work
- 12–13 Uhr: Mittagspause
- 13–14 Uhr: 1:1 mit der Führungskraft (sofern vorhanden)
- 14–17 Uhr: Projektarbeit
- 17:30 Uhr Wrap-up
Donnerstag
- 8:30 Uhr Morning-Check-in
- 9–12 Uhr: Deep Work
- 13–14 Uhr: Kunden-Demo (wöchentlich, sofern ein laufendes Projekt besteht)
- 14–17 Uhr: Projektarbeit
- 17:30 Uhr Wrap-up
Freitag
- 8:30 Uhr Morning-Check-in
- 9–12 Uhr: Deep Work / offen (Innovation-Time)
- 13–14 Uhr: wöchentliches Retro (30 Minuten + 30 Minuten stilles Durchlesen der Dokumente)
- 14–17 Uhr: leichtere Aufgaben, Code-Cleanup
- 17:30 Uhr Wrap-up
Freitags vermeiden wir anspruchsvolle Kunden-Calls – die frischen Erkenntnisse aus dem Retro sollen nicht unnötig in anstrengenden Meetings verpuffen.
Anti-Patterns – was Sie vermeiden sollten
1. „Always on"-Kultur
Der Slack-Status „online" bedeutet nicht, dass man immer erreichbar ist. Das „Do not disturb"-Signal ist zu respektieren.
2. Die Erwartung „asynchron, aber bitte sofort antworten"
Eine asynchrone Nachricht wird innerhalb von maximal vier Stunden beantwortet. Ist es dringend, dann synchron (Call).
3. Zu viele Meetings
Das Muster „zwei bis drei tägliche Standups plus vier bis fünf Syncs" ist im Remote-Kontext ermüdend. Zwei bis drei Stunden Meeting-Budget sollten das Tagesmaximum sein.
4. Entscheidungen ohne Dokument
„Wir haben darüber gesprochen und entschieden" gilt nur, wenn es auch im Dokument festgehalten ist. Andernfalls gilt es als „verloren".
5. Die Haltung „managt sich selbst" – zu früh
Die ersten drei Monate eines Junior-Teammitglieds sollten persönlich oder mit täglichem 1:1 mit einer Senior-Person stattfinden. Die Annahme „remote = managt sich von selbst" scheitert.
Offizielle Dokumente und weiterführende Lektüre
- GitLab Remote Manifesto – als Full-Remote-Pionier
- Doist Remote Guide – Async-first-Prinzipien
- Buffer State of Remote Work – jährliche Branchenumfrage
- Async Manifesto – community-getriebene Async-Prinzipien
- Notion Remote-Work-Vorlagen – Vorlagensammlung
Verwandte Artikel von uns: Von Excel zu SAP für KMU – der Projektmanagement-Aspekt. KI-Implementierung bei ungarischen KMU – der KMU-Team-Flow. KI-Lead-Assistent für ein KMU aus der Automobilbranche – ein Workflow aus einem laufenden Projekt.
Fazit
Remote Work ist 2026 in der Tech-Branche kein Trend mehr, sondern die Standardoption. Doch der Ansatz „ich richte einen Slack-Workspace ein, und dann läuft es" funktioniert nicht – Remote-Disziplin erfordert Async-first-Kommunikation, eine Doc-first-Kultur und bewussten Teamaufbau.
Der hier beschriebene Workflow ist nicht der einzig richtige Weg – nur einer von vielen. Er funktioniert für uns, Ihre Erfahrung kann abweichen. Aber die Grundprinzipien (Async-first, Doc-first, wöchentliches Retro, Office-Hours-Buchung) finden sich in vielen erfolgreichen Remote-Teams – es lohnt sich, darauf aufzubauen.
Wenn Sie an einem gemeinsamen Projekt mit dem Corevanix-Team interessiert sind, lassen Sie uns in einem 30-minütigen Gespräch austauschen – in den ersten fünf Minuten sehen Sie, wie unser Team kommuniziert, und können entscheiden, ob das zu Ihrem eigenen Setup passt.