Technische Stellungnahme

Ja. Between würden wir als durchgängiges System bauen:

• App (Frontend): iOS & Android (z. B. React Native / Flutter, final im Kickoff)
• Backend-API: eigene Server-API (Auth, Business-Logik, KI-Proxy, Billing-Status)
• Datenbank: PostgreSQL (User, Sessions, Nutzungszähler, Metadaten der Analysen)
• Dateispeicher: Objekt-Storage mit serverseitiger Zugriffskontrolle (nur für den jeweiligen User), TLS, keine öffentlichen Dauer-Links ohne Ablauf

Accounts mit Passwort-Hashing, geschützten Sessions und serverseitigen Rechten. nicht nur „im Client ausgeblendet“.

@app.post("/auth/register", status_code=201)
def register(..):
    user = User(
        username=username,
        password_hash=hash_password(payload.password),
        display_name=payload.display_name.strip(),
    )
    # Session-Token nur serverseitig signiert (nicht im Client „gebaut“)

Ja, das ist der einzig sinnvolle Weg.

• API-Keys liegen ausschließlich serverseitig (Secrets/Env), nie in der App und nie im Frontend-Bundle
• Die App spricht nur mit unserem Backend. Das Backend ruft den KI-Anbieter auf
• Rate-Limits, Auth-Check und Nutzungszähler (Free-Uses) vor jedem KI-Call

class Settings(BaseSettings):
    # geladen aus Server-.env, nicht im Client-Binary
    database_url: str
    user_session_secret: str
    apns_auth_key: str = ""   # .p8 nur auf dem Server
    # Between analog: OPENAI_API_KEY / ANTHROPIC_API_KEY hier

Ja, mit klarer Pipeline und Limits. Technischer Ablauf:

1. Upload → Typ-/Größen-Check → Speicherung usergebunden
2. Extraktion: Text aus .txt / Chat-Export.zip entpacken (Whitelist Dateitypen). Screenshots als Bilder
3. Normalisierung / Chunking (große Chats werden sinnvoll aufgeteilt)
4. KI-Auswertung über Backend → strukturiertes Ergebnis in der App

MAX_UPLOAD_BYTES = 8 * 1024 * 1024
ALLOWED_CONTENT = {"image/jpeg", "image/png", "image/webp", ..}

def process_avatar_image(raw: bytes) -> bytes:
    image = Image.open(io.BytesIO(raw)).convert("RGB")
    image = image.resize((256, 256), Image.Resampling.LANCZOS)
    # speichern unter /media/avatars/{user_id}.jpg

Umsetzbar und vorgesehen. Für Between empfehlen wir pragmatisch RevenueCat (oder vergleichbar) als Schicht über Apple IAP und Google Play Billing: einheitliche Receipt-Validierung, weniger Plattform-Sonderfälle, serverseitig abgleichbarer Abo-Status.

• Free-Uses serverseitig zählen (nicht nur lokal manipulierbar)
• Paywall nach Verbrauch: Abo und/oder Einmalkauf. Produkt-IDs legen Sie im Store fest
• Backend entscheidet anhand Kaufstatus, ob KI-Calls erlaubt sind

Ja. Build-Pipelines, TestFlight-Intern/Extern, Play Internal/Closed Testing, Store-Listings technisch vorbereiten und den ersten produktiven Upload begleiten. auf Basis Ihrer Developer-Accounts.

Voraussetzung: funktionierende Apple-/Google-Entwicklerkonten auf Ihren Namen, Zugang für uns (oder gemeinsame Sessions) für Zertifikate, Bundles und Review-Uploads.

# backend/Dockerfile: produktiver API-Start
CMD ["gunicorn", "app.main:app",
     "-k", "uvicorn.workers.UvicornWorker",
     "-w", "3", "-b", "0.0.0.0:8000"]

Technische Maßnahmen, die wir umsetzen können und für Between vorsehen:

• Strikte User-Isolation in DB und Storage (jeder Zugriff prüft die User-ID)
• TLS in Transit. Speicherung nur für eingeloggte, berechtigte Nutzer
• Kein Teilen von Analyse-Dateien zwischen Accounts
• Account-/Datenlöschung: User-Daten, Uploads und Analyseergebnisse entfernen bzw. unkenntlich machen
• Minimale Logs (keine Chat-Volltexte in Klartext-Logs, soweit betrieblich vermeidbar)

