Propta turns a single revenue number into a full operating mothership for short-term rental hosts.
A solo, end-to-end product: research, brand, UX/UI, and a working web app with live calendar sync, now running real hosts' real numbers.
Overview
Propta is an operating system for short-term rental hosts. Airbnb, Vrbo, and Booking.com show hosts their revenue — and almost nothing else. Propta turns those bookings into what a business runs on: real profit after every cost, tax set-aside, seasonality, occupancy, and break-even pricing.
I took it from a kitchen-table conversation to a shipped product with hidden beta accounts, where two hosts are now running their actual numbers — and seeing their real profit for the first time.
Now in private beta — testing and refining with real hosts. Shipped solo, end to end.
Hosts only ever see revenue. Most don't know their profit, their costs, or even which KPIs matter.
The Problem
Most STR hosting companies give their hosts one number, and it's the wrong one.
It started at the kitchen table
My mom hosts on Airbnb, and she mentioned the app barely gives her any analytics. I asked what it does show.
"Revenue." That was the whole answer.
Money appears in the account, and that's everything a host learns about their business.
A business nobody taught them to run
The easy diagnosis is that STR sites have weak analytics. The actual problem is deeper: running a short-term rental is running a business, and most hosts have never run one. Many don't know which numbers exist, let alone track them. Profit after the mortgage, cleaners, fees, and utilities. What to hold back for taxes on income nobody withholds. Whether a nightly rate even covers fixed costs in the off-season. The platforms deposit revenue and answer none of it.
Research
Almost every host I interviewed was running their business blind. Each one was blind about something different.
I interviewed the three hosts I could reach directly.
The Accountant
My mom · 1 property, now hosting privately
Runs the family cabin, first on Airbnb and now booked privately. She's an accountant, so spreadsheets don't scare her. She still couldn't say which KPIs were worth watching or what would actually clarify her income.
The Operator
High school friend · 2 properties
Two properties, both doing well. He knows what to do and when to do it, and admits he has no idea what the numbers are doing behind it. Very blue collar, zero interest in spreadsheets.
The First-Timer
High school friend · 1 property
Brand new to renting and open about not knowing what she's doing yet. Works in HR, sharp, and exactly who the educational side of the product is for.
They didn't know their numbers, or which ones mattered
Two of the three couldn't tell me their real numbers, and none of them knew what the numbers should be. Nobody could name their profit margin or what they set aside for taxes. So the product couldn't just display KPIs; it had to quietly teach them. That decision shows up all over the final UI: every metric carries a plain-language caption, like "Share of revenue you keep" or "Set aside before you spend the profit."
Everyone watched a different number
One host watched occupancy, another cash flow, another just wanted to know if she was actually making money. No single dashboard was right for everyone. That killed my first fixed-layout concept and forced the customizable dashboard Propta shipped with.
Any tool that needed recurring manual data entry would be abandoned within a month. Hosts already resent admin work. Whatever I built had to pull bookings in on its own, which later killed the CSV-upload plan and led straight to the iCal architecture covered in Process.
Process
Three problems that shaped the product.
Hosts all needed different numbers, so the dashboard became theirs to build.
My first concept was a fixed dashboard: the "right" KPIs in the "right" order. The interviews broke it. Push occupancy at a host who thinks in cash flow and it reads as noise, and noise is why people stop opening analytics tools.
So I rebuilt it around a customizable Key Metrics row. Hosts pick which metrics sit in it, and the hero stat stays locked on the one number every interview had in common: net profit this month, with revenue always one toggle away.
My plan was CSV uploads. Watching one host manage his calendar killed it, and handed me something better.
My original plan for getting booking data in was CSV uploads. Hosts export from each platform now and then and drop the files into Propta. It technically worked, and it was quietly fatal. The data is stale the moment it lands, and "remember to export your CSVs" is exactly the admin chore my interviews said hosts abandon. A live product running on dead data undercuts the whole selling point.
The fix came from an interview, not an engineering sprint. While I watched how one host tracked his bookings, he mentioned "some sort of link" he used to move his calendar around. I dug into it after the session. It was an iCal feed, and nearly every booking platform exposes one. Airbnb, Vrbo, and Booking.com all publish a host's bookings as a calendar URL that keeps refreshing. That one comment replaced my entire ingestion plan. Paste a link once and Propta keeps bookings, occupancy, and projections current on its own. It does what an official API integration would do here, except it's free and open to anyone, while Airbnb's real API sits behind partnership programs no indie developer is going to clear.
The tradeoff is real, and I took it on purpose. iCal carries dates, not dollars, so costs and rates still come from the host's own one-time setup, and freshness comes from a daily refresh plus a live sync whenever the host opens the app, rather than instant webhooks. In return, Propta works with every platform on day one, with one manual step ever. For an analytics tool, where the calendar drives occupancy, seasonality, and break-even, that was the right trade. It's the decision I'd defend hardest in the whole build.
Seeing profit isn't enough. Hosts need to know what they can't spend.
A profit number on its own still leaves a host exposed. Rental income has no withholding, and slow months still have a mortgage. So Propta plans instead of only reporting. It estimates a tax set-aside from the host's rate and location, surfaces quarterly estimated-tax dates and the usual state and local STR taxes, works out break-even occupancy from the host's own fixed costs ("Booked 80% vs 24% needed to cover fixed costs"), and suggests a peak-season reserve so the strong months carry the soft ones. Each one is labeled as planning help, not tax advice, and the estimates say so out loud. Honesty is part of the interface.
The Build
Shipped like a product, not a prototype.
Propta isn't a Figma prototype with a URL. It's a working product. React 19 and TypeScript on Vite, Tailwind v4, Framer Motion, Supabase for auth and data, deployed on Vercel with two small serverless functions doing the interesting work.
Two layers, and neither one needs the host.
The sync runs in two layers, and neither one needs the host. Airbnb's and Vrbo's iCal feeds can't be fetched from a browser, because those servers send no CORS headers. So the first layer is a tiny read-only serverless proxy. It only accepts HTTPS links from an allowlist of booking domains, so it can't be turned into an open proxy. It fetches the feed with a timeout, checks that it's actually a calendar, parses it with a roughly 100-line iCal parser I wrote, and returns clean JSON cached at the edge for 15 minutes.
The second layer is a scheduled job. Every day a Vercel cron, locked behind a secret and using a server-only Supabase key, sweeps every property's feeds and refreshes booked nights, reservations, and projected revenue, writing only when the numbers actually changed. That's the quiet promise of the product: a host's dashboard stays current even if they never open the app.
The parser encodes decisions, not just dates.
Real host calendars are messy, and the rules are domain decisions. "Blocked" and "Not available" events count as blocks, never bookings. A stay cross-posted to two platforms' feeds gets merged so it's never double-counted. A timed event in a synced personal Google Calendar is treated as personal: an all-day event is a booking, but a dentist appointment must never become rental revenue. The calendar layer also works out facts the raw feed doesn't contain, like same-day turnovers, where a checkout with a check-in that afternoon means a tight cleaning window.
The whole reservation vs block vs personal call, in eight lines.
Deterministic on purpose.
Ask Propta is deterministic on purpose. The chat isn't an LLM call. It's an answer engine that reads the intent of the question and computes the response from the host's own data. Every answer can carry an honesty note ("estimate, not tax advice"), and nothing leaves the device. For a finance-adjacent tool I chose answers that are always true over answers that are always fluent. An LLM can sit in front of this engine later for open-ended phrasing.
Enforced in the metrics engine.
The dashboard's 18-metric library has one hard rule: a metric that needs an input the host hasn't given, like cap rate without a property value, renders locked with a prompt instead of a fake $0. Fixed costs store a billing frequency and normalize to true monthly figures, because treating a $6,000 annual tax bill as a monthly cost makes the profit number garbage. The same honesty extends to the frame. Propta reads numbers, it never moves money, and it says so in the UI.
The demo is the funnel.
Anyone can open the full product on sample data, no account, with a note that nothing they change is saved and a guided Open House Tour to walk them through it. For a product whose pitch is feeling what it's like to finally see your numbers, a live demo converts better than any screenshot, and it doubles as the proof for this case study.
A force multiplier, not a decision-maker.
I used Claude Code to speed up the implementation, so my own time went to the interviews, the cost model, and the judgment calls above. The decisions and tradeoffs in this study are mine. AI just compressed the distance between deciding and shipping.
Craft, in the small stuff.
The theme is applied before first paint, so there's no flash, and the mobile browser chrome color stays in sync.
Break-even occupancy renders as a real bullet graph, not a bar pretending to be one.
Typed inputs for amounts a host knows, sliders for the ones they are estimating.
A status bar shows the last sync and how fresh the numbers are, at a glance.
Good morning or good evening, keyed to the host's own local time.
The Solution
One place where a rental stops being a listing and becomes a business.
Airbnb hands a host one number. Propta hands them the business behind it.
Net profit is the first number a host sees, with costs, margin, and a month of daily bars behind it. The Key Metrics row is theirs to choose.
Profit against last year, seasonality by month, and a plain answer to the scariest question: is your nightly price actually covering you?
The next estimated-tax date, a running set-aside, platform fees, and typical state and local STR taxes. The paperwork layer no platform touches.
Every platform's bookings in one view through iCal sync, driving occupancy and projections with no manual entry.
Plain-language questions answered against your own numbers, computed on the spot and kept on your device.
Set a target and every strong month moves the bar. Propta shows how far off you are and roughly when you'll get there.
An automation layer on top.
Propta already tells a host what's true. The layer I want to build next acts on it. Move the tax set-aside into its own account without being asked. Flag a nightly rate that's about to slip under break-even before the booking lands, not after. Turn a receipt into a filed expense in the right category. The numbers are already live and trustworthy, which is exactly what makes automation the natural next step: the tool stops being something a host checks and starts being something that quietly keeps them ahead.
Outcome
Two hosts put their real numbers in. One found out what he was actually making.
Propta is live: a public demo, a landing page with a waitlist, and hidden beta accounts where two hosts run their real properties through it.
One host, looking at his month with every cost finally accounted for:
"Wow, I'm really only making $300 in profit this month."
He'd never have known that without paying someone to build the spreadsheets for him. That one sentence is the product working exactly as intended.
This is early, and I'll say so plainly.
Two beta users and qualitative feedback so far, with no conversion or retention data yet. Here's what I'd measure next.
Demo to account sign-up
The moment the product actually clicks
Do hosts come back on their own
Rate changes, tax money actually set aside
Reflection
Most of what made Propta good came from listening, not from building.
I'd talk to hosts before I sketched anything. My first dashboard was a confident guess, and it took real interviews to show me it was the wrong shape. The customizable layout that shipped was sitting in those conversations the whole time. I just reached it the long way around. On the next project, the sketching starts after the listening, not before.
The hard part was never the interface. It was figuring out what hosts actually needed when each one needed something different. Interviews kept overruling my assumptions, and the product got better every time I let them. Shipping to real users also beats polishing in private: the $300 moment taught me more than another month of design ever would have.
Market-rate comps by location and season, which is the half the rate check is still missing. The automation layer that acts on the numbers instead of only showing them. And turning the waitlist into a real beta cohort.