Unofficial client concept · Live lead 01

# Drei Stuben has a new colleague.

What Harriet could feel like for a real Zürich restaurant: request a change in German, review the actual brand, and publish without opening a CMS.

Live business in ZürichGerman owner experienceOwner-approved publishingNo lock-in
Why Drei Stuben

## A real business makes the product question concrete.

Drei Stuben is an active Zürich neighbourhood restaurant with a visually distinctive live website, frequently changing menus, events, opening hours, a garden terrace, and German–English content—the kind of everyday context an AI website worker must understand.

4.5★Google rating across 664 reviews in the lead dataset
14GaultMillau points stated on the official website
100Static-fit score from Harriet’s lead qualification
887 msHomepage response measured by the lead finder

Unofficial exploratory concept based on publicly visible content from drei-stuben.ch and internal lead data captured in August 2026. Drei Stuben has not endorsed or approved this presentation. Proposed migration results and app health scores are illustrative.

Design position

## Still Drei Stuben.
Now easier to run.

Harriet should preserve the restaurant’s photography, handwritten identity, German voice, current event content, and reservation flow. The owner experiences a capable colleague—not a replacement brand or a technical dashboard.

01

### Speak like an owner

Terrace notices, event dates, photos and menus—not commits, builds and branches.

02

### Show, then explain

A visual result comes before implementation details or technical logs.

03

### Nothing goes live alone

Harriet prepares. The owner previews and explicitly publishes.

04

### Every action is reversible

Plain-language history makes restoration feel safe and ordinary.

The golden path

## From a passing thought to a safe live change.

01AskText, voice, photo or document
02ConfirmHarriet restates the outcome
03WorkVisible progress, no technical noise
04ReviewVisual preview and change summary
05PublishExplicit owner approval
06RestoreAny earlier revision, one tap
Current site → Harriet

## Start with what the owner already recognizes.

The left screen is the live Drei Stuben website captured while creating this concept. The right screen imagines the Harriet handoff using the same domain, handwritten identity, photography, and German voice.

↗The goal is not to erase the existing brand. It is to make that brand easier for its owner to operate.
00 · The handoff

## Their identity, already inside.

The first screen uses Drei Stuben’s real logo, photography, domain, and German copy. The owner should recognize the business before learning anything about Harriet.

!This assumes Harriet invitations are sent only after an AI-generated migration has passed human review.
01 · Ask naturally

## “The terrace is closed today.”

A weather-driven restaurant update becomes a normal German sentence. Harriet finds the right place, adds a clear notice, and avoids exposing coding-agent mechanics.

1Voice is visually first-class because owners are likely to use Harriet while moving between daily tasks.
02 · Work visibly

## Confidence without a terminal.

Owners see outcome-oriented steps: what Harriet found, changed and checked. They can leave the app and return when the preview is ready.

2Progress is intentionally honest but non-technical. Exact time promises should only appear when the backend can support them reliably.
03 · Review & publish

## Actual brand. Explicit decision.

The preview combines the proposed notice with Drei Stuben’s real interior photography and identity. The owner sees the customer-facing result before deliberately publishing.

3“Nothing is live until you approve it” should become a repeated product promise, not fine print.
04 · Remember & improve

## Restaurant history, not Git history.

Entries refer to the terrace, the Jungschwein event, and menu changes. Website Care can surface concrete opportunities such as making PDF menus easier to use on a phone.

4Proactive suggestions can demonstrate recurring value, but they never publish themselves.
Trust architecture

## The interface reflects the operating model.

Harriet’s technical differentiators—isolated agents, Git history, customer-owned hosting and portable source—become understandable customer promises.

H

### Private worker

Each customer’s agent and website run in an isolated workspace.

✓

### Approval gate

Production changes require a deliberate action from an authorized owner.

↶

### Full history

Every change is stored and an earlier revision can be restored.

↗

### Always yours

Source and hosting belong to the customer and survive Harriet.

MVP information architecture

## Three places, one job.

Avoid the temptation to mirror every backend object. The first app can remain extremely small.

01HomeWebsite status, primary request composer, and common tasks.
02RequestsConversations, active work, previews and decisions awaiting the owner.
03HistoryPublished revisions, previews and restoration controls.
+Website CareReachable from Home; health and optional optimization suggestions.
What this concept should test

## The screens are a hypothesis, not a specification.

01

Will owners trust a conversational request without seeing technical details?

02

Is a visual preview plus plain-language summary enough confidence to publish?

03

Do voice and quick requests reduce anxiety for people unfamiliar with AI?

04

Does website health create recurring value beyond occasional content updates?

05

Can customers understand revision restoration without Git vocabulary?

06

Which fixed interface terms need different phrasing in Bulgarian and German?