152 lines
6.7 KiB
Markdown
152 lines
6.7 KiB
Markdown
# Präsenzstrategie für Jan Wagner / w-make
|
||
|
||
Stand: 2026-08-15
|
||
|
||
## 1. Ziel
|
||
|
||
Die Präsenz soll drei Zielgruppen in weniger als einer Minute verstehen lassen:
|
||
|
||
1. **Industrie- und Mittelstandskunden:** Jan löst reale Prozessprobleme mit belastbarer Software.
|
||
2. **Technische Entscheider und Partner:** Jan kann Domäne, Architektur und Betrieb zusammen denken.
|
||
3. **Zukünftige Arbeitgeber:** Jan ist ein Senior Engineer mit Ownership, nicht nur ein Implementierer.
|
||
|
||
Primäre Conversion: qualifizierter Erstkontakt. Nicht: möglichst viele Projekte oder Technologien zeigen.
|
||
|
||
## 2. Empfohlene Positionierung
|
||
|
||
> Ich entwickle robuste digitale Systeme für industrielle und anspruchsvolle Geschäftsprozesse — mit Domänenverständnis, klarer Architektur und Verantwortung für den Betrieb.
|
||
|
||
Die Positionierung ist stärker als „innovative Lösungen“ oder „Full-Stack-Entwicklung“, weil sie ein Problem, eine Zielgruppe und einen Qualitätsanspruch benennt.
|
||
|
||
## 3. Was bewusst nicht auf die öffentliche Startseite gehört
|
||
|
||
- Casino-Automation und Echtgeld-Workflows
|
||
- Trading-/Prediction-Market-Projekte
|
||
- Interne Hermes-Infrastruktur, Bot-Namen und Serverdetails
|
||
- Unbelegte Zahlen wie Testanzahl, Verfügbarkeit oder Effizienzgewinne
|
||
- „Enterprise-Niveau“, „24/7 verfügbar“ oder ähnliche Behauptungen ohne veröffentlichbare Nachweise
|
||
|
||
Diese Themen können privat als technische Lernprojekte oder auf Anfrage erscheinen. Öffentlich verwässern sie die B2B-Positionierung und können bei Kunden bzw. Arbeitgebern unnötige Risiko- und Vertrauensfragen auslösen.
|
||
|
||
## 4. Inhaltliche Säulen
|
||
|
||
### A. Industrie-Software und Domäne
|
||
|
||
Der stärkste Beleg ist W-Make Batch. Daraus entstehen:
|
||
|
||
- Case Study: „Wie aus einem Produktionsprozess ein belastbares Softwaresystem wird“
|
||
- Architekturartikel: „Warum fachliche Buchungen nicht einfach gelöscht werden dürfen“
|
||
- Prozessartikel: „Vom Satzzettel zum Tagesprotokoll: ein durchgängiges Produktionsmodell“
|
||
- Produktseite: Problem → Lösung → Arbeitsweise → Demo/Kontakt
|
||
|
||
### B. Engineering-Entscheidungen
|
||
|
||
- Datenintegrität statt schneller CRUD-Logik
|
||
- Fachliche Regeln als explizite Invarianten
|
||
- Kleine, testbare Module statt verteilte Business-Logik
|
||
- Migrationen, Backups, Auditierbarkeit und sichere Fehlerpfade
|
||
|
||
### C. Persönliche Perspektive
|
||
|
||
- Übergang von Glass Technology zu Software Engineering
|
||
- Was Domänenwissen in der Produktentwicklung verändert
|
||
- Entscheidungen, die im Betrieb wichtiger sind als im Demo-Video
|
||
- Ehrliche technische Rückblicke mit Problem, Entscheidung, Ergebnis und offenem Rest
|
||
|
||
## 5. Seitenstruktur für den öffentlichen Auftritt
|
||
|
||
1. **Startseite:** Positionierung, 1–2 Belege, Arbeitsweise, Kontakt
|
||
2. **Über mich:** Glas-/Industrie-Hintergrund, Senior-Engineering-Profil, Arbeitsprinzipien
|
||
3. **W-Make Batch:** eigenständige Case Study mit Screenshots/Diagramm und klarer Abgrenzung zu vertraulichen Kundendaten
|
||
4. **Engineering Notes:** 4–6 substanzielle Artikel statt Newsfeed
|
||
5. **Kontakt:** E-Mail, LinkedIn/Git-Profil, Einsatzformen, Standort/remote
|
||
6. **Impressum/Datenschutz:** vor öffentlichem Launch rechtlich vervollständigen
|
||
|
||
## 6. Case-Study-Template
|
||
|
||
Jede Referenz folgt demselben Muster:
|
||
|
||
- **Ausgangslage:** Welcher Prozess war schwierig oder fehleranfällig?
|
||
- **Verantwortung:** Welche Rolle und welchen Anteil hatte Jan?
|
||
- **Entscheidungen:** Welche Architektur-/Domänenentscheidungen waren entscheidend?
|
||
- **Ergebnis:** Nur belegbare Resultate; vertrauliche Werte anonymisieren.
|
||
- **Beweis:** Screenshot, vereinfachtes Modell, Teststrategie oder öffentliche Demo.
|
||
- **Lernpunkt:** Was kann ein anderer technischer Entscheider daraus übernehmen?
|
||
- **CTA:** Gespräch über einen ähnlichen Prozess.
|
||
|
||
## 7. Priorisierte 30-Tage-Roadmap
|
||
|
||
### Woche 1 — Vertrauen und Basis
|
||
|
||
- Eigene Domain-/Unternehmensbezeichnung festlegen.
|
||
- Professionelle Kontaktadresse und LinkedIn-Profil verknüpfen.
|
||
- W-Make Batch als Referenz auf Freigabe und Vertraulichkeit prüfen.
|
||
- Impressum-/Datenschutz-Anforderungen vor Launch mit fachkundiger Stelle klären.
|
||
|
||
### Woche 2 — Belege
|
||
|
||
- Case Study zu W-Make Batch schreiben.
|
||
- 3–5 aussagekräftige Screenshots oder ein anonymisiertes Prozessdiagramm erstellen.
|
||
- Rolle, Zeitraum, Verantwortung und veröffentlichbare Ergebnisse sauber dokumentieren.
|
||
|
||
### Woche 3 — Auffindbarkeit
|
||
|
||
- LinkedIn-Headline an die Positionierung anpassen.
|
||
- Eine Engineering Note veröffentlichen.
|
||
- Profile konsistent verlinken: Website, LinkedIn, GitHub/Gitea nur wenn öffentlich geeignet.
|
||
- Title, Description, Open Graph, Sitemap und Search Console ergänzen.
|
||
|
||
### Woche 4 — Conversion
|
||
|
||
- Kontaktformular oder klare E-Mail ergänzen.
|
||
- Angebot in 2–3 konkrete Einstiege übersetzen: Prozessanalyse, technische Due Diligence, Produkt-/Backend-Entwicklung.
|
||
- Jede Seite mit genau einem nächsten Schritt versehen.
|
||
- Mobile, Tastaturbedienung, Ladezeit und externe Links prüfen.
|
||
|
||
## 8. Konkrete Angebotsformulierungen
|
||
|
||
### Prozessanalyse
|
||
|
||
> Ich analysiere einen bestehenden digitalen Prozess, identifiziere fachliche Bruchstellen und übersetze die Ergebnisse in eine priorisierte technische Roadmap.
|
||
|
||
### Produkt- und Backend-Entwicklung
|
||
|
||
> Ich entwickle oder stabilisiere Anwendungen, bei denen Datenmodell, Geschäftslogik und Betrieb wichtiger sind als ein schneller Prototyp.
|
||
|
||
### Technische Zusammenarbeit
|
||
|
||
> Ich unterstütze Teams bei Architekturentscheidungen, schwierigen Integrationen und der Überführung von gewachsenem Code in ein wartbares System.
|
||
|
||
## 9. Noch offen vor dem Launch
|
||
|
||
- Öffentlich verwendbare Kontaktadresse
|
||
- Vollständiger Name/Firmierung nach UG-Gründung
|
||
- Impressums- und Datenschutzhinweise
|
||
- Freigabe zur Darstellung von W-Make Batch und verwendbaren Screenshots
|
||
- Tatsächliche öffentliche Profile/Links
|
||
- Messbare Ergebnisse, sofern sie veröffentlicht werden dürfen
|
||
|
||
## 10. Erfolgskriterien
|
||
|
||
Nach dem ersten Ausbau muss ein fremder Besucher beantworten können:
|
||
|
||
- Was macht Jan konkret?
|
||
- Für wen ist das relevant?
|
||
- Woran ist die Qualität erkennbar?
|
||
- Wie kann ich Kontakt aufnehmen?
|
||
|
||
Wenn eine Information nicht auf eine dieser vier Fragen einzahlt, gehört sie nicht auf die Startseite.
|
||
|
||
## Quellen aus dem Workspace
|
||
|
||
- `/home/eldov-ryzen5/workspace/Coding/Batchmaker/README.md`
|
||
- `/home/eldov-ryzen5/workspace/Coding/Batchmaker/AGENTS.md`
|
||
- `/home/eldov-ryzen5/workspace/Server/README.md`
|
||
- `/home/eldov-ryzen5/workspace/Coding/hermes-tools/README.md`
|
||
- `/home/eldov-ryzen5/workspace/w-make-com/src/app/page.tsx`
|
||
- `/home/eldov-ryzen5/workspace/w-make-com/src/app/layout.tsx`
|
||
|
||
Die Quellen belegen technische Substanz. Kundennamen, Resultate und Rollen dürfen nur nach Freigabe öffentlich behauptet werden.
|
||
|
||
<!-- ponytail: Keine Personen-, Kunden- oder Leistungsbehauptungen ergänzen, solange kein veröffentlichbarer Beleg vorliegt. -->
|