The brief we got for Rentfol.io did not start with a wireframe. It started with a tax problem. The client had a rent calculator that Finnish landlords already used, and a list of everything they wanted bolted onto it: listings, tenant accounts, a service marketplace, a calendar. Our position, then and now, is that most landlord apps get built in the wrong order. Listings first, messaging second, money last. The money is the product. Everything else is a feature.
This piece is about what that means when you build an all-in-one rental management platform, with Rentfol.io as the worked example. Some of what follows is opinion. We will say so when it is.
Why the all-in-one rental app keeps failing on accounting
Look at the feature list of any landlord app launched in the last five years. Listings. Screening. Chat. Maintenance tickets. Rent collection. Somewhere near the bottom, "financial reports." That ordering reflects how founders think about demand: tenants are the volume, so build for tenants first, and the landlord's books can be a CSV export later.
The ownership data points the other way. Per the 2021 Rental Housing Finance Survey from HUD and the Census Bureau, released in November 2022, individual investors own about 70 percent of US rental properties, and only about 22 percent of properties with one to four units are professionally managed. The typical landlord is one person with two or three doors, no bookkeeper, and a filing deadline. That person does not need another listings site. They need to know, in March, what they can deduct.
"Small landlords are fine with a spreadsheet and Venmo. Nobody is going to pay for an app to do what Excel already does for free."
We hear a version of this in almost every discovery call, usually from an investor rather than a landlord. It is half right. Excel does track income. What it does not do is capture the receipt at the moment of the expense, tie it to the property, apply the right tax category, and keep the original image for the years a tax office can ask for it. Four chores, and the second one is where the system breaks. A receipt not captured within a day or two is gone.
The feature-checklist approach fails for a related reason. When every module is a peer, nothing is the system of record. The listing stores one copy of the rent amount, the chat another, the reports screen computes a third. Reconciling them becomes the job the user was trying to escape. That link between the checklist mindset and the reconciliation mess is our inference from projects we have shipped, not something any vendor admits on a pricing page.
What an accounting-first rental app actually is
The accounting-first rental app is a platform where the ledger is the system of record and every other feature either writes to it or reads from it. A lease is a scheduled income event. A maintenance ticket is a pending expense with a receipt attached. A calendar entry is a due date on a ledger row. Search and messaging sit on top, not alongside.
The practical test is short. Delete every screen except one and ask which one the landlord would keep. In our experience it is never the chat.
At its core, the ledger has to capture:
Income per property on a schedule, so a late payment gets flagged the day it is late rather than noticed in April
Expenses with a category, an amount, a date, and the original document image attached
A tax model that knows the local rules, including rate thresholds and which categories are deductible
Portfolio roll-ups, so an owner with five units sees year-to-date totals per unit and in aggregate
An export an accountant will accept without reformatting
Nothing on that list is glamorous. All of it is what a landlord opens the app for on the second day, which is when retention gets decided.
Spreadsheet, rental SaaS, or custom real estate development software: what each route buys you
Three routes exist for a landlord or a founder who has outgrown the shoebox of receipts. The first is a spreadsheet plus separate tools for payments, documents, and reminders. The second is an off-the-shelf property management SaaS in the Buildium or AppFolio tier, priced per unit per month and shaped around US multifamily books. The third is the kind of real estate development software that handles accounting, maintenance, and tenant communication in one place, modeled on one market's tax rules and one specific set of user roles. The table is how we frame the trade before any code gets written.
Route | Upfront cost | Ongoing cost | Control over the data model | Accounting depth | Multi-user roles | Time to launch
|
|---|---|---|---|---|---|---|
Spreadsheet plus separate tools | Near zero | Hours of the owner's time every month | Full, but every rule is a formula you maintain | Shallow, no tax logic unless you write it | None, one owner | Same day |
Off-the-shelf PM SaaS | Low | Per-unit monthly fees that grow with the portfolio | Limited to the vendor's schema and reports | Good inside the vendor's home market, thin outside it | Fixed roles the vendor defined | Days to weeks |
Custom all-in-one platform | $30,000 to $120,000 for a platform with integrations, per LITSLINK's published 2026 tiers | Hosting, support, and feature work | Full | As deep as the tax code you choose to model | Any roles you define, such as tenant, landlord, service provider | Proof of concept in 4 to 8 weeks, full system in 3 to 6 months |
The honest reading is that the spreadsheet wins at two units and the SaaS wins at two hundred units in one US metro. The custom route makes sense in the gap between: a product company serving thousands of small landlords in a market whose tax rules nobody else has modeled, or a portfolio owner whose roles do not fit a vendor's template. Rentfol.io sat in that gap.
The build sequence we used for Rentfol.io, and why the ledger shipped first
Our client was Rentcal Oy, a Helsinki PropTech company founded by property investors. Their product, Vuokrakulut, was a rental expenses calculator built for the Finnish market, where tax reporting on rental income is paperwork-heavy and the rates bite. The goal was to grow it into Rentfol.io, a platform for landlords, tenants, and service providers, without losing the thing people had downloaded it for. The case study covers the full scope. Here is the order we built in and why.
Ship the ledger and the tax model before anything else. The first phase was the calculator itself: per-property income logging with due dates and recurring schedules, expense capture by category, and a live tax calculation using Finland's capital income tiers of 30 percent up to 30,000 euros and 34 percent above that. A team of five shipped it in about ten weeks across five two-week sprints, timed to land before Finland's spring tax window. Logging an expense takes about fifteen seconds. That number mattered more than any feature on the later roadmap.
Make document capture a ledger write, not a file cabinet. Every receipt photo, invoice, and renovation record attaches to an entry, with the original image kept on S3 behind signed URLs for six years. Rentfol.io later extended this into a paperless record system for contracts and receipts that users can edit and comment on, plus a service book holding each property's renovation and maintenance history. A document without a ledger row is a photo. A document with one is evidence.
Add identity and roles only once each role has something to see. Rentfol.io has three user types: landlords, tenants, and service providers. We did not build tenant accounts until there was a lease schedule for a tenant to see and receipts for them to receive. Landlord and service provider profiles are verified manually, which is slow, unfashionable, and exactly what prevents fraud when a fake listing can cost a renter a deposit.
Put the calendar on top of ledger dates. The centralized calendar with notifications did not get its own data model. Rent due dates, inspections, and maintenance appointments already lived in the ledger and the service book. The calendar reads them. This sounds like an implementation detail. It is the whole argument of this article in one feature.
Build search and the marketplace last. Property search with filters for living space, apartment type, furnishing, and bedrooms, saved listings with status tracking, and a service provider directory with reviews by industry and location all came after the money features were stable. By then there were verified landlords to list.
Expand the tax model by country, not by feature. The app launched Finland-only. A 2026 update added Spanish property tax calculations, and a later release let owners copy income and expenses across properties in different countries, with the form adjusting to each country's rules. That only works when the tax model is a first-class object rather than a formula hard-coded into a reports screen.
Proof: what Rentfol.io shipped, with what team, in what time
Numbers, because a build sequence without them is just a preference.
Phase one, the Vuokrakulut tracker, took a team of five (one project manager, two mobile developers, one backend developer, one QA engineer) about ten weeks and launched on iOS and Android with React Native on the front and Ruby on Rails with PostgreSQL on the back. In its first year it passed 1,000 downloads on Google Play with a 4.1 rating across 23 or more reviews, followed by more than 60 updates. The client reported that annual tax filing for a landlord with one to three properties dropped from four to six hours to 15 to 20 minutes. We did not measure that ourselves, so treat it as client-reported.
Rentfol.io itself, the second phase, ran about a year with a team of six on React Native, React.js, and Ruby on Rails. Our scope was product design, development, full-cycle QA, and store publishing. The app is listed under Rentcal Oy in the Finance category, sells at $3.99 a month or $24.90 a year, and went from Finland-only to available worldwide. Between February 2025 and October 2026 the App Store version history shows more than two dozen releases, including the Spanish tax support and the cross-country expense copying mentioned above.
We do not have retention or revenue figures we are cleared to publish, so we will not invent them. What we can say is that the post-launch roadmap stayed almost entirely inside the ledger: new tax filing items, receipt export per property, country-specific forms. Years on, the calculator is still the product.
Renters already expect the money to move online
The tenant side of the ledger is measurable demand, not a nice-to-have. Zillow's Consumer Housing Trends Report for rentals, built on a survey of about 36,000 renters fielded from March to July 2024, found that 65 percent of renters now typically pay rent online, up from 50 percent in 2020, and 73 percent say they would ideally pay online. A quarter of renters passed on a property because it did not offer an online application. Electronic lease signing among recent renters went from 21 percent in 2018 to 43 percent in 2024.
Read those as ledger facts. Every online rent payment is an income row with a timestamp. Every e-signed lease is a schedule. The tenant pulls the landlord onto the platform, and the platform earns its keep by writing what the tenant did into the landlord's books without anyone retyping it. An app that handles the payment but not the accounting has solved the tenant's problem and handed the landlord a new one.
What to do now if you are planning a landlord app
Write the tax model before the user stories. Pick the jurisdiction, list the deductible categories, note the rate thresholds, and define what the export to an accountant looks like. If this takes a week, good. It saves a quarter.
Pick one market and one tax year for the MVP. Rentfol.io started Finland-only and added Spain later. A model that handles one country completely beats one that handles four approximately, because approximate tax math is a liability, not a feature.
Decide the roles by who pays. Landlords paid for Rentfol.io, so the landlord ledger shipped first and tenant accounts came when there was something to show them. If your revenue comes from property managers or service providers, reorder accordingly, but keep the ledger at the center.
Budget for document retention from day one. Six years of receipt images across thousands of properties is a storage and access-control problem. Signed URLs, lifecycle policies, and an export path belong in sprint one, not sprint eighteen.
Treat listings and search as a growth feature, not a launch feature. They are expensive to build well, they need verified supply to be useful, and nobody churns because search filters arrived in month nine.
Where rental platforms go from here
The US market is handing landlords more reasons to care about the books, not fewer. The Census Bureau's Housing Vacancies and Homeownership release for the second quarter of 2026, published July 28, 2026, put the national rental vacancy rate at 7.3 percent and the median asking rent for vacant units at $1,531. A 7.3 percent vacancy rate is a lot of turnovers, and every turnover is a cluster of expenses, a gap in income, and a stack of receipts that either lands in the ledger or does not. The landlords who come out ahead in a softer market are the ones who can see their numbers per unit without a weekend of data entry.
Our guess, and it is a guess, is that the next wave of rental platforms gets judged on how little typing they require. Receipt images categorized on capture, bank feeds matched to lease schedules, tax forms pre-filled from the ledger. All of that only works if the ledger was the foundation from the start. Bolting an accounting layer onto a listings app in year three is the most expensive way to reach the same place.
If you are scoping a landlord app and want a second opinion on the build order, our team at LITSLINK has shipped this sequence more than once and is happy to argue about it.
Build the books first, and the rest of the platform has something to stand on.
