Product lessons

Property software needs a journey, not just a listing page

What building HomeHub reveals about vertical SaaS: the valuable work often starts after someone clicks on a property.

By Amrish Seunarain22 September 20264 min read

Updated 17 October 2026

Editorial illustration of a model apartment building, keys, a document folder and a laptop on a property-planning desk. — AI-generated editorial illustration. Not a photograph of a customer, operating site or live product interface.

The interesting work starts after the enquiry

A property listing has an obvious job: help someone decide whether a place might suit them. Photographs, location and price matter. But the listing does not explain what happens when somebody asks to view, submits an application, needs a document corrected or reports a problem after moving in.

That gap is where vertical software becomes useful. Instead of serving every kind of business equally, it understands the recurring decisions and handovers of a particular field. In property, the product needs to follow more than a lead. It needs to follow a relationship between a place, a person, an agreement and ongoing work.

HomeHub is a working demonstration of that broader product idea. It is useful as a design and workflow example; it is not presented here as a live property operation or proof of completed transactions.

Follow one record through its lifecycle

Consider an illustrative rental journey. A person finds a property, asks a question and arranges a viewing. They may then submit an application, supply requested information and wait for a decision. Each step changes what the next participant needs to know.

If those steps live in unrelated messages, the same details get requested repeatedly. A shared property record can preserve the relevant context while linking separate records for applications, documents and work items. That is different from putting every fact into one long note that nobody can navigate.

The lifecycle continues after the initial decision. An accepted application does not make a maintenance request disappear, and a maintenance issue should not require a person to resubmit their application history. Structure the relationships so that a new task can reference the right property and agreement without duplicating everything.

A shared record does not mean a shared permission

Applicants, owners, managers and service providers do not need identical access. A contractor responding to a repair needs the location, approved scope and access arrangements. That does not mean they should see another person's application documents or private financial details.

Design those views before collecting more information. Decide who can upload, view, correct and delete a document, and what happens when their involvement ends. A convenient link is not a permission model. The application must check access at the point where a record or file is requested.

Make the state of a record clear as well. A draft offer, an approved decision and an executed agreement are not interchangeable. The interface should not imply that a legal or external transaction has happened simply because somebody filled in a form.

Make the awkward handovers visible

The software becomes valuable when ordinary exceptions have a place to go. An application may be missing a document. A viewing may need to be rescheduled. A reported repair may require clarification before a quote can be prepared. Give each situation a next action, a responsible person and a record of the communication.

For an illustrative maintenance request, capture the reported issue separately from the assessment and proposed work. The resident's description is useful evidence of the experience, not automatically a technical diagnosis. Let a responsible person approve the scope before treating a contractor's proposal as an instruction.

This is less glamorous than adding another discovery filter, but it helps prevent work from falling between roles. A useful status answers 'what is waiting for whom?' rather than merely reporting that something is 'active'.

Earn a broader product one workflow at a time

HomeHub's demonstrable surfaces cover discovery, draft journeys and management concepts. Production identity, payments, screening, delivered messaging and other external services are separate integration work. A credible product explanation should make that distinction once, clearly, rather than hiding it behind ambitious language.

For a founder, the next useful experiment is narrow. Choose a workflow such as enquiry-to-viewing, define its start and finish and test it with approved participants. Observe where they leave the application, repeat information or become unsure about the next step. Those moments are better product guidance than a longer feature list.

Check whether another person can take over the work using the record alone. Can they see what happened, what is outstanding and what they are allowed to do? If not, improve the handover before connecting another provider.

The lesson applies beyond property. A vertical product earns its place by understanding the messy middle of an industry. Start with that understanding, support it with careful records and permissions, and let the wider platform grow from workflows that people can actually use.