{{ background }}
02 · Product & UI · Frontend

Alfred Co.host platform

The cockpit hosts use to configure Alfred. If the docs explain how Alfred works, the platform is where you make it work — an owner-facing web app to add properties, teach Alfred what to know, choose which channels to go live on, and manage the subscription.

Alfred co.host logo

The product

What Alfred Co.Host is

Alfred is an AI guest assistant for hotels, BnBs and vacation rentals. It handles guest messaging across Airbnb, Booking.com, WhatsApp, email and more — answering in seconds, in any language, 24/7, drawing from each property’s own information rather than generic scripts. The platform is the control room behind it: where the host sets up everything the assistant guests actually talk to needs to know.

Hotels BnBs & guesthouses Vacation rentals Property managers & co-hosts

Role

Product & UI design + frontend

Timeframe

2024 – ongoing

UI & FRONTEND STACK

Figma → React, Github, Claude Code, Codex

Who built what

The core — dashboard, KB editor, property management, subscriptions, profile — was designed and prototyped by me in Figma and implemented by a developer. The booking calendar, PMS integrations, embedded documentation and both chatbots (Alfred and Robin) I prototyped and vibecoded myself with Claude Code and Codex. Built for hospitality operators with wildly uneven digital literacy — from the tech-savvy property manager to the family B&B that has used nothing but WhatsApp for three years.

Alfred in a blink

What users actually do in the platform

1

Create properties & their library

Add each property and build its knowledge base from preconfigured library items — fields already named and described, so you fill in rather than start from scratch.

2

Manage each property’s subscription

Every property has its own plan, billing cycle and renewal date — all aggregated into one tabular view in your profile.

3

Test the AI before going live

Chat with Alfred using your own KB, across stay phases (pre-stay, stay, post-stay), and confirm it’s ready before guests ever reach it.

4

Customize the edges

Add custom fields, shape the escalation logic, and choose channels per property — WhatsApp, Telegram, or an iframe on your own site.

The challenges

Four problems worth solving

Configuring an AI, not a back-office

Most B2B tools have a user who already knows what they want. Here the user has to teach a system — what the chatbot knows, how much, for which property. The job was making that clear to someone who has never heard the words “knowledge base.”

Wildly uneven digital literacy

From the co-host with 20 properties to the owner of a single flat who signed up on a friend’s tip. The interface had to serve both — without patronising the first or overwhelming the second. No 12-step onboarding, no technical glossary.

Multi-property, separate subscriptions

Every property lives independently: its own plan, live or not, different channels active. Making that parallelism legible — without it collapsing into a configuration table — was non-trivial.

Design decisions into production React

The vibecoded work closed the gap between prototype and implementation directly — Claude Code to write real components, not mockups. It changed how I design: I now think in terms of state, not just screens.

Visual identity

Calm by design, not understyled by accident

Both the colour direction — chosen together with the team — and the broader UI of the platform, which I owned, were a deliberate bet on simplicity. The audience is huge and spans roughly 25 to 65: a single property owner and a 20-unit professional co-host use the same screens. That ruled out anything that depended on being digitally fluent.

So the interface is quiet, familiar and unhurried — legible type, generous spacing, one accent colour, no decorative motion. Not ultra-modern, not animation-heavy, not a parade of shapes and gradients. Restraint is the feature: the real fear was that a less tech-confident host would get lost in a busy, “designed” interface — that visual noise would read as stress, not delight. Every element earns its place, and the rest gets out of the way to keep cognitive load low without ever feeling dull.

The Alfred red, and why it leans on Airbnb

The Alfred red is, unmistakably, a derivative of the Airbnb red — and that was the point. For a worldwide audience that already lives inside Airbnb every day, a closely related red buys instant cognitive continuity and a quiet sense of reassurance: it feels native to the world hosts already operate in, before they’ve read a single label.

Logo

Alfred co.host logo

Colour lineage

Alfred red

#FF4D4D · accent

Airbnb “Rausch”

#FF5A5F · the reference

Approach

Decisions that came from the user

01

Flat navigation by design

The most deliberate Information Architecture decision was flattening navigation. Five main clusters — Dashboard, Property management, Calendar, Integrations, Documentation — reachable from the side drawer with no sub-menu hierarchy. No three-level paths, no “Settings > Property > Channel > Advanced.” The complexity exists, but it’s handled inside each cluster, not through navigation. A host juggling three properties shouldn’t have to remember where things are — they should find them by instinct the first time and by muscle memory the second.

02

Per-property subscriptions

The subscription model mirrors the reality of multi-property hospitality: properties aren’t the same and don’t carry the same volume. Each has its own plan, billing cycle (monthly/yearly) and renewal date. The host profile aggregates all of it into a single tabular view — no navigating property by property.

My subscriptions table aggregating every property: name, billing cycle, plan type and renewal date, each with change-plan and delete actions
03

Onboarding: the first login forces you to create

On first login the host is guided to create their first property before anything else. It guarantees the system has something to work with — but it also trains: the host learns the platform’s mental model the moment they first use it. The full funnel: site → pick a plan → sign up with a 15-day trial → first login → forced creation of the first property. Onboarding as UX, not marketing.

The Add A New Property modal that opens on first login: internal name, guest-facing name and a guest access PIN
04

Property view: everything inline, zero drill-down

From the property list you do everything without entering a sub-page: open the KB editor, duplicate a configuration, test the chatbot, manage activation per channel. Actions are inline icons on each row, the “Go live” toggle is immediate, and supported channels — WhatsApp, Telegram, and an iframe for embedding Alfred on your own site — are visible at a glance for every property. For anyone running more than one place, that’s the difference between a tool and a usable tool.

Screen recording of the property overview list: inline edit, library, duplicate, test and delete actions per row, channel badges and an immediate Go live toggle
05

