I was running more than ten properties through Hostaway and spending hours a week on things that had no business being manual.
Listing rewrites. Any time I needed to update a description, make it more SEO-friendly, sharpen the appeal for a new target guest, tweak the opening line after a slow conversion month, I was starting from scratch in a text editor. Copy the existing copy, open a doc, rewrite it, paste it back. Multiply by however many listings needed the update.
Guest reviews. Hostaway keeps detailed records on every stay: what the guest booked, how long they were there, whether they followed house rules. Writing a personalised review from that data should take thirty seconds. I was spending five minutes per checkout, and when you're moving ten or more guests through per week, that adds up fast.
Then there was the daily ops context problem. Quick questions that should have instant answers -- what's the occupancy rate across all properties this month, which booking has the earliest check-in tomorrow, what are the cleaning notes on that property -- required navigating a PMS that wasn't designed for fast retrieval. I didn't want a different PMS. I wanted to talk to the one I had.
Those three problems were the product. I just didn't know it yet.
The fix came before the product
I'm not someone who sits down and decides to build a SaaS. The pattern is: I hit a problem hard enough, I build a solution for myself, and somewhere in that process I realise the solution has a shape that others might pay for.
Here, the fix was connecting Claude to my Hostaway data. I wired Claude into the account directly so I could query it conversationally. "What's the occupancy this week?" "Draft a review for the guest who checked out this morning." "What do I need to update before the school holidays?"
It worked. Immediately and obviously. The friction that had been bleeding time out of my daily ops dropped to almost nothing.
That's when the question shifted from "does this work for me" to "how many Hostaway users are doing this manually right now?"
The answer, based on a few conversations in STR operator forums, was: almost all of them.
90 days
I set a loose constraint: first paying customer in ninety days or I park it.
The wedge was the two problems with the clearest before-and-after: listing rewrites and guest review automation. Both had obvious inputs and outputs, both had a direct line to time saved, and hosts were already doing them manually every week without a good alternative.
I did not build a clean product in ninety days. I built a version that did the thing. Listing rewrites were slow. The review automation was fragile at the edges. The onboarding was me sending an email and a Loom recording.
The first customer paid anyway. Because the output was better than what they were doing manually, and they were doing it manually every single week.
That first payment is a specific kind of signal. It's not enthusiasm -- it's someone deciding this is worth money compared to the alternative. Those are different things, and the second one is what matters at day ninety.
The thing I over-built
Somewhere between the working prototype and the first paying customer, I built a full multi-property dashboard.
Nobody asked for it. I built it because I could see what the product was going to be, and I wanted the shell ready. I had a clear mental model of RentalStack as a platform: a place where an operator with ten or more properties would come to understand their portfolio at a glance, then act on it. The dashboard existed clearly in my head, so I built it.
It sat unused for two months. The users I had weren't managing ten properties. They were managing three. They didn't need the dashboard. They needed the automations to be faster and more reliable.
I don't regret building it, though. The work forced me to understand the underlying data model in depth: how properties relate to bookings in Hostaway, how availability is structured, where the edge cases live. When it came time to extend the product properly, I wasn't discovering that structure for the first time.
The mistake wasn't building it. The mistake was counting it as progress when it wasn't.
What the product is now
Three things.
Listing rewrites. Feed in your current listing, select what you're optimising for, and get back a rewrite that's ready to publish. Not a suggestion. Not a rough first pass. A version you can push directly.
Auto guest reviews. Hostaway knows everything about a stay. RentalStack turns that data into a personalised review after every checkout, without copy-pasting or starting from scratch.
Hostaway data connected to AI. The workflow I built for myself, being able to query and act on Hostaway data without navigating through screens, is where the product is heading. The operator who has to click through three menus to answer a question they need answered twenty times a day is the customer this is built for.
What's being built next
The biggest friction point left in STR operations isn't managing a property once it's live. It's onboarding a new one.
Right now, a host adding a property to any PMS goes through a mostly manual process: fill in fields, write descriptions from scratch, upload photos without context, hope the listing lands. The AI tools that exist mostly help you edit after the fact. Nobody has made the onboarding itself fast.
That's what I'm building into RentalStack next. A full property onboarding workflow where the host drops in photos, works through a structured checklist, and the AI analyzes the images, pulls in the relevant context, and writes the listing from that -- not from a blank prompt. The output isn't a draft to refine. It's a listing ready to go live.
There's more attached to it. When a property gets its first booking, the owner gets an email. When there are gaps in the onboarding checklist, the system emails them and asks for what's missing. It's less of a form and more of a light CRM layer around the onboarding process itself -- tracking what's been provided, what's still needed, what's happened since the property went live.
That gap exists in every PMS I've looked at. The tools are good at managing properties once they're in. The process of getting them in is still mostly a host copying and pasting into text fields at 11pm.
The pattern that keeps repeating
I've shipped enough products now to recognise the shape of the ones worth continuing.
RentalStack has it: I needed it, I built it, it worked, others needed it, they paid. That's the whole story. The products that don't make it usually fail at the second or third step. Either the build never produces something that works well for the builder, in which case you're shipping hope rather than product, or it works for you but you're too unusual a user for the problem to generalise.
The direct Hostaway connection I built for myself is an edge case. Most STR operators aren't going to wire Claude into their PMS account. But the problem it solved, slow and manual interaction with data they already own, is completely general. The product doesn't sell the technical implementation. It sells the outcome: less time on operational copy and more accurate information when you need it.
That's the translation work. From what I built for myself to what someone else would pay for. The first version is always about the builder. The product is about the customer.
What I'd do differently
Start charging earlier.
Pricing is a forcing function. It changes what people say. Free users give you enthusiasm. Paying users give you requirements.
The dashboard I over-built would have stayed in the backlog if I'd been talking to paying customers from week four instead of week ten. They would have told me what they actually needed, and it wasn't a portfolio view.
Everything else, the over-build, the fragile first version, the Loom onboarding, was fine. You have to build something, and the first build is always rougher than you want it to be. Rough and working beats clean and hypothetical every time.
The first ninety days of RentalStack looked nothing like a startup. They looked like an operator fixing a problem, then checking whether other operators had the same problem, then charging them to use the fix.
That's still the whole thing.