UX audit and proposal

1 Summary

This document is the result of a UX audit of the Hostify mobile app, done between 28 September and 1 October 2026 on our rebuild of the app. It proposes a redesign of every area a property manager, a worker and an owner uses, shows each change as two pictures of the same screen with the same data (how the app works today, and a working prototype of the proposal), and ends with the questions only Hostify can answer.

The audit covered ten areas: the inbox, reservations, the calendar, tasks, revenue and the owner's views, listings, expenses, updates and links, signing in, and the shell with its tab bar. It recorded 185 findings, walked 27 everyday workflows step by step, and produced 29 proposals. On the main path of those workflows, 253 taps become 177, about 30 percent fewer. The count understates the gain: three tasks change kind rather than length. Sending an owner their statement becomes possible (today it ends in "not built yet"), finding a double booking stops depending on memory and luck, and reordering photos becomes something a manager can find.

The redesign is built on a small number of rules that apply everywhere, listed in the chapter on design principles. The most visible ones are that nothing is said twice on one screen, that the usual state goes unsaid and only the exception speaks, that a reversible act happens at once with Undo while an irreversible one asks once with buttons that name their results, and that every control shows its current state. The rules were made area by area, so a final pass held every picture against all of them at once and made the same thing look and behave the same way on every screen.

A design system goes with the rules: one type scale, one grey ramp with the brand blue reserved for the one filled button and the chosen tab, depth by tone and a hairline instead of shadows, a short scale of corner radii, named durations for motion, a haptic vocabulary, and tabular figures on every amount. It is described in its own chapter, and three looks built from it are shown on four screens for Hostify to choose from. The lead's recommendation is the quiet one, with the tonal cards kept for the KPI tiles alone.

Nothing in the proposal needs a backend change to be built. Where a change would make a screen better than the current API allows, the screen is built on what exists today and the question is listed at the end, with what the app does until the answer comes.

The pictures were taken from a build that runs on test data. Names, guests and amounts are invented.

2 How the audit was made

The audit worked on our rebuild of the Hostify mobile apps. The rebuild copies what the current apps do, screen by screen, and runs on a local set of test data that holds every state the backend can produce: an empty list, a failed request, a name at the longest length the backend accepts, a guest party of six, a listing with 500 rows behind it. Every picture in this document comes from an automated walk through that build on an iPhone simulator. Nothing is drawn by hand, and the pictures are taken again after every change, so a page and its pictures always describe the same version.

2.1 The "before" pictures

They show our rebuild, not the current apps. Where the rebuild already fixed a defect of the current apps, the picture shows it fixed, so a "before" may look slightly better than what users see today. Nothing in this document is a defect of our own build presented as Hostify's.

2.2 Five passes

The audit went through the app five times, each with a different question.

• An inventory of every screen: what it is for, who sees it, how it is reached, what every control does, and pictures of its states and of everything it opens on top of itself. 444 pictures over ten areas.
• A walk through the 27 tasks each role does most often, counted in taps, scrolls, sheets and decisions. The counts are the baseline the proposals are measured against.
• A comparison of every pattern the app uses (choosing, searching, confirming, loading) against the way the rest of the app does the same job. Seventeen jobs were done 65 ways. One way per job was chosen, with the reason.
• A benchmark against the apps people already know: iOS Mail for a list of records, the messaging apps for a conversation, the booking tools for a host's calendar, and Apple's and Google's guidelines, the Nielsen Norman Group and Baymard for the rest. We borrowed how they behave, never how they look. Every screen keeps Hostify's colours and brand.
• An accessibility floor: contrast at 4.5:1 for text and 3:1 for marks, touch targets of 44 points, a visible path for every gesture, and every string in every language. The current app fails the contrast floor on its primary blue, its warning colour and its selected tab.

2.3 Prototypes, not drawings

Each proposal was built as a working prototype inside the rebuild, on the same data and the same backend calls as the screen it replaces. That is why the "after" pictures show real data at the backend's limits, and why a change that looked good on paper and broke at 500 rows was caught before it reached this document. A small set of rules, written down as each area was approved, was then checked mechanically over every prototype, so a later screen could not drift from an earlier decision.

2.4 Where the numbers come from

Taps and decisions are counted on the walks of the 27 workflows. Screen shares (how much of the conversation screen the messages get) are measured on the pictures. Contrast ratios are computed with the WCAG formula from the colour values in the code. A number this document cannot back is not in it.

3 Design principles

Eleven rules guided every screen in this document. They were written down as the areas were designed and approved, and the last pass of the audit checked every picture against all of them. Each rule names the problem it answers in the current app.

3.1 Content first

The thing the user came for gets the screen. In a conversation today the messages get 44 percent of the screen, and 19 percent with the keyboard up; controls, bands and a second composer row take the rest. The proposal gives the messages about 60 percent with the tab bar kept. Titles, search boxes and chips scroll away with a list and come back on the first pull down. A photo is an element of a page, an 80-point tile beside the facts, never a banner that pushes them below the fold.

3.2 One way per job

The app does each job one way. One sheet, with a handle, a title, a visible Cancel and a footer that stays in view. One way to choose from a list, with the current choice marked by the component itself so no screen can forget it. One search behaviour, one date grammar, one failure look, one empty state, one way to confirm. Today seventeen jobs are done 65 ways, and a manager who learns how the inbox filters work has learned nothing about the reservations.

3.3 Nothing is said twice

What a header, a title, a chip or the screen's context already says, the row under it leaves out. Under a day header "Fri, Oct 2" a booking says "until Oct 7". A list filtered to one listing drops the listing from its rows. A conversation's header carries the booking, so its messages do not. A detail page never repeats its title in its first card. Every picture was checked for this before it went in.

3.4 The usual state goes unsaid

When nearly every row of a list shares one state, the row says nothing about it, and only the exception carries its dot and word: "Unlisted", "PMS off", "Overdue". Mail leaves read mail unmarked for the same reason. A list where the states are spread (bookings, tasks, payments) keeps a status slot on every row, as a dot and a word in a fixed place, never as a pill whose width changes from row to row.

3.5 Recognition over recall

Every control shows its current state before it is tapped: a rule shows "Minimum stay · 2 nights", an assignee row shows who, a period button shows which period. Filters are chosen from the values the data has, not typed: a row of tiles for two to four values, a list with a box on every row for more, a search inside that list only from ten values. Free text is for free-text fields. It is clear before the first tap whether a choice takes one value or several.

3.6 Act where you decide

The act a user is most likely to want is in view where they decide on it. A booking's page shows the one act its state asks for (Accept, Check in, Check out) at the top with Message beside it. A row's menu carries the record's own acts with their state, so an inbox can be sorted without opening conversations, which would mark them read. A form that can be sent from anywhere on a page keeps its button at the bottom of the screen.

3.7 Reversible acts act at once; the irreversible ask once

Blocking nights, closing a conversation, checking a guest in and handing a task on happen on the tap and say what they did in a toast with Undo. Accepting a request, sending a message to a guest, deleting a photo and logging out ask first, and the question names what will happen ("The booking becomes Accepted") with two buttons that name their results ("Accept request", "Not now"). There is no "Are you sure?" and no list with a separate Cancel under it. A destructive act is red wherever it is a button or a row.

3.8 The app tells the truth

A count says what it counted over ("30 of 34 listings", "in the days loaded, Aug 15 to Nov 13"). A failure names its reason in quiet grey and offers one "Try again"; the sentence never says "try again" beside the button that does. A refresh that fails keeps the last good page on screen under one line that says so. A control that cannot act is not shown. A confirmation claims only what the act is known to do, and what is unknown is asked of Hostify rather than promised.

3.9 Borrowed patterns, Hostify's look

A list of records behaves like iOS Mail. A conversation behaves like the messaging apps everyone uses. A calendar behaves like the booking tools managers already know. These are patterns, not looks: the brand blue, the Lucide icons and the Hostify name stay, and no colour, font, artwork or screen of another product is copied.

3.10 An accessibility floor, not a feature

Every text colour clears 4.5:1 on every ground it sits on, every mark clears 3:1, every control is at least 44 points to the touch, every gesture has a visible path as well, and every string exists in every language the app ships. These are the floor the proposals were built on, not a later pass. Larger text sizes (Dynamic Type) are a phase of their own and are not in this document.

3.11 Platform conventions

A sheet covers the whole screen, tab bar included. Cancel is a word, never a cross in a corner. Back goes back. The tab bar stays on every screen, so any tab is one tap away from anywhere. The week starts on Monday, today sits on a dark disc, time follows the phone's 12 or 24 hour setting, and the number keypad opens for an amount.

4 The design system

The proposal's screens are drawn from one small set of values: a type scale, a grey ramp and one accent, a rule for depth, a scale of corner radii, named durations, a haptic vocabulary and a rule for figures. The values follow what Apple's and Google's guidelines and the best consumer apps agree on, and every one of them was checked against the accessibility floor. Hostify's brand stays: the blue, the name, the icons.