KB editor: killing blank-page anxiety

The most critical onboarding moment is asking a host to “enter information about your property.” The instinctive reaction: which information? all of it? in how much detail? The answer was to map the categories a guest statistically needs most — Access & Check-In, House Rules, Amenities, Local Tips, Emergency Contacts — and ship preconfigured library items for each, with fields already named and described. The host doesn’t write from scratch; they fill in: “WiFi Network Name — the name of the WiFi network guests should connect to.”

The strength of the KB isn’t the volume of information but the granularity of the items — each field is a self-contained molecule. Alfred doesn’t need paragraphs, it needs precise, well-isolated facts; the prompt does the contextualising. Even a host who fills in three fields gets a working chatbot.

06

Terminology consistent with the docs

Every term in the platform — library item, stay phase, knowledge base, hands-off number — is the same one used in the documentation, chosen after researching industry jargon, talking to operators, and keyword analysis with Semrush. A host who read the docs should land in the platform with no mental translation.

The feature

Two chatbots, two jobs

The platform runs two conversational surfaces side by side — both vibecoded with Claude Code, both built on the same logic pointed in opposite directions. One lets the host test the product they’re building; the other helps them learn how to run the platform itself.

A

Alfred — test the assistant

Left · the product you’re building

Straight from the property list, the host types a question as if they were their own guest. Alfred answers using exactly what was entered in the KB, and a stay-phase selector (pre-stay, stay, post-stay) reflects how questions shift across the moment of the stay. The reality check: before handing Alfred’s contact to guests, you confirm it knows how to reach the flat, the WiFi code, the check-out time. It stops being an opaque system that “should work” and becomes something you can interrogate yourself.

R

Robin — learn the platform

Right · how to use the tool

Robin runs the same logic in the opposite direction: it answers the host’s questions about the platform itself — subscriptions, channels, the KB editor — not the properties. The manager’s assistant, not the guest’s. Where Alfred is the thing being configured, Robin is the help desk that explains how to configure it.

Side by side: Alfred testing a guest conversation for a property, and Robin answering a platform-support question
The two panels side by side — Alfred (left) answering as the property’s guest assistant, Robin (right) handling a question about the platform.
The Alfred test panel with its stay-phase selector open, showing pre-stay, stay and post-stay options
The stay-phase selector open on the Alfred panel — switching context between pre-stay, stay and post-stay so the host can test how answers change.

Microcopy & friction

Friction calibrated to the stakes

Not every dialog deserves the same weight. A sensitive action has to seize attention and not let go until the host understands the consequence; a routine, repetitive one should get out of the way. Two opposite ends of that scale — and the copy stays in the language hosts actually use in hospitality, never generic SaaS-speak.

Sensitive

Force the focus, then explain in full

Deleting a subscription dims the whole app behind a modal that can’t be ignored — the action is the only thing in focus. Here I deliberately allowed more copy: it spells out exactly what happens (the plan stays active until the end of the billing cycle, then the AI assistant is unpublished) and points to the gentler alternative — untoggling Go live. Exhaustive, but kept tight: two short paragraphs, the irreversible consequence in red, and the two choices weighted by colour, never a bare “are you sure?”.

Delete subscription confirmation modal dimming the app, with the irreversible consequence highlighted in red and two weighted choices
Routine

Strip it down to a form everyone knows

Adding a custom library item is the opposite job. Everyone has filled in a closed, guided form before, so I leaned on that muscle memory: label, short description, a type toggle (string, image, video), a drop zone. No instructions, no theory of what a “custom item” is — just named fields and a clear save. The friction is near-zero because the pattern is already familiar, and the same vocabulary from the docs (library item, info type) carries straight through.

Add custom info modal: a guided closed form with label, short description, info-type toggle and a file drop zone

Build story

Two ways of building

The whole design and prototyping perimeter is mine. For the core, I worked in Figma alongside the developer — from the first wireframe to the handoff on Jira, the developer implemented from my prototypes. The second phase — booking calendar, PMS integrations, embedded documentation, Alfred and Robin — bypassed Figma entirely: it came straight from my head, built conversationally in React with Claude Code and Codex. No mockup in between. I described the component, vibecoded it, reviewed it visually, and adjusted it to fit the existing design system — a continuous loop, not prompt-and-paste.

The component I’m proudest of technically is the inline chatbot test — it requires state management between the property list and the conversation panel, and it’s where product logic and implementation touch most closely. It’s also the one that works best in the demo.

Limits & what’s next

Honest about the edges

Touchpoints still need to expand. Alfred reaches guests on a focused set of channels today. The next step is widening that coverage — more messaging surfaces and integrations — so a host can meet guests wherever they already are, not where the platform happens to support.

We rely on third parties we don’t control. The assistant is built on external LLMs and channels like WhatsApp, so their availability, policy changes and pricing sit outside our hands. It’s a deliberate trade-off — and one we’re transparent about: the dependency is spelled out in the terms & conditions accepted at subscription.

The host can’t pick Alfred’s contact number. The number guests message Alfred on is assigned by us, not chosen by the client — the only number the host controls is the hands-off number, the one Alfred escalates to when it passes a conversation to a human. Letting hosts bring or choose Alfred’s own number is something to improve later.

See it live

If the demo doesn’t load pages correctly, just refresh the page — it usually comes back on a second try. And for product-protection reasons, this is a partial demo: not every flow is enabled.

alfred-demo-sarah-lasaracina.netlify.app
See widescreen website

Get in touch

Let’s talk.

Got a project, a role, or just want to swap kitty pictures and plant-based recipes? I’d love to hear from you.

sarahlasaracina@gmail.com LinkedIn 📅 Meet me on lunch break