Mobile Home Park Software: Fixing Lot Rent, Utilities and Title Chaos

Why lot rent software makes or breaks a mobile home park operator

Mobile home parks are the only real estate asset class where you collect rent on dirt, sell or finance the box sitting on it, resell the electricity flowing into it, and track a vehicle title for a structure that has not moved in thirty years. Every one of those is a different data model. Rent Manager, AppFolio, Yardi Breeze, Buildium, and RentVine were all built around a unit that the landlord owns. In a park, the lot is yours, the home is sometimes yours, sometimes the resident's, sometimes a lender's, and sometimes it is an abandoned shell whose registered owner died in 2019. The software has no field for that. So it goes into the notes column.

The setup we walk into looks like this. A regional operator with 1,400 lots across 11 parks in three states. Rent Manager holds the rent roll. A shared Google Sheet named "Water Billing MASTER v7 FINAL" holds sub-meter reads, because Rent Manager's utility billing cannot handle the way the operator actually bills: RUBS at four parks, direct sub-meter pass-through at five, and a flat included rate at two grandfathered ones. A property manager photographs meter dials on her phone on the third of each month, texts them to the office, and someone in accounting types 180 numbers into the sheet. Two of them get transposed every single month. The resident calls, the manager credits it, and nobody ever traces the leak that caused the real 400 percent spike at lot 42.

Meanwhile the title binder lives in a fireproof cabinet. When the operator sold a park last year, the buyer's diligence team asked for proof of ownership on the 63 park-owned homes. It took a bookkeeper nine days to reconcile the binder against the rent roll, and 11 homes had no clean title at all. That is a valuation problem dressed up as a filing problem: 11 homes at roughly $22k of assumed value each that could not be underwritten. Software did not cause that, but the right software would have surfaced it three years earlier.

Problem 1: utility sub-billing that your PM software refuses to model

The specific pain: you have a master water meter from the city, sub-meters at each lot, and a spread between them. That spread is your loss. Rent Manager's utility module can do a basic RUBS allocation and can import reads, but it cannot hold your real logic: park A bills at the city tier rate with a 1.15 admin factor capped by state law, park B bills a flat $38 because the sub-meters were never certified, park C has 22 lots on a single legacy loop that has to be split by occupancy count, and park D is in a state where you can only pass through actual cost with no markup. So finance runs the calculation outside the system and imports the result as a charge line. The system now holds an answer with no audit trail behind it.

Why off-the-shelf cannot fix it: these platforms model utilities as a billing feature, not as an operational asset with meters, loops, leaks, and jurisdictional rules. There is no meter entity with a serial number, install date, multiplier, and read history. There is no concept of master-to-sub reconciliation. You can bolt on Conservice or a similar third party, but you are now paying a per-unit monthly fee, you lose the raw read data, and you still cannot see loss by loop.

What a custom build does: a real meter table keyed to the lot, with read history, multiplier, and install date. The manager's phone becomes the input: photograph the dial, an extraction model reads the digits, and the system flags any read that is lower than the last one or more than three standard deviations above that lot's twelve-month band. That single feature kills the transposition errors and flags a running toilet on day three instead of on the day the city bill arrives. Then a rules engine holds each park's billing method as configuration, not code, so adding park number 12 with a fourth method is a settings change. And a reconciliation view shows master read minus sum of sub-reads by loop, monthly, so a 30 percent line loss under the 1970s section becomes a work order rather than a mystery in your operating expenses.

Problem 2: the home is a separate asset from the lot, and nothing tracks it

Specific pain: lot 17 pays $425 lot rent plus $310 on a note for the home. Lot 18 pays $425 lot rent, and the home is yours, rented at $650 all in. Lot 19 is a lonnie deal you inherited. Lot 20 has a home owned by a resident who moved out and stopped answering, and you are 14 months into an abandonment process. In Rent Manager, all four look like a unit with a rent amount. Your books cannot tell you park-owned home rental income versus lot rent versus note interest without manual GL work, which means your investor reporting and your cap rate math are built on a spreadsheet someone maintains by hand.

Why off-the-shelf cannot fix it: the data model has one object where you have two, plus a financing instrument. You can fake it with unit types and charge codes, but every report downstream inherits the fake.

What a custom build does: separate lot, home, and agreement entities. A home has a VIN or serial, a HUD label, a title status, a year and make, an acquisition cost, a rehab cost roll-up, and a current disposition. An agreement links a resident to a lot, a home, or both, with its own terms. Now the reporting question your lender actually asks, what is our lot-rent-only NOI excluding home sales, becomes a query instead of a project. And when you sell the park, home inventory with title status exports in an afternoon.

Problem 3: title, lien, and tax work that lives in a filing cabinet

Specific pain: in most states the home is titled like a vehicle through the DMV or a manufactured housing division, with its own transfer process, its own lien recording, and in some states a personal property tax bill that follows the title owner. When you repossess a home, you may need a bonded title. When you sell one, you have 20 or 30 days to transfer. Miss it, and you are still the taxpayer of record on a home you do not own, and you find out via a delinquency notice 14 months later.

Why off-the-shelf cannot fix it: no property management platform has a title workflow. It is not in their market. So it lives in a binder, a Dropbox folder, and one person's memory.