4.1 Type

One typeface, the platform's own (SF Pro on iOS, Roboto on Android), so the text looks native and loads instantly. Hierarchy is carried by size and weight alone, never by colour or decoration. Nothing is lighter than Regular. The largest sizes are tracked one percent tighter and lead closer, as every large figure in a banking app is.

4.2 Colour

The canvas is white. Structure is drawn with an ink and six greys, and every text grey clears 4.5:1 on white, on the tonal page and on the fill. The brand blue is reserved for the one filled button on a screen, the chosen tab, a chosen day on the calendar and a search match, so when it appears it means something. Status colours are the only other colour on a screen.

The brand blue is the current #167FFC darkened until white text on it reaches 5.4:1. Today's value gives 3.8:1, which fails the floor for every filled button and badge in the app.

A colour is never the only signal. The word stands beside the dot, the minus stays beside a red amount, and a chosen tile carries a check as well as its tint.

4.3 Depth and shape

There are no cast shadows. A card is set off from the page by a hairline on white, or by its tone on the tonal page. A sheet is a lighter surface over a dimmed page. The tab bar and the app bar are separated from the content by one hairline. Four corner radii cover every shape: 8 points for chips and tags, 12 for inputs, tiles and cards, 16 for the top of a sheet, and a full capsule for pills and the search field.

4.4 Spacing and targets

