plinthos
Rent management for landlords who rent out rooms, not whole
I built "20 minutes from your university" into a room search
Every rental portal lets you filter by neighbourhood. Which is useless to a
student, because they don't care about the neighbourhood — they care about
whether they can get to their 9am lecture.
So I built distance-by-time instead of distance-by-map.
Plinthos is a rental management tool for landlords renting single rooms, and
it has a public portal attached. On that portal you don't search by area.
You pick your university campus and you say 20 minutes on foot, or 30 by
bike, or 40 by public transport. What comes back is every room inside that
travel-time shape.
Getting there was more work than I expected:
- Isochrones come from Valhalla, self-hosted in Docker. Building the routing
tiles for northern Italy took 18 minutes and 1.7 GB of RAM.
- Public transport needs GTFS feeds, one per city, each in its own state of
disrepair. Valhalla segfaulted on transit until I pruned the feeds down to
urban services only.
- Half the cities I wanted have no usable GTFS at all, so their stops come
from OpenStreetMap instead.
- Every listing gets its travel-time bands computed on insert by a trigger,
so search is a polygon lookup, not a routing call. Search has to be fast;
precomputation doesn't.
10 cities so far. Bologna, Milan, Rome, Turin, Naples, Florence, Padua,
Modena, Parma, Reggio Emilia. Metro lines included where they exist.
The part I like: the same data makes the listings better, not just the
filter. A room isn't "in Bolognina", it's "14 minutes from Unibo
Engineering". That's the sentence the student actually needs, and it writes
itself from the geometry.
Happy to go deeper on the Valhalla setup if anyone's fighting with it —
the transit side in particular is badly documented and cost me a weekend.
Most rental tools assume one apartment, one tenant, one lease. The landlords I kept running into were renting single rooms: one flat, three or four tenants, bills to split every month, deposits to track. They were doing it all in a WhatsApp group and a spreadsheet.
So I built Plinthos around the room. Rent tracking with photo receipts, bill splitting (equal, by days, or by square meters), deposits with a guided check-out, deadline reminders, and built-in chat. The landlord pays after a 14-day trial. Tenants are free forever and join with one link, which is also how it spreads.
Solo founder. Shipped native iOS + Android, a web app, payments on all three, multi-country and multi-currency, in 5 languages.
Happy to answer anything about the build or the two-sided model. What would you want from a tool like this?
-
1
This is a nice wedge — “room-level renting” is a very real use case that most tools ignore.
The distribution loop through tenants joining for free is smart, especially since that’s how these setups naturally work (WhatsApp group → shared tool). That part feels aligned with real behavior, not forced.
The main question is whether you can become the system of record for the household — not just tracking rent, but being the place where everything (payments, communication, deposits) actually happens. If landlords and tenants still fall back to WhatsApp for anything important, it weakens the product over time.
Also curious how you handle trust between tenants (e.g. bill disputes, late payments), since that’s usually where things get messy in shared flats.
Overall though, solid positioning — much clearer than generic property management tools.
-
1
Room level rentals always look like a niche until you realize the operational chaos is constant, not edge case. WhatsApp plus spreadsheets usually works until scale hits and then reconciliation becomes the real product.
The harder part here is not billing, it is standardizing behavior across tenants who do not think of themselves as part of a system. Most tools underestimate that fragmentation problem.
-
1
You're absolutely right. I have plans for this, which I'll reveal at the right time. For now, I'm focusing on validating the entire workflow and making improvements based on user feedback. But I have my own roadmap for outpacing the competitors in the industry.
-
1
Fair enough, no need to reveal the roadmap. One thing worth testing even before any feature ships though: behavior fragmentation usually isn't fixed by adding more functionality; it's fixed by making the default path the easy one e.g. if logging a bill split takes 10 seconds and chasing someone on WhatsApp takes 2 minutes, people switch on their own.
So the early signal to watch for might not be feature requests, it's whether tenants who join via the link actually stay inside the app for day-to-day stuff or quietly drift back to WhatsApp once the novelty wears off. That drift rate would tell you more about the fragmentation problem than any roadmap item.
-
-
-
1
One thing I'd be curious about is whether the tenant side is primarily a distribution mechanism or part of the value thesis itself.
Reading this, I found myself wondering whether "tenants are free forever" is a pricing decision or a clue about how the product is expected to spread.
Those can end up looking similar early on while leading to very different product decisions later.
That's the part I'd be most interested in learning from usage.
-
1
Tenants don't pay for the app; in fact, the cost of the app is just the beginning of my goals. Tenants are the real source of revenue, and I'll focus on that as soon as I'm sure the workflow is optimal.
-
1
That's actually the part I'd be most curious about.
Reading your reply, I found myself wondering whether the tenant model is being shaped by observed behavior or by an expectation about where future value will come from.
Those can end up leading in very different directions.
I've got a few thoughts on that, but it's probably more than I'd try to unpack properly in a thread.
What's the best email to reach you on?
-
-
Comment