What a custom build does: a title record attached to the home, with state, title number, lien holder, transfer status, and next action date. Document extraction pulls the VIN, title number, and owner name off a scanned title or bill of sale so a clerk verifies rather than types. Deadline rules per state generate tasks: home sold on the 5th, transfer packet due by the 25th, assigned to the park manager, escalating to the regional at day 20. The tax angle matters too. The system reconciles your title-of-record list against the county's assessed list annually, and the mismatches are your exposure list.

Problem 4: compliance calendars across states, and the one thing that gets you sued

Specific pain: rent increase notice periods differ by state and sometimes by city. Some jurisdictions require a specific notice form. Some require an annual meeting or a resident association response window. Then there is the physical compliance layer that most PM software ignores entirely: water system testing if you are a public water system, sewer lift station inspections, storm shelter requirements in some states, and skirting and tie-down standards. A missed notice period does not just delay revenue. It voids the increase for the year, which on 1,400 lots at a $30 increase is $504k of annualized rent you cannot bill.

Why off-the-shelf cannot fix it: these tools do notices as templates and reminders as calendar events. There is no jurisdiction table, no version history of which notice went to which resident on which date with what delivery proof.

What a custom build does: jurisdiction rules as data, so each park inherits its state and municipal rule set. Increase workflow calculates the earliest legal effective date, generates the correct form, records delivery method and proof, and archives an immutable copy per resident. Physical compliance items become recurring inspection records with photos, assignee, and a pass or fail, so your lender's annual site review is an export. AI is useful here in a narrow way: summarize an incoming municipal ordinance PDF against your current rule set and flag what changed, for a human to confirm. Do not let a model decide your notice period. Let it find the paragraph you need to read.

Problem 5: after-hours demand, infill, and the leads you never answer

Specific pain: your inbound is a mix of "is the lot rent all in," "do you allow 1998 homes," "I have a home to move in," and maintenance emergencies, and it arrives at 8pm. Park managers are not a call center. Infill is where the value is created: filling 40 vacant lots at $425 is $204k of annual NOI, which at a 6 cap is roughly $3.4M of value. And the pipeline for that lives in text messages.

What a custom build does: an intake agent that answers on the phone and by text after hours, knows the actual rules per park (age restriction, pet policy, home age limit, whether you allow move-ins), qualifies, and books a showing into the manager's calendar. Emergencies route to the on-call line by keyword and never get answered by a bot. Then an infill pipeline entity with lot, prospect, home source, and stage, so the regional can see that park 6 has 12 vacant lots and four dealers who have not been called back in three weeks. This is the one place in the stack where AI shows up directly in the rent roll rather than in a demo.

What this actually costs and how long it takes

Across 2,000-plus projects, Digital Heroes sees this category land in two bands. A focused first release, meaning meters and utility billing engine with photo capture, lot and home separation, and the compliance calendar, typically runs $60k to $130k and ships in 12 to 16 weeks. A full platform adding resident portal and payments, title and lien tracking, home inventory with rehab cost roll-up, infill pipeline, and investor reporting runs $150k to $400k phased over 6 to 12 months.

What drives price up in this category specifically: the number of states you operate in, because each one adds title rules, notice periods, and tax reconciliation logic, and states are the single biggest multiplier here. Payment processing with ACH, card, and cash networks such as PayNearMe or MoneyGram, because a real share of your residents pay cash and that integration is not trivial. Two-way sync with Rent Manager or AppFolio if you are keeping accounting there, which is usually the right call and usually the most fiddly two weeks of the build. Data migration from twelve years of spreadsheets where the home serial number and the resident name were typed inconsistently. And Spanish language support in the resident portal, which is a real requirement in a large share of parks and is cheap if scoped up front and expensive if bolted on later.

Build versus buy: our honest position

Buy if you are under roughly 400 lots, in one or two states, with mostly resident-owned homes and city-billed utilities. Rent Manager at its published pricing does the job, and the money you would spend on a build is better spent on a manager who does not quit. Also buy if you have no internal owner for the software. Custom software with nobody accountable for it decays into the same spreadsheet you started with, only more expensive.

Build when three or more of these are true: you are past 800 lots, you operate in three or more states, you have more than 50 park-owned homes or notes, someone spends more than 20 hours a month on utility billing, or your last acquisition diligence took more than a week to assemble because the data was not in one place. The tipping signal we trust most is this one: when you can name the single spreadsheet that would sink the company if it were deleted, you are already running custom software. You are just running it badly, with no backup, no audit trail, and one person who understands it.

How to choose a developer for mobile home park software

Ask them to model the data before they quote. A team that has done this will separate lot, home, agreement, meter, and title on a whiteboard in under ten minutes and will ask you which states you operate in before asking about screens. A team that has not will propose a units table.

Ask what happens to your accounting. The right answer is usually not "we will rebuild your GL." It is "we will sync to Rent Manager or AppFolio and own the operational layer." Anyone who volunteers to rebuild accounting in phase one is selling you a longer project.

Ask them how they will handle rules that change per jurisdiction. If the answer involves writing code per state, walk. Notice periods, markup caps, and transfer windows belong in configuration that your operations lead can edit without a deploy, with an audit log of who changed what.

Ask who owns the code and the data, in writing, before the first invoice. You should get the repository, the infrastructure accounts in your name, and a documented export path. In this asset class you may sell a park or the whole portfolio inside five years, and a buyer's diligence team will ask where the data lives. The answer needs to be your cloud account, not a vendor's.