A four-point scale, with 16 points as the gutter on a phone. A button in a bar is 48 points tall; a choice tile is 64; a touch target is never under 44 points, whatever the drawn size. Groups of rows are separated by space and a header, never by a grey band or a border. A card is used only for a thing that is one object (a KPI tile, a guest's request), never to group rows.

4.5 Icons

Lucide, as the app uses today: one stroke weight on a screen (2 points at 24, 1.75 at 20 in dense rows), outlined by default, filled only to mean chosen or active. Every icon-only button has a label a screen reader can speak.

4.6 Figures

Every amount, count and time is set in tabular figures, so a column of amounts aligns and a figure that updates does not jitter. The sign and the currency sit inside the figure. An amount in text keeps its cents ("€7.50"); a headline figure over a period drops them ("€13,776"). A change carries its direction in an arrow and a colour, and a plain positive amount keeps the body colour, so green still points at something.

4.7 Dark mode

The grey ramp is tiered so a dark theme can be built from it (a base and an elevated surface, text at reduced white opacity, hairlines at low white opacity) without changing any screen. No dark screen is in this document. It is a proposal of its own, for a later phase.

5 Controls and interactions

The screens in this document are assembled from a dozen shared pieces. Each is described here once, with the rule it follows, so the area chapters can show the pictures and say only what is particular to each screen. Where the current app does the same job several ways, the piece replaces all of them.

5.1 The list row

A list is white, edge to edge, and its rows are told apart by a hairline inset to the text, the way iOS Mail draws them. The first line holds the name and, on the right, the time or the dates. The second line is the preview or the second fact. The third is the meta line: the status as a coloured dot and a word in a fixed slot, then the channel, the listing and the stay. Unread is a dot at the row's leading edge and a bold name, never a mark at the far end. The time reads as Mail gives it: the hour today, "Yesterday", the weekday within a week, then the date.

Every row opens its record with one tap. Its other acts are behind one menu button at the right edge, and the swipes stay as shortcuts. When some rows have the menu and others do not, the rows without it keep its slot empty, so amounts and times still end at one edge. A name takes at most two lines and ends in an ellipsis; the full name is on the record's own page.

5.2 Headers and the tab bar

A tab's title is large, on the left, in the ink. It scrolls away with the list and snaps back on the first pull down, with the search and the chips. A pushed page's bar carries a title, the kind of page ("Task") or the record's name once the large title has scrolled away, and Cancel is a word on the right of every form's title row. The tab bar stays on every screen, a count is a badge on the tab's icon, and the chosen tab is told by colour and weight.

5.3 Quick views, facets and filters

The everyday views of a list (Open, Unread, Snoozed; Upcoming, Arriving, Past; This month, Last month, Not invoiced) are one row of chips that scrolls sideways, with their counts, never wrapped onto a second line. The views of one axis are a single choice; a switch laid over them (Unread, Assigned to me) is a chip that toggles.

A facet over a list (properties, vendors, owners, cities) takes its form from how many values it has. Up to four: chips in the row, "All" and one each. Five or more: one chip that names the choice ("All properties", "Acropolis View", "3 properties") and opens a list with a box on every row, "Choose one or more", the count chosen and Clear. Ten or more: the same list with a search at its top. A field with few values is never a text search.

The rarer filters live in one sheet behind the filter button. Each is a step inside that sheet with a Back arrow, never a sheet opened over the sheet. The current choice is first and ticked. Reset and Apply stay fixed at the sheet's foot. A filtered list says so with a strip of the active filters, each with its own cross, and "Clear all". Clear empties one facet; Reset puts every filter of a sheet back.

5.4 Search

A capsule field with its icon inside, under the chips, that says what it searches: "Search conversations", "Search listings". Focusing it enters a search mode: the title and the chips step aside, Cancel appears, and the empty field offers recent searches. Results come live after a short pause from the third character, the match is marked in each row, the count is stated, and the keyboard goes down when the results are scrolled. A search looks across every state of the list and says so; it never runs silently inside the chosen view. An empty result offers "Clear search".

5.5 Sheets

Every sheet is the same sheet. It opens over the whole screen, tab bar included, with a handle, a title and a height fitted to its content, capped at 90 percent of the screen. A choice or an action sheet ends in a full-width Cancel of its own, as the phone's does. A form sheet with a footer names Cancel in words in its title row and keeps its footer in view while the content scrolls. A sheet that holds changes does not close on a swipe or a tap outside; it asks.

Whether a choice takes one value or several is visible before the first tap. One: the chosen row carries a check on the right, a tap answers and closes, and the caption says "Choose one". Several: every row carries a box on the left, a tap toggles and the sheet stays, and the caption says "Choose one or more", then how many are chosen, with Clear. From ten rows a choice list has a search.

5.6 Confirmations and Undo

A confirmation is two buttons that name their results, never a question and a Cancel row: "Delete payment" and "Keep it", "Accept request" and "Not now", "Discard" and "Keep editing". Its sentence names what will happen and claims nothing the act is not known to do. A destructive act is red. A reversible act skips the question: it happens on the tap and a toast says what it did with Undo ("Acropolis View · 3 nights blocked · Undo"). Undo restores each item's own earlier state.

5.7 Buttons and button groups

A group of buttons or of choices is one row that never wraps. Every button in it is the same width whatever its word, and a long word shrinks rather than widening its button. Each carries an icon, and colour only where the colour means something, such as how bad a damage is. Two shapes, one rule: a group inside the content is a row of 64-point tiles with the icon over the word (a step's acts, a form's choices); the acts of a bar at the foot of a screen or a sheet (Reset and Apply, Decline and Accept, a booking's act and Message) are 48-point buttons with the icon beside the word, so the bar takes no room from what it acts on. The act the group waits for is the one filled button. A lone button is a bar of one: filled when it is the page's one act ("Sign in", "Start", "Share PDF"), outlined when it answers a state ("Try again"). A text link is a centred sentence with no icon.

5.8 Forms

A form's one button stays at the bottom of the screen, above the keyboard, and names its result ("Save €18.40", "Send report", "Set €130 for 3 nights"). While something is missing, the line above it says exactly what ("Add a photo to send"), and the button stays visible rather than greyed with no reason. Errors appear under their fields, all at once. The first field takes the focus, and an amount field opens the number keypad with the currency code inside the box; the digits are padded to the cents when the field is left, so "7.5" becomes "7.50". Leaving a form with changes asks; leaving it unchanged simply closes. Typed text is never lost on back, on a tap outside or when a saved reply is chosen.

A record's own fields are read first and edited one at a time: a text in a sheet whose button names it ("Save Parking spot"), a list as a "Choose one" step whose tap saves. A set of values with one Save (tags, amenities, a fee) gets one bar that counts the changes ("Save 2 changes").

5.9 Dates, times and moments

Dates are words in one grammar: "Oct 1"; "Aug 1, 2027" when the year is another; "Thu, Oct 1" where the weekday matters; "Oct 1, 5:20 PM" for a moment; "Sep 29 – Oct 2 · 4 nights" for a stay. Never a numeric date. Wherever a day is chosen the same picker opens: the week starts on Monday, today sits on a dark disc, the chosen day is tinted with its number in the brand colour. A range is two taps on one calendar. A moment (a snooze, a reminder) is offered first as ready choices with when each lands ("Tue 9:00 AM"), and a custom moment is a step of the same sheet with a calendar and one row of hours. Never a sheet, then a date dialog, then a time dialog.

5.10 States

A first load shows the shapes of what it loads, never a spinner on an empty page. One failure look everywhere: an icon, what failed, the reason in quiet grey, and one outlined "Try again", with the header and the chips kept. A refresh that fails keeps what is on screen under one short line that gives the reason first ("No connection — showing the last list"), with Try again beside it. A section that cannot be read fails on its own row and the rest of the page works. An empty view offers the act that undoes its cause: Clear search, Clear filters, Show read ones too, Back to open conversations.

5.11 Feedback

A toast names the object and the act ("Checked in", "Price set for 3 nights"), sits above the lowest control so it never covers a button or the composer, and offers Undo where the act is reversible. A failure inside a form is said inside the form, never in a toast over it. A push that arrives while the app is open is a banner at the top.

5.12 A record's page

A record's page starts with when and what now: a sentence ("Arrives in 11 days", "Late · Yesterday · 10:00 AM to 1:00 PM"), the dates, the status as a dot and a word, the photo as a tile beside them, and the one act the state asks for with Message beside it. The rest is grouped rows in the order the reader needs them, each row stating its answer ("Photos · 6 photos", "Reporting · €13,776 this year"). A section's page says which section it is and whose record under it, and starts with its answer ("Check-in complete", "Not filled in yet"). Several people or items are one row each; the detail opens on its own page.

5.13 The calendar grid

A row starts with the listing's name, cut in the middle so a trailing number stays. A booking is a light band in its status colour with a strong edge at its start, the channel's letter and the guest's name, running from the middle of the arrival day to the middle of the departure day so a turnover day holds both stays. A night that cannot be sold shows no price. A chosen night is a light brand tint with a small check and its date lit in the header, never a border. The bar under the grid names the listing first, then how much is chosen and which dates, and carries the everyday writes as buttons. A tap on a booking opens a peek: when and what now, one money line, the turnover fact, Message and Open.

5.14 Conversations

A white page, the guest's bubbles a quiet grey and the team's a pale blue, a note yellow with its lock. No avatars in a conversation with one person; the side says who speaks. The time sits inside the bubble, runs are grouped, system events are a quiet centred line. The header carries the guest and, under the name, the listing, the stay and the status; a tap on it opens the conversation's details with every act and its state. The composer is one line at rest and opens up while writing: the mode, the channel, the field growing to six lines, the send button in its corner, and a way to the whole screen for a long reply.

6 Motion and haptics

The pictures in this document are still, so this chapter describes what moves, and what the phone does under the thumb, as a proposal. Two sources set the rules: Apple's guidance for motion and haptics, and Material 3's duration and spring tokens. The apps the audit used as a bar (Revolut, Monzo, Wise, Airbnb) follow the same rules, and what they do not do is as telling as what they do. Nothing moves for its own sake.

6.1 The rules

• Feedback is brief: a control answers a touch within 100 to 200 milliseconds. A container (a sheet, a page, a bar sliding in) takes 250 to 350 milliseconds with the standard easing.
• Only things that move may bounce. A sheet, an act bar or a chosen tile's check settles on a spring; a colour or an opacity never does.
• Every move has a fade behind it. When the phone's Reduce Motion is on, moves become fades and springs tighten to the standard easing.
• A haptic always has a visible cause, and uses the phone's own vocabulary with its documented meaning: a selection tick when a value changes, a light impact when something snaps into place, a success pattern only when a write completes, an error pattern only when a write is refused. Never a haptic for a tap that did nothing.
• A press state exists on everything tappable and is immediate: a tone shift for buttons and rows, a scale to 0.97 over 120 milliseconds for tiles and cards, back on a spring.

6.2 What happens on each event

6.3 What is not proposed

Count-up animations on amounts (a figure the reader came for should not be delayed), bounce on colour or opacity, animated empty-state illustrations, shadows that lift on press, and any motion the reader has to wait for. Shared-element transitions between a row and its page are left for a later pass: they polish a transition, and the audit's first job was to make the transitions the same everywhere.

7 Three looks to choose from

The design system of the previous chapters can be drawn in more than one way without changing a single rule. Three looks were built from the same tokens and pictured on the four screens a manager sees most: the inbox, a booking's page, the revenue overview and a listing's page. Every other picture in this document is drawn in the first look. We ask Hostify to choose one, or a mix; the chosen look is then applied to every screen.

7.1 A, quiet

The design system as written. A white page everywhere, groups of rows separated by space and a header, cards only for things that are one object (a KPI tile), a hairline where a card needs an edge. The brand blue appears on the one filled button and the chosen tab. This is the lead's recommendation: it keeps the Mail-row grammar on every list and changes the least between a list and a record's page.

7.2 B, tonal

The same, on a pale grey page, with white cards for a record's groups and for the KPI tiles, as the grouped lists of iOS Settings and the light mode of the banking apps group by tone. Lists stay white and edge to edge. It is the most recognisably "premium" of the three at a glance, and the most expensive to carry through: every record page, form and sheet needs its card anatomy decided, and a list under a grey page sits beside a white one under the same tab bar.

7.3 C, dark primary

The quiet look with the one filled button in the ink instead of the brand blue, as Revolut and Monzo draw their primary button; the blue then lives only on chosen states and links. It changes the least on screen and the most in meaning: the ink button reads as a neutral act, so the eye no longer finds the page's one act by colour, which the "one filled button" rule depends on. The lead does not recommend it.

7.4 The four screens

In each sheet the three looks stand side by side, A on the left, B in the middle, C on the right. On the inbox the three are identical by design: a list is white in every look and has no filled button, so the sheet shows the design system itself (the 34-point title, the capsule, the ink chips, the grey ramp). On the revenue overview A and C are identical, because the page has no filled button.

7.5 What we recommend

Look A, with B's white cards kept for the KPI tiles alone, because a tile is one object and reads well as a card on either page. Whatever is chosen, the type, the greys, the contrast floor, the depth rule and the motion stay the same.

8 Everywhere: one grammar

The rules in this document were made area by area, so an early area could not follow a rule that came later. A final audit held every picture against all the rules at once and made the following the same on every screen.

• Dates are written in words: "Oct 1"; "Aug 1, 2027" when the year is another one; "Thu, Oct 1" where the weekday matters; "Oct 1, 5:20 PM" for a moment; "Sep 29 – Oct 2" for a stay, with the nights after it. Today one page mixes "9/29/2026 5:20 PM" with "Sep 18".
• Wherever a day is chosen (a snooze, a payment's date, a filter's dates, "go to a date") the same picker opens: the week starts on Monday, today sits on a dark disc, the chosen day is lit. Today two of these pickers start the week on Sunday.
• An amount in text keeps its cents ("€7.50"). A headline figure over a period drops them ("€13,776"). An amount being typed shows its currency code inside the box and is padded when the field is left, so "7.5" becomes "7.50". A percentage reads "17.8%" and a change "↗ 0.6%".
• Every confirmation is two buttons that name their results: "Delete payment" or "Keep it", "Accept request" or "Not now". There is no list with a separate "Cancel" under it. A destructive act is red wherever it is a button or a row.
• A button that stands alone is 48 pt tall with its icon. It is filled when it is the page's one act ("Sign in", "Start", "Share PDF") and outlined when it answers a state ("Try again"). A text link is a centred sentence with no icon. Today a lone button comes in five heights.
• When a refresh fails, one quiet line gives the reason first and then what is still shown ("No connection — showing the last list"), with "Try again" beside it. No sentence says "try again" next to the button that does. The word is always "Try again", never "Retry".
• A search box says what it searches ("Search listings", "Search statements"). On every list it is a capsule under the chips; the chips and the filters stay the main way in.
• "Clear" empties one facet. "Reset" puts every filter of a sheet back. A pushed page's top bar always carries a title. Cancel is on the right of every form's title row.

The pictures of every area in this document were taken again after these changes.

9 The inbox

The inbox is the screen a manager spends the most time on. Today it is built like a settings page: controls take most of the screen and the conversation gets what is left over. The proposal gives the messages the room and moves the controls to the moments they are needed.

9.1 The list of conversations

• A large title on the left in the body colour. Today's small, grey, centred title looks disabled. The title, the search and the views scroll away with the list and come back on the first pull down.
• Rows laid out like iOS Mail: white, with thin separators. The unread dot sits at the start of the row. The first line holds only the name and the time, and the time reads as Mail does it: "12:12 PM" today, then "Yesterday", then the weekday, then the date.
• The booking status is a coloured dot and the word, always in the same place. The status word is in colour only where the manager has to act (Pending, Inquiry). Today's status pills are different widths, so the name and the time move from row to row.
• The unread count is a badge on the Inbox tab. "Inbox (19)" inside the label breaks in German.

9.2 The everyday views, one tap each

One row of chips that scrolls sideways: Open, Unread, Assigned to me, Snoozed, Closed, with the counts kept. Unread and Assigned to me are switches on top of the chosen view. Today, Unread takes four taps through the filter sheet, and "assigned to me" takes five.

9.3 Search

Search works the way it does in messaging apps. Tapping the field enters a search mode with Cancel. Results appear as you type, the matching text is highlighted and the number of results is shown. The search covers open, snoozed and closed conversations. Today it searches only the view that is selected and does not say so, so a closed conversation cannot be found. A search with no results offers "Clear search".

9.4 Filters

• The sheet covers the tab bar. Cancel is spelled out, and Reset and Apply always stay in view.
• Each choice opens as a step inside the same sheet with a Back arrow, with the current choice first and ticked. Today a second sheet opens on top of the first. The 19 channels come with a search.
• A filtered list says so: a strip of the active filters, each with its own ×, and "Clear all". Today the only sign is a small red dot.

9.5 The conversation

• About 65 % of the screen for the messages, up from about 45 %. The tab bar stays.
• The page is white. The guest's bubbles are light grey and the team's are light blue. There is no avatar beside every message (it is a conversation with one person). The time sits inside the bubble, and messages from the same person are grouped.
• The header shows the guest, and under the name the listing, the dates and the status. It no longer cuts off. Tapping it opens the conversation's details: the guest, the booking, the assignee, the tags and the actions, each showing its current value.
• A pinned note becomes a one-line pinned bar, as in messaging apps. Today the tags and the note take two bands and 143 pt above the messages.

9.6 Writing a reply

The reply box changes with what the manager is doing. While they read, it is one line, "Message Amélie", with a + beside it. Once they start writing it opens up: the mode (Reply or Internal note) and "via Airbnb ▾" appear above the field, the field grows from two lines to six, the send button sits in its corner, and ⤢ opens the field full screen for long replies such as check-in instructions.

A reply goes out on the booking's channel unless the manager picks another one. Sending by SMS or WhatsApp instead is rare, so that choice sits behind "via … ▾" rather than in a row of four chips that is always on screen.

An internal note is a separate mode. The field turns yellow and shows a lock and "Only your team sees it", so nobody mistakes a note for a message to the guest.

No AI buttons in the reply box. We propose removing the AI draft and "Improve this reply" from the mobile inbox: in a working chat with guests they get in the way more than they help. AI features are a separate proposal, which we will bring later. Note that the isAi permission then controls nothing in the mobile inbox.

9.7 Saved replies and photos

• Each saved reply shows its text, so the manager can see what will be sent. A chosen reply is added after what is already typed. Today it replaces the draft without warning.
• The + opens a tray of three large tiles: take a photo, choose a photo, saved replies.
• The photo viewer closes with "Done" or by dragging down, as in Photos.

9.8 A guest's change request

• In the conversation the request is a single line that says what is asked: "2 guests (was 1) · Sep 28 – Oct 2 · +€114.00", with Review. Today a table can take up to 45 % of the conversation.
• Review shows only what changes, one line each: the old value crossed out, the new one in bold, and "+1 night". The payout is a single line with the difference, and the other figures fold under "Price details". The decision comes after the facts: Decline, then Accept on the right.

9.9 Triage from the list, and snoozing

• Every row has a ⋮ with the conversation's actions and their current values: star, snooze, close, assign, tags. A manager can sort the inbox without opening a conversation, which would mark it as read. The swipes remain.
• Snooze lists the ready options with the exact time each one returns the conversation ("Tue 9:00 AM"). "Pick a date and time" is a step in the same sheet, with a calendar and one row of hours. Today it takes a sheet, then a date dialog, then a time dialog.

9.10 When something goes wrong

• A calm failure screen: an icon, what failed, why, and one "Try again". Today it is red text and a large blue button.
• When a refresh fails, the list stays on screen with one short line above it: "No connection — showing the last list".
• An empty view offers the action that undoes its cause: Clear search, Clear filters, Show read ones too, Back to open conversations. An inbox with nothing waiting says "All caught up".
• The first load shows the outline of the rows instead of a spinner on an empty page.

10 Reservations

The reservations list follows the inbox: the same row, the same chips and the same search. A booking list is scanned by date, so the dates take the place the time has in the inbox.

10.1 The list of reservations

• Rows laid out like iOS Mail, as in the inbox. The guest's name comes first. The stay sits on the right, where Mail puts the time. The listing goes on the second line. The third line has the status as a dot and a word, then the nights and the number of guests. The status pills go, so the name no longer moves from row to row.
• The status word is in colour only when the manager has to act (Pending, Inquiry, Pre-approved, Special offer). Accepted stays grey.
• The views (Upcoming, Hosting, Past, Arriving, Departing, All) are one row of chips that scrolls sideways, with their counts. Today they take two rows.
• Upcoming and Past are grouped by day, with headers like "Today", "Tomorrow" and "Fri, Oct 2". Under a header a booking only says when it ends ("until Oct 7"), because the header already gives the arrival. Nothing on a screen is said twice.

10.2 Search

The search covers every view. Today it searches only the selected view and does not say so. Searching "Konstantina" in Upcoming finds 3 bookings, while 5 exist. The proposed search finds all 5, highlights the matching text and states the count. Cancel returns to the view the manager was on. A search with no results offers "Clear search".

10.3 Filters

• The same sheet as the inbox's. It covers the tab bar, Cancel is spelled out, and Reset and Apply always stay in view. Today the 19 channels alone fill the sheet as chips, and Apply is pushed to the bottom.
• Each choice opens as a step inside the sheet with a Back arrow: the listings, the channels, the three dates, the review and the order. Today the date presets open an action sheet on top of the sheet, and "In the last" opens a third one.
• It is clear before the first tap whether a choice takes one value or several. Where several are allowed, every row has a checkbox, and the step says "Choose one or more", how many are chosen, and offers Clear. Where only one is allowed, the step says "Choose one" and closes on the tap. The inbox's filters follow the same rule.
• A filtered list shows each filter as a chip with its own ×, and "Clear all". Today the only signs are a red dot and a line of text. The rows leave out what the filter already says. Filtered to Vitosha Loft, a row no longer repeats "Vitosha Loft".

10.4 One reservation

• The top of the page answers "when" and "what now". It starts with a sentence ("Arrives in 11 days", "Arrives today"), then the dates, the nights, the guests and the status. The listing photo becomes a tile beside that sentence and opens the listing; today it is a banner that takes a quarter of the screen. The listing is named once, in the title, where today it also appears in the first card.
• One main action, chosen by the state of the booking, with Message beside it. On the arrival day it is Check in: one tap, then "Checked in" with Undo. Today Check in is the second item of the ⋮ menu and asks for confirmation first. A pending request gets "Accept request", which still asks, because the answer goes to the guest. The question says what happens ("The booking becomes Accepted") instead of today's "Are you sure that you want to approve the reservation?". We would like to say more, for example whether the guest is notified and whether the dates close to other bookings, once you confirm what accepting does.
• The rest is grouped rows in the order a manager reads them. The stay shows the address and the arrival and departure times (the dates are already at the top). Money shows one figure: what is still due, "Paid in full", or the payout. The breakdown is one tap away. Then the check-in form, custom fields, automations and the review, then the guest, the notes and the booking's details. Today the money is a row of cards that scrolls sideways and is cut off at the edge.
• A cancelled booking says "Nothing here can be changed" and shows no amount as due.
• Rare actions (move, cancel) stay in the ⋮ menu.

10.5 A reservation's money

• The page opens with the same figure as the reservation's page ("€394.00 due"), so the two can never disagree. "Record a payment" is a large button right under it. Today it is a small + beside the word "Transactions" at the bottom of the page.
• Payments are list rows: what it was, the amount on the right, and under it the status as a dot and a word and the date. The status is in colour only where someone has to act: a payment request the guest has not paid, or a card hold not yet captured. A tap shows the details, and ⋮ holds copy link, edit and delete. Today every payment is a card with a coloured label.
• The security deposit is one line, "€200.00 · Paid".
• The price breakdown is folded under "Show price details". Opened, it has headings for what the guest pays, what you and the owner receive, and the costs, with the sums in bold. Today three panels with up to 40 lines sit between the payout and the payments.
• Choosing what kind of payment to record comes first, with a visible Cancel: charge a card, request a payment, or record a payment made elsewhere.

10.6 Recording a payment

• The amount comes first and large. When a payment made elsewhere is recorded, it starts from what is still due, and a note under it says so. It stays empty when the channel collects the money, and for a card charge or a payment request, so a card is never charged a guessed amount.
• The type and the two dates are rows with their value on the right. Each opens as a step inside the same sheet, with "Choose one" and the current choice ticked. A date step offers "Today" (or "Not set") and a calendar, and a button that names the day confirms it ("Use Oct 2"). Today the type is a dropdown and each date opens a dialog over the form.
• Cancel is spelled out at the top, and the main button stays in view and names its result: "Record payment", or "Charge €394.00" where the amount is what leaves the guest's card.
• Errors show under their fields, all at once.

10.7 Guest check-in

• The page starts with the answer: "Check-in complete" and when, or "Not filled in yet" with "Copy the check-in link" as the one button. Today it is seven cards, and the answer is a small label in the first one.
• The confirmation code, the status and the stay's dates are gone from this page. They belong to the reservation, one Back away. What the guest wrote stays: the arrival and departure times they gave, the party they declared, and "The booking says 4 guests" when the two counts differ.
• Each guest is one row: the name, the document, how many scans. A tap opens that guest's document on its own page, with the scans large. Today every guest is a long card with every field and the scans open, so a party of six takes six screens of scrolling.
• The scans appear only on the guest's page, never in a list, because a list row is what the phone shows in its app switcher. They open full screen and cannot be saved or shared, as today.

10.8 Reviews

• The guest's rating is shown as a number and as stars ("5.0 ★★★★★"), then the date and the whole text. Today there are stars only.
• Reply says who will see it and until when: "Public · Reply by Oct 8", in amber in the last three days. When the window has closed, the page says so instead of the button silently disappearing.
• The reply, once written, sits under the review as "Your reply".
• The six categories are a list, each with the guest's comment under its own row.
• The guest's private feedback is its own grey block titled "Private feedback · not shown publicly", with a Message button that opens the conversation. Today it looks like the rest of the review.
• Rating the guest takes three short steps in one sheet: the three ratings and "Would you host this guest again?", then the public review, then an optional private note. Each step says who will read it. Today the public and private text boxes sit on one screen with the stars between them.

10.9 Custom fields

• The page is for reading first: each field's name with its value under it, and "Not set" for an empty one. Today the whole page is a form of input boxes, so a saved value looks the same as one being typed, and an empty field shows only its label.
• A tap changes that one field. A text field opens with "Save Parking spot" as its button. A list field opens as "Choose one", with the current choice ticked, and a tap saves it. The result is named: "Door code saved". Today changes wait for a Save button at the bottom of the page.

10.10 Automations

• Two groups, "Upcoming" (soonest first) and "Past" (latest first). Today everything is in one list, so a message due tomorrow sits between two that were sent last week.
• Each row says what it is, when, and its status as a dot and a word. Only a failure is in red, and it has "Try again" on the row. A line at the top says "1 automation failed". Today every status is a coloured label, so a failure is one red label among five colours.
• A tap opens the automation: the message as the guest will read it, a switch that shows whether it will run, and "Send now" (or "Send again"). Sending asks first and says who gets it. Today this is a ⋮ menu with a separate Preview.

11 Calendar

The calendar keeps its grid: a row per listing, a column per day. What changes is what the grid says at a glance and what a tap does with it. Rossen had already chosen, from earlier pictures, how a booking is drawn and how chosen days look.

11.1 The grid

• Each row starts with the listing's name, on up to two lines. Today it starts with an 80-point photo and the name is nowhere on screen, so finding a listing means knowing its photo or typing its name. When a name is too long, the middle is cut, not the end: "Athens Courtyard… 12" and "Athens Courtyard… 4" stay different.
• A booking is a light band in its status colour: green for accepted, amber for pending, violet for an inquiry, grey for an owner stay. The band has a strong edge where the stay starts, the channel's letter, and the guest's name (first name only when the full one does not fit). Today every booking is the same grey-blue with a globe.
• A night that is booked or blocked shows no price. Only a night that can still be sold does.
• The month and year stay pinned in the corner and change as you scroll.
• A day's own note has a note icon. The warning triangle now means only one thing: two bookings on one night.
• The info button explains every colour and mark. Today nothing does.
• Tapping a listing's name opens a short menu with "Open listing" and the clean/dirty switch, which shows the current state. Today the menu is titled with its only action.

11.2 Choosing nights, then price and block

• Chosen nights get a light tint, a small check, and their dates lit in the column header. Today each chosen cell gets a blue outline.
• The bar under the grid says what is chosen, starting with the listing: "Acropolis View", and under it the nights and dates ("3 nights", Tuesday 17 to Thursday 19). Today it says "Act on these days", and nothing on screen names the listing that is about to change.
• The bar has three buttons: Price, Block (or Open, when every chosen night is blocked), and More.
• The price form names the listing and the nights, opens with the price selected so typing replaces it, and shows the change as it will be: "€120 €130 a night". The button says what it will do: "Set €130 for 3 nights".
• Block and Open act at once and say what they did: "Acropolis View · 3 nights blocked · Undo". Undo puts back only the nights that changed. Today blocking takes a form with three options in the backend's words: nine taps across four sheets.

11.3 The rest of the rules

• More opens the rules for the chosen nights, titled with the listing. Every row shows what the nights hold now: "Minimum stay · 2 nights", "Arrivals · No arrivals", or "Varies" when the nights differ. Today the sheet is titled "Calendar" and no row shows any state.
• Rules have plain names with a one-line explanation: "Arrivals", with "Whether guests can check in on these days" under it, instead of "Closed to arrival".
• New booking and Owner stay stay at the bottom, below a line.

11.4 A booking on the grid

• Tapping a booking shows where the stay is in time first: "Arrives today", "Staying, leaves Thu 1", "Left Mon 28". The dates, nights, status, channel and guests follow.
• One money line, the one a manager acts on: "€120 due of €480" or "Paid in full". It follows the same visibility rules as the booking page.
• On a changeover day it says "Turnover · next guest arrives Thu 1", which is the first thing a cleaner asks.
• "Message" and "Open booking" are the two buttons. Today the conversation opens only by tapping the guest's name, which is blue and looks like a heading.

11.5 Double bookings and free listings

• Double-booked nights get a line above the grid: "22 overbooked nights", with the dates it counted over (the days the app has loaded), with Show, which scrolls to the first one and opens it. Today you find one only by scrolling past it.
• "Find a free listing" is a single sheet. It offers Tonight, This weekend and Next week with the dates each one means, and Other dates as a calendar inside the same sheet. The past cannot be chosen, and weeks start on Monday like the grid. Guests are set with minus and plus buttons. Today the search uses two separate date pop-ups that start on Sunday and accept past dates.
• The answer opens on its first night and says what it searched: how many of the 34 listings are free, for which nights and how many guests, with Clear. Today the grid lands six weeks back and says "Showing 30 of 30 listings" when the account has 34.
• When nothing is free, the answer says so and offers the two ways out: "Try other dates" and "Show every listing". Today it says "Nothing matches. Clear the search to see every listing", although nothing was typed.

11.6 One listing, month by month

• The listing's name is the title. Tapping it picks another listing. Today that choice sits behind a house icon.
• Days from the next or previous month are left empty. Today the last week of September is drawn again as the first week of October, so a booking or a selection shows up twice.
• Bookings, chosen nights, the bar under the grid, the rules and the booking preview work the same way as on the calendar of all listings.
• A day where guests cannot check in has a short mark on its left edge, and a day where they cannot check out has one on its right. Holding a day shows the reason in words.
• Today's date sits on a dark disc, like the phone's own calendar.

11.7 What the grid shows

• A "View" button opens a short sheet with two switches: prices and minimum stay. Turn prices off and the grid shows only who is staying, which is what a cleaner or an owner mostly needs. Airbnb, Hostaway and Lodgify all have a similar switch.
• The same sheet ends with "What the marks mean", which opens the legend. Today there is no legend at all.

11.8 When the calendar cannot be read

• If a refresh fails, the grid stays as it was and one quiet line under the header says so, with "Try again". Today a notice appears above the title and every day shows a "?".
• If the first load fails, the page shows one message with its reason and a "Try again" button. The title and the search stay in place.
• While the calendar loads for the first time, grey shapes of rows and bookings stand in for it, where today there is a spinner on an empty page.

11.9 Going to a date

• Tapping the month in the top-left corner opens a month to pick a day from, and the calendar opens on that day. Today the only way to reach a date months away is to scroll there.

12 Tasks

The tasks area is the app of the cleaning and maintenance staff. It is used on the move, often with one hand.

12.1 The list of tasks

• One list, in time order: Overdue first while it has tasks, then Today, Tomorrow and each day after, each with how many tasks are still open. Today these are three sections that open one at a time, so a worker with an overdue task sees either it or today's work, never both.
• Each task is one row: the property first (that is where the worker goes), the hours on the right, the job under it, then its status as a dot and a word. Only "Overdue" is red. In the Overdue group the row gives the day, because no header does.
• The property's photo stays as a small picture at the start of the row, because a worker recognises a house by it.

12.2 A task's page

• The page starts with the job and when it is due ("Late · Yesterday · 10:00 AM to 1:00 PM"), with the property's photo beside it. Today the page starts with a card about the property and puts the job in a second card.
• The property, the guests leaving and the guests arriving are one row each. So are the notes, each saying which stay it is about.
• The button at the bottom says how big the job is before it starts: "Start · 6 steps, 3 photos".

12.3 The checklist

• "1 of 6 done" sits above the checklist and at the bottom beside the clock, so the worker always knows how much is left.
• The next open step is already open, with its instructions and its reference photos. When a step is done, the next one opens and scrolls into view. Today the worker has to look for it: seven scrolls on a six-step task.
• Each step says what it still needs in words ("Needs a note"), and the button for that is the main one in the step. Today four small icons do this, and they squeeze the step's title onto three lines.
• A photo not sent yet says where it is and when it will go. Today it shows a blue "Not sent yet" label and an hourglass. A photo taken with no signal will be kept on the phone and say "Waiting for a connection · uploads when the phone is back online", with "Try now". Today it is lost. We decided this, and will build it in the next app release.
• Damage and Expense are at the bottom of the screen, reachable while scrolling. Today they are closed sections at the end of the page.

12.4 Finishing the task

• There is one way to finish a task: the button at the bottom. While steps are left it says how many ("5 steps to go") and takes the worker to the first open one. When none are left it becomes "Complete task". Today "Complete" is offered twice, once in the page and once after the last step.
• The clock and the count share one line above it: "0:00:04 · 1 of 6 done".

12.5 Comments and handing a task on

• Comments are always open, as a short thread with the newest last, each with who wrote it and when. The heading says who reads them: "seen by your team and the office". A posted comment appearing in the thread is the confirmation; today a message pops up over the field.
• A team lead hands a task on by choosing one person from the team. The person who has the task now is at the top, ticked and marked "Has this task now", and cannot be chosen again. The question before it names the person: "Give this task to Ana Assist? It moves to Ana Assist's list."

12.6 Reporting damage and adding an expense

• Both forms open from the bar at the bottom of the task, wherever the worker has scrolled.
• The damage report starts with the photos, because the worker is standing in front of the damage with the phone in hand. How bad it is comes next, as three tiles of equal width with a signal-bar icon in green, amber or red, then what kind (four tiles, one icon each), then the description.
• One button stays at the bottom of the screen and says what it does: "Send report", or "Save €12.50" for an expense. While something is missing, the line above it says exactly what: "Add a photo to send". Today the button is at the end of the form, and the line lists every part whatever has been filled in.
• Cancel is written out at the top left, and leaving a form that has been typed in still asks first.
• Every group of buttons in the task area (a step's Add photo, Add note and Done; Camera and Gallery; the choices of a form) is one row of tiles of the same width, an icon over each word. A group never breaks onto a second line and a longer word never makes its button wider. Colour is used only where it means something, as with how bad a damage is.

12.7 When the list cannot be renewed

• If a refresh fails, the list stays and one quiet line under the title says why, with "Try again". A first load that fails shows one message with its reason and a "Try again" button; while the list loads, grey shapes of the rows stand in for it.

13 Revenue and the owner's views

The manager looks at money a few times a week to answer one question: how is this month going, and is it better than the last one? The owner opens the app a few times a month to see what they earned, when it will be paid, and who is staying in their home next.

13.1 The overview

• The page opens on this month, compared with the period before. Today it opens on this year.
• The period is one row of four buttons of the same width: This month, Last month, This year and Other…. "Other…" lists the rarer periods and starts with "Choose dates…". Today the period is a sheet of 14 choices, taller than the screen, with nothing marked.
• One line under the period says what the figures are compared with, for which listings and in which currency: "vs Aug 2 – Aug 31 · All listings · EUR". Tapping it opens one sheet with the three choices. A comparison is named by what it compares with ("Previous period · Aug 2 – Aug 31", "Same period last year · September 2025"). Today four rows take the top third of the screen, and the currency is called "Default".
• Revenue leads, and Occupancy, Nightly rate and Nights sit in one row under it. Each shows the figure, how it moved and what it was ("was €45,408"). Today eight tiles of the same size show a percentage without the figure it was measured from.
• Owner revenue, reservations, the target and the money received are under "More figures", and the other eight charts are under "More charts". Nothing that is shown today has been removed.
• For a month, the chart has a single point today, because the app groups a whole month by month. We will change the app so that a month is grouped by day and gets a line. Until then, the page says that one month is a single point.

13.2 The list of statements

• Statements are listed by month, newest first, with the month as a header ("August 2026"). A manager and an owner both call a statement by its month.
• Each row has three lines: the property and the amount, then the owner and the number, then how far it is paid ("Partly paid · €1,430.25 due"). Today each statement is a card of six labelled lines, with "Show lines" folding open inside the card.
• The period uses the same four buttons as the overview. Status and payment are two rows of tiles, each tile with an icon and a colour that means something (paid in green, partly paid in amber, unpaid in red).
• A filtered list shows what it is filtered by, each filter with its ×, and "Clear all". It also says how many statements match.

13.3 One statement

• The page opens with the answer: the property and the month, the statement's total, how much is still due, and one button, "Share PDF". Today it opens with six labelled lines and the issuer's address.
• "How it adds up" lists the revenue, the management fee and the cleaning, then the owner's revenue as their result. The column adds up. The stays and the expenses it is made of are folded under their counts ("Expenses · 1 · €180.00"). Expenses are in date order.
• "Share PDF" hands the file to the phone's share sheet (mail, chat, Files, print). It replaces "Download", which today ends in "saving it to your device is not built yet". The file is named after what the reader knows it by: "Statement ST-2026-0042 · Acropolis View · August 2026.pdf". This needs one more library in the app, which is our decision, not yours.

13.4 Expenses

• Expenses are listed by day, newest first. Each row has the property and the amount, then the vendor and what it was for, then "Invoiced" and how it repeats. Today each expense is a card of four labelled lines.
• A filter is chosen, not typed. "This month", "Last month" and "Not invoiced" sit over the list and take one tap. The filter sheet has the period and "invoiced" as tiles and the vendors as a list with a box on each row. That list gets a search box only once it has ten vendors or more. The text search is a capsule under the quick views, for descriptions and names, never the list's main way in. Today the search box is the first thing on the screen.
• In any list, a name takes at most two lines.
• A filtered list shows what it is filtered by, and the rows no longer repeat it: with one vendor chosen, the rows leave out its name.
• The form follows the order the manager has the invoice in. The property comes first because it decides the owner and the currency, and the row shows both once chosen ("Vitosha Loft · Maria Ivanova · EUR"). Then come the amount in that currency, the vendor and the description. The date, the VAT and the repeat keep their defaults further down. Today the owner comes before the property, and the amount is last.
• One button stays at the bottom and names the sum ("Save €18.40"). While something is missing, the line above it says what: "Add a property, an amount, a vendor and a description to save". Today Save is under the fold and grey, with no reason given.
• Once the property is chosen, the amount field takes the cursor and the number keypad opens, since the amount is the next thing read off the invoice.

13.5 The owner's Home

• The owner's Home opens on this month, with the same four period buttons and the same figures as the manager's overview. Owner revenue leads; occupancy, nights and bookings sit under it, each with what it was. Today it opens on the year to date, with blue figures and "Unchanged" printed over two different numbers.
• Then come the stays: who is coming, to which property and when ("Arrives Fri, Oct 2 · 4 nights"). A stay under way reads "Staying now · until Oct 1". An owner's own block is called "Owner stay", with its code under it and no €0.00.
• Then the properties, each with its four figures always in the same place. A property opens that property's bookings. Today the cards cannot be tapped.
• The revenue chart is folded at the end.

13.6 The owner's bookings

• The owner's properties are chosen, not typed, and the way they are shown depends on how many there are. With up to four, each is a one-tap chip over the list ("All · Acropolis View · Ladadika Loft"). With five or more, one chip names the choice ("All properties ▾", "Acropolis View ▾", "3 properties ▾") and opens a list with a box on every row. From ten properties that list also has a search. Today the search box asks the owner to type a property's name.
• Bookings are grouped by the month they begin. Each row shows who is staying and what it brings, then the property and the channel, then the status and the dates ("Confirmed · Oct 10 – Oct 14 · 4 nights"). An owner's own block reads "Owner stay". With one property chosen, the rows leave its name out.
• The filter is one sheet with the statuses, channels and properties, each a list with a box on every row. The text search is a capsule under the period and the properties, for a guest's name or a code.
• "Upcoming" and "Past", with the soonest stay first, need a date filter on the bookings list (below). Until then the Home's stays answer "who is coming next".

13.7 The owner's statements and expenses

• Both lists find things by choosing, not by typing. The period uses the same four buttons as the rest of the money area. Tapping the lit one again shows every period, and "Other…" also offers "Every period". The properties are one-tap chips. Finding last month's statement takes one tap; today it takes about ten (Filter, Period, Custom range, two days, Apply). The properties work the same way as on the bookings.
• Statements are grouped by the month they cover, expenses by day. With one property chosen, the rows leave its name out and lead with the vendor.
• The expenses say their total next to the count ("10 expenses · €2,614.00") when every row is loaded. A credit note is green beside its minus.
• The newest-first or oldest-first order is one button beside the search capsule.

13.8 When the figures cannot be read

• While the figures load, grey shapes of the tiles stand in for them. Today a spinner turns in the middle of an empty page.
• If a new period cannot be read, the figures already on screen stay, and one line above them says they are from before the change, with "Try again". Otherwise the lit period would be lying about them.
• If a section of the owner's Home cannot be read, that section shows one message and "Try again", and the rest of the page still works.
• A month that is not over says so on its lead figure: "Revenue · so far". A period with no stays shows €0 with a line saying the figures are zero, not missing.

14 Listings

A manager opens a listing to check it or to change one thing: a photo, the Wi-Fi, a fee. Most weeks they do not open it at all. So the list has to find one listing among hundreds quickly, and the page has to say what the listing holds before anyone taps into a section.

14.1 The list of listings

• Each listing is one row: a small photo, the name on at most two lines, the channels at the right, and the city under the name. A listing that is not the usual case says so first: "● Unlisted · Thessaloniki". A listed one says nothing extra, as Mail leaves a read message unmarked. Today a row carries every tag, so one row can be three times as tall as the next.
• The list is narrowed by choosing, not typing. One row of chips over the list holds the status (All · Listed · Unlisted), the city and the tag. The city has eight values here, so it is one chip that names the choice ("All cities ▾", "Athens ▾") and opens a list. That list says "Choose one", because the list takes one city at a time. Today all of this sits in a sheet of seven menus behind the filter button.
• The rarer filters (PMS Services, channel, country) and the order are under the filter button, each a step of one sheet with its current value marked first. Whatever they narrow shows as a chip with its × over the list, with "Clear all".
• The search looks for a name or a nickname as you type, from three letters. It looks past the status chip and says so ("3 listings match, every status"). The matching letters are marked, and a match in the listing's other name is shown under the row's name. Today the search waits for the Search key and also matches cities and tags, which the chips now cover.
• The list says how many listings it holds ("34 listings", "500 listings") and still loads 30 at a time.

14.2 One listing

• The page opens with what the listing is: its title, its address, its status and whether it is clean, its owner, and its photo as a tile beside them. Under that is one button, "Open calendar". Today a photo 220 points tall comes first, and the title card is pulled over it.
• Each section is a row that states its answer: "Reservations · 6 to come · next Mon, Oct 5", "Reporting · €13,776 this year · ↗ 21.2 % on last year", "Photos · 6 photos", "Amenities · 17 chosen", "Fees and taxes · 7 fees, 2 taxes". Today each section is a strip of cards that scrolls sideways, and a strip shows only what fits on the screen.
• The rows are in two groups: what is only read here (Reservations, Reporting) and what is changed here (the listing's own sections). Reservations is now reachable on a phone.
• A section this account cannot open is a row without an arrow, and a section that could not be read fails on its own row (section 7).

14.3 Changing the listing's details

• The three tabs (General, Descriptions, Layout) become one page read top to bottom: what guests read, what only the team sees, the place, and where it is. Each row shows its value, or "Not set".
• There are two ways to change something, and they never mix on one screen. A single value opens its own sheet, and the button names what it saves ("Save internal name"). The title and the summary are one sheet, because the guest reads them as one text; its button names what changed ("Save title", "Save title and summary"). A set of values (the tags, the amenities, a fee) gets one bar that counts the changes ("Save 2 changes").
• Nothing is saved until the manager taps Save. Leaving with changes asks, and the two buttons say what they do: "Keep editing" or "Discard". Leaving with no changes asks nothing.
• The language the texts are written in is the page's first row.
• Rooms and beds keep today's editor in this pass. The proposal for them is the same as for a fee: one room is a set of values with one Save.

14.4 Photos

• The first photo says "Cover", and the line over the grid says it too: "6 photos · the first is the cover".
• Each photo's ⋮ holds its actions: Make cover, Move earlier, Move later, the caption, and Delete. The order can be changed without dragging.
• "Reorder" is a mode of its own: a list with handles, each moved photo saying where it was ("was 2"), and one button, "Save order · 4 moved". Today every drop is written at once, with no way back.
• An upload says how far it has got: "Uploading 1 of 2", with a bar.
• "Select" still chooses several photos to delete at once, and the button says how many ("Delete 2").
• Deleting asks, and the two buttons say "Keep photo" and "Delete photo". The question says only that the photo is gone for good. What happens to it on the channels is a question for you (below).

14.5 Amenities

• The page opens on what the listing has: "Chosen · 17", in groups. "All" is where amenities are added: every group with how many of it are chosen ("9 of 10"), and a search. Today the page opens on the full list of every amenity, with an "Active" switch to hide the rest.
• Every row has a box and, as today, the channels the amenity is sent to. There is no "Check all": ticking a whole group in one tap is how a listing ends up claiming a sauna it does not have.
• An unticked amenity stays in view, unticked, until it is saved, and the bar counts the changes ("Save 1 change").
• The Wi-Fi is a single value with its own sheet, "Save Wi-Fi".

14.6 Fees and taxes

• The fees are grouped by type (nightly rate, fees, extras, taxes, costs). Each row says what the fee is and how it is charged in words ("Cleaning fee · per stay · Online · to Management company"), with the amount at the right edge. A cost is money the listing pays, so it is red beside its minus.
• Each type keeps today's template choice as a row that says its state ("Template · Off"). Choosing a template asks first, because it deletes this listing's lines of that type. A type a template governs says so, and its lines are changed on the template. The search over the fees stays.
• A new fee starts with what it is for (Cleaning fee, Linen fee, Late check-out, as the backend names them), as tiles. The choice sets how it is charged, which the manager can change with one tap on the kind's own options ("Per stay · Per night"). A percentage says what it is a percentage of, and only then.
• Who collects the fee, who it goes to and its VAT are copied from this listing's other lines of the same type when they all agree ("Management company · as your other fees"). The VAT is filled in when the country has only one rate. When nothing can be copied, the row stays open and says "Choose one"; the app never guesses a value. The channels, taxable, stay length and cap are folded under "More options" while they hold nothing.
• A line of today opens the same page with its values, and "Remove" at its foot asks first, as the ⋮ does today.
• The button names the result: "Add cleaning fee · €60 per stay". While something is missing, the line above it says what ("Still to choose: how it is collected").

14.7 When something cannot be read or saved

• A list that cannot be read keeps its title, its search and its chips, and shows one message with "Try again".
• On the listing's page, each section that could not be read says so on its own row with its own "Try again". The rest of the page works.
• A save that fails says why inside its sheet and keeps what was typed until it is saved or discarded.
• We do not show "changed on another device". The app cannot detect it without versioned writes, which is a question for you (below).

15 Updates and links

Today an update can be announced in four places at once, and none of them can be tapped. When an update is required, the wall has no button, so the user has to search the store by hand. The legal and help links answer "Links cannot be opened in this build".

• An optional update has one signal: a card at the top of More that names the version, with "Update" and "Not now". The More tab carries a dot. The banner over every tab goes. "Not now" hides the card until a newer version comes out.
• A required update is a wall with a title that says what happens ("Update Hostify to go on"), the two versions, and one button, "Update in the App Store" (or Google Play), which opens Hostify's page in the store.
• About shows the version, with "Update to 9.9.9" beside it when there is one. "Check for updates" goes: on a phone the store updates the app, and the app already hears of a new version.
• Privacy, terms and help open in the browser inside the app, with Done to come back, and each row says so. A row that cannot act is not shown. In the pictures the button says where it would open: opening the store and the browser needs one more library in the app, which is our decision, not yours.

16 Signing in

• The form starts at the top of the screen, so the keyboard never covers it. Hostify's name comes first (your logo goes there), then "Sign in to Hostify" and one line saying which account to use. Today the form floats in the middle under a plain "Sign in".
• The password has an eye to show what was typed. It is hidden by default.
• An error sits under the field it is about: a malformed address under the e-mail, a refused sign-in under the password. The refusal does not say which of the two was wrong.
• "Forgot password?" sits right under the password. "I have a support code" is a quiet link at the foot, since only staff use it.
• The code screen says "Code expires in 9:55", in minutes and seconds. Today it counts "598 seconds". The field is marked as a one-time code, so the phone can offer the code from the message it arrived in.
• The maintenance wall says what is happening, shows your message, and has one "Try again" button. It does not promise a time, because the app is not told one (below).
• The question about notifications should come when it matters, not straight after sign-in. For a manager that is the first time the Inbox opens: a card saying "Get told when a guest writes" and one button that brings up the phone's own question. The phone's question cannot be pictured, so this one is described, not shown.

17 Two decisions about the whole app

These two change where people land and what the tab bar holds. Both were pictured as concepts and decided on 2026-10-01; nothing else in this document depends on them.

17.1 Which tabs a manager gets

The concept put Listings in the fourth tab and moved Revenue and Expenses under "Money" in More. We keep today's bar: a manager checks money a few times a week and opens a listing's settings far less often, and the tab bar follows what people use most. If you have usage data that says otherwise, the change is small. For workers and owners "More" becomes "Account", since for them it holds only the account.

17.2 A "Today" page for managers

The concept answers "what needs me today" on one page: who arrives and who leaves today, each opening the booking, and how many conversations are open. Cleanings not done and double bookings are not on it yet: the first needs a question the app does not ask today, the second needs a list from you (below). We will build it as a page opened from the top of the Inbox, and decide whether it becomes the first tab after managers have used it.

18 What this needs from Hostify

For the inbox, nothing on the backend. Everything above runs on the current API. Two things would make it better:

• Search inside messages (not only guests and listings), to show results as "Conversations" and "Messages".
• A count for a filtered list, so the filter sheet's button can say "Show 12 conversations" instead of "Apply".
• Who wrote last. If the list could say whether the guest or the team wrote the last message, or filter for "waiting for a reply", the inbox could offer an "Unanswered" view. Until then Unread stands in for it.
• Conversations with no assignee. The list cannot filter for them today, so there is no "Unassigned" row in the filter sheet.
• WhatsApp template placeholders. Are placeholders such as the guest's first name filled in when a template is sent? The app shows the template as the server returns it.

For reservations:

• What accepting a request does: whether the guest is told and the dates close to other bookings, so the question before it can say so.
• "Staying during" as a date filter (a stay that overlaps the chosen days), which the list endpoint cannot ask for today.
• Whether "paid" already counts refunds, so "to refund" is right after money has been given back.
• Whether every guest has to fill in the check-in form, so the check-in page can list the guests who have not done it yet.
• Why an automation failed, so the failed row can say it in plain words.
• Which "due" a manager means. Today's app computes it as the payout minus what was paid. The payout is what you receive after commission, not what the guest owes. We would like to know whether the balance the guest still owes (the total minus what was paid) is the figure to show and to prefill when a payment is taken.
• A check-in mark before the arrival day. The app offers "Check in" from the arrival day on. Is a mark before that day valid, and should it be offered at all?
• The arrival time and the check-in form in the list. The Arriving view could show each guest's planned arrival time and whether the check-in form is done, if the list answer carried them. Today they are on the booking's own page only.

For the calendar:

• A search for free listings across the whole account. Today the app can only ask about the listings it has loaded (50 at a time), so the answer has to say "among the loaded ones". This is the open question MC31 in our earlier list, repeated here only to show what it unlocks.
• A list of double bookings across the account, so the notice above the grid can count every one, not only those in the loaded days.
• Price and minimum stay for chosen weekdays ("only Fridays and Saturdays" within a range), which the write takes as one range today.
• Listing filters by tag and by owner as separate fields. Today the listing search takes one text that matches the name, city and tags together, so a filter sheet with City, Tags and Owner as separate choices cannot be built on it.
• Whether the calendar sends cancelled bookings. If it does, the app should leave them off the grid, or draw them so they clearly do not hold the nights.

For tasks:

• A pause for the task clock. A worker who stops for lunch cannot pause the timer today.
• An estimated duration per task, so the start button can say how long the job usually takes.
• Whether a reassign sends a push. If handing a task to a colleague notifies them, an Undo would leave a stray notification, so the reassign keeps its question. If it does not, the question can go and Undo takes its place.

For revenue and the owner's views:

• What a month still in progress is compared with. Today the previous period is the same number of days just before it (Aug 2 – Aug 31 for September). We would compare the same days of the month before (Aug 1 – Aug 30) and say so on the page. Which one does the reporting endpoint compute?
• Whether the figures count a stay by the nights it covers or by its check-in date, so the page can say it once.
• What a statement's amount is. The statement sends its amount, and sends the same figure again as net_amount, total_revenue and owner_amount. In our example, that figure is the revenue before the management fee (€2,860.50), while the owner's revenue is €2,378.40. Which figure is the one the owner is paid?
• Opening, correcting and deleting one expense. The list can show expenses and add them, but there is no way to read, change or delete one. A wrong expense cannot be fixed from the phone.
• Filtering expenses by property and by owner, with counts. Today the list can filter only by date, invoiced and vendor. A property or an owner can only be found by typing its name. With counts per value, the filter could say "Vitosha Loft · 12".
• Filtering the manager's statements by property and by owner. Today the statements can only be found by typing an owner's or a property's name into the search.
• An address for each property in the expense form's menu. Three properties called "Acropolis View" with the same owner can only be told apart by their listing number.
• A receipt on an expense, if the backend can store a file.
• Stays that have ended in the owner's "upcoming stays". The answer includes stays whose last night is already past, and counts them as ahead. The page now labels such a stay "Left" with its date, but the list should not send it at all.
• A date filter on the owner's bookings, so the list can show "Upcoming" with the soonest first and "Past" with the latest first.
• When the owner is paid next. If the backend knows the date of the next payout, the Home can show it first.

For listings:

• The next arrival in the list. A listing's row could say when its next guest arrives ("Fri", "Oct 14") if the list answer carried it. Today it does not, and working it out from other pages would be a guess.
• A filter by owner, and several cities or tags at once. The list takes one city and one tag, and no owner at all. A manager who thinks in owners cannot narrow by one. Does the list accept an owner, and a set of cities or tags in one question?
• The photo limits. How many photos a listing may have, how large one may be, and which formats are taken. The page states none until we know.
• What deleting a photo does on the channels. Is it removed from Airbnb and Booking.com too, or only from Hostify? The question before a delete says only what we know today.
• Versioned writes. If a listing's answer carried a version (or the time it last changed) and a save could send it back, the app could say "changed on another device" instead of overwriting a colleague's work without a word.
• A safe default for a new fee. For now, a new fee copies who collects it, who it goes to and its VAT from the listing's other fees of the same type, and fills the VAT when there is only one rate. Otherwise the manager chooses. Is there a default you consider safe for every account, such as the company's usual setting?
• Natural sorting of names. "Rooms 4" should come before "Rooms 12". The app keeps the server's order and says so; a natural sort on the server would fix every list at once.

For updates and signing in:

• The app's store addresses. The "Update" button opens Hostify's page in the App Store and in Google Play. We need the two addresses (the app's ids in each store).
• When maintenance ends. If the maintenance answer could carry the time the service is expected back, the wall could say it instead of "Try again".
• The code e-mail. An iPhone offers a code from an e-mail for one-tap entry only when it recognises it. We will check this on a real phone; if it does not work, the e-mail's wording may need a small change on your side.

For settings:

• "Do not translate" after a language is chosen. Does the account's translation setting accept "none" once a language has been picked? If it does, the settings can offer that row.

19 What we ask of Hostify

Three things, in this order.

• Choose a look from the chapter "Three looks to choose from", or say which parts of each you prefer. The chosen look is applied to every screen before the build starts.
• Answer the questions in "What this needs from Hostify" where you can. None of them blocks the build: each says what the app does until the answer comes. An early answer saves a second pass on that screen.
• Tell us where you disagree with a change. Every change in this document is one before/after pair, so a comment can name the picture. Where a change rests on a rule from the chapter on design principles, the rule is what to argue with, because it holds on every screen.

19.1 How the build is ordered

The proposals are built foundations first, because the later screens stand on them: the sheet, navigation, choosing, then the inbox, the accessibility floor and the languages, then forms, feedback, search and filters, dates, confirmations, row actions and states, and only then the area screens in the order of what a user gains per day of work. The full list with its effort estimates is in the appendix.

Two decisions about the whole app were taken while the audit ran and are described in the area chapters: the manager's tab bar stays as it is, with "More" renamed "Account" for workers and owners, and a "Today" page for managers is built as a page opened from the top of the Inbox, with the landing tab decided once managers have used it.

Three things are not in this document and have their own proposals: larger text sizes (Dynamic Type), a dark theme, and AI in the composer, which the proposal removes from the mobile inbox.

20 Appendix: the proposals in build order

The 29 proposals, in the order they are best built. Effort is for one developer at this project's review and test standard: S up to two days, M three to five days, L one to two weeks, XL more. "Needs Hostify" marks what the backend has to answer before the full proposal can be built; what can be built without it is always built first.

20.1 The workflows counted

Across all 27 workflows, 253 taps become 177.