iOS MVP experience · Concept 01

Your website has a new colleague.

A mobile experience for non-technical owners to request, review, publish, and reverse website changes—with the ease of sending a message.

Native iPhone firstOwner-approved publishingEnglish · Bulgarian · GermanNo lock-in
Harriet home screen
Conversation with Harriet
Publishing success screen
Design position

Not a CMS.
Not a terminal.

Harriet should feel like a calm, capable employee who already knows the website. The owner describes an outcome; Harriet handles the implementation and returns with something concrete to approve.

01

Speak like an owner

Opening hours, 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
00 · The handoff

Value before setup.

The first screen begins with the migrated result—not account configuration. It makes speed, accessibility and ownership legible in seconds, matching the sales promise.

!This assumes Harriet invitations are sent only after an AI-generated migration has passed human review.
New website handoff screen
Harriet home dashboard
Natural language website request
01 · Ask naturally

A short request is enough.

The home screen has one dominant action: tell Harriet what changed. Common tasks reduce blank-page anxiety, while conversation supports nuance without 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.
Harriet request progress
Review a website change
Website change published
03 · Review & publish

AI acts. The owner decides.

The preview makes the proposed result concrete. A short quality summary supports trust, while a single deliberate publish action preserves the owner’s control.

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

Safety becomes a habit.

History is written in the owner’s language, not Git terminology. Website Care turns Harriet from a reactive editor into a useful ongoing subscription—with improvements that remain optional.

4Proactive suggestions can demonstrate recurring value, but they never publish themselves.
Website revision history
Website health and recommendations
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?