From Directing Engineers to Building Alongside Them

1. You’ve built and sold companies in group buying, coupons, and travel deals long before short-term rentals. You’ve said the failures taught you more than the wins. What’s one specific lesson from a company that didn’t work – Zweet, Travelalerts, U-Swap – that directly shaped how you designed Sentinel?

Zweet hit number one on the App Store with hundreds of thousands of downloads. Users loved it. It still failed, because the people who loved it were not the people paying for it. Sponsors had different goals and we never designed for them.

That shaped Sentinel directly. The daily user is a revenue manager who wants fewer things to look at. The buyer is the person who owns the P&L and wants proof the decisions worked. If you only build for the first, you get a product people enjoy and nobody renews. So the decision record and the revenue evidence are not a reporting afterthought in Sentinel, they are the product.

2. Sentinel came out of seven years running revenue for thousands of listings inside Angel Host, and the diagnosis was that the constraint was never data, it was attention. What was the actual moment that convinced you this needed to be a separate company rather than a new feature inside Angel Host?

Running revenue for thousands of listings inside Angel Host, the pattern was consistent. The team did not lack data or skill. As the portfolio grew, signals fragmented across pricing tools, reports and spreadsheets, and good revenue managers still missed things because there was simply too much to look at every day.

The moment it stopped being an internal frustration was when another operator asked me how we kept up at that scale. I started to answer and realized I could not hand them anything. What we had was a process living in a few people’s heads, and it only worked because those specific people were very good.

That is when it became obvious. Fixing this inside Angel Host would only ever help Angel Host. The layer we needed, something that sits above the pricing tools and tells a revenue manager exactly where to act today, was not specific to our portfolio or our team. Every operator running dynamic pricing hits the same wall, through scale or through time. So it stopped being a roadmap item and became a separate company

3. Sentinel launched in April 2026 and is already powering over 5,000 properties across 42 portfolios. For a product whose whole premise is “trust me to tell you the one thing to act on,” what’s the objection you still hear most from revenue managers who’ve spent years relying on their own dashboards?

The objection is usually some version of “I know my portfolio, I don’t need software telling me what to look at.” They are right. That is not the problem Sentinel solves.

The gap is not knowledge, it is coverage. Nobody reviews hundreds of listings and 365 days of calendar every morning. What changes their mind is not a pitch, it is seeing the reasoning. Sentinel shows the signal and the logic behind every card, so they can check it against what they already know. Once they see it is not overriding their judgment but making sure that judgment lands on the highest-value date first, the request flips to wanting more surfaced, not less.

4. After roughly three decades running companies, you’ve said you’re writing code again yourself, mostly with AI. What’s actually changed in how you build and make decisions now that you’re back in the code, and not just directing people who are?

What changed is how fast an idea becomes something real.

Before, an idea went from my head into a document, then into a meeting, then into a queue. By the time it came back as a screen, weeks had passed. Now I build the first version myself in an afternoon. The team sees the actual thing instead of my description of it. And it’s not only me, my CPO, our lead developers, they can all bring ideas to live in a much faster way!

That speed changes what gets built. When a first version costs a day, you can try five and keep one. Ideas that would never have survived a roadmap discussion get their chance, and the weak ones show themselves quickly.

Starting from something real instead of a description makes the handoff to the engineering team much cleaner, and it has made this the most enjoyable stretch I have had working with engineers.