@app.delete("/users/me", status_code=204)
def delete_own_account(..):
    """Immediate account deletion (Apple Guideline 5.1.1(v))."""
    delete_user_account(db, user, payload.password)

# account_deletion.py
delete_avatar_file(user_id)
# Reports/Texte → Placeholder "[deleted]", Retention-Job räumt nach

Ja. Architektonisch vorbereitet, aber kein reiner Konfigurationsklick.

Wir kapseln die KI hinter einer internen Schnittstelle (z. B. AnalysisProvider). App und Domänenlogik sprechen nur dieses Format. Dahinter liegen austauschbare Adapter (OpenAI, Anthropic, …). So vermeiden wir, dass die ganze App an ein Hersteller-SDK klebt.

Was ein späterer Wechsel trotzdem bedeutet:

• neuen Adapter + Auth/Limits verdrahten
• Prompts und strukturierte Outputs neu kalibrieren (Modelle antworten unterschiedlich)
• Vision/Screenshot-Pipeline und Chunking an Kontextfenster/Preise anpassen
• Regressionstests an einem festen Beispiel-Set (Qualität, nicht nur „HTTP 200“)
• ggf. neue AV/DPA und Regionen beim Anbieter

Realistisch: Wechsel ist planbar (typisch Tage bis wenige Wochen je nach Tiefe), nicht „Feature-Flag und fertig“. 100 % identische Antworten zwischen Anbietern gibt es nicht. Parallelbetrieb / Fallback ist optional und zusätzlicher Aufwand.

class ZoneLike(Protocol):  # austauschbare Geometrie-Logik
    shape: str
    center_lat: float
    ..

# Between-Skizze (geplant):
class AnalysisProvider(Protocol):
    def analyze(self, payload: AnalysisInput) -> AnalysisResult: ..

class AnthropicAdapter: ..
class OpenAIAdapter: ..

Ja. So arbeiten wir.

• Vollständiger Quellcode der für Between entwickelten Software bei Abnahme/Übergabe
• Technische Dokumentation (Setup, Deploy, Umgebungsvariablen, Datenfluss)
• Zugangsdaten / Übergabe der von uns eingerichteten Projektteile
• Nutzungsrechte laut Vertrag (Standard: Sie als Auftraggeber für das Projektergebnis)

Accounts: Apple Developer, Google Play, KI-Provider, Hosting, RevenueCat/Payments sollten von Beginn an auf Ihr Unternehmen laufen. Wir unterstützen Einrichtung und technische Anbindung. Eigentümer sind Sie. So bleiben Abrechnung, Steuern und Store-Verantwortung klar.

def require_project_role(.., require_approver=False):
    """Developers bypass membership. Accounts brauchen Rolle."""
    if actor.kind == "developer":
        return None
    if require_approver and member.role != "approver":
        raise HTTPException(status_code=403, ..)

Beispiele: unklare Datenschutzangaben, fehlende Account-Löschung laut Vorgabe, Abo-Hinweise, Inhalte, Login-Zwang, Nutzung von Daten Dritter usw.

Haftung / Nacharbeit: Solche Ablehnungen liegen außerhalb der rein technischen Umsetzung vertraglich spezifizierter Funktionen. 282studio übernimmt keine Haftung für die Store-Freigabe durch Apple/Google. Anpassungen, die nötig werden, weil Richtlinien, Reviewer-Auslegung oder fehlende rechtliche/inhaltliche Voraussetzungen es erfordern und die nicht im vereinbarten Leistungsumfang standen, werden gesondert beauftragt und berechnet.

Beispiele: Crash beim Start, Login funktioniert nicht, Kaufstatus wird falsch erkannt, Upload/Analyse bricht ab, bezogen auf Features, die vertraglich als Liefergegenstand der Erstveröffentlichung festgehalten sind.

Nachbesserung: In diesem Fall erfülle ich im Sinne der Nachbesserung die vertraglich festgesetzten Funktionen der App im Rahmen der Erstveröffentlichung, ohne dass Policy-Themen oder Scope-Erweiterungen darunterfallen.