Bruno ANTUNES

Posted on Mar 19

Rentilot: A Practical Alternative to Rentila for Property Management

#php #webdev #saas

If you're a landlord or a developer building tools for landlords, you've probably seen the same pattern: most property management apps are good at administrative storage but weaker on decision support.

This is exactly the gap I wanted to close with Rentilot.

In this article, I’ll break down the technical thinking behind building Rentilot as an alternative to Rentila: domain model, automation flows, financial metrics, and implementation trade-offs.

Why Build an Alternative?

Many rental tools solve the basics:

rent receipts
tenant records
document storage

That’s useful, but not sufficient once your portfolio grows.

In practice, owners need answers to questions like:

Which property is underperforming this quarter?
Where are payment delays becoming structural?
Which expenses are hurting cash flow the most?
What is the real return net of vacancy, incidents, and recurring costs?

So the product objective becomes clear:

Move from admin management to portfolio steering.
That's the idea of Rentilot : https://www.rentilot.fr

Product Design Principle: Operational First, Analytical Second

A common mistake in proptech SaaS is to start with dashboards.

We did the opposite:

Build reliable operational workflows.
Generate clean events from those workflows.
Compute metrics from event history.

This sequence matters because analytics quality is directly tied to event quality.

Core Domain Model

At minimum, you need these entities:

Property
Unit (optional, for multi-unit assets)
Lease
Tenant
Charge (scheduled expected payment)
Payment (actual received money)
Document
Reminder
Incident

A simplified relationship view:

One Property has many Leases
One Lease has many Charges
One Charge has zero to many Payments
Late status is derived, not manually entered

Why this model works

It separates what should happen (Charge) from what happened (Payment).

That single decision makes delays, partial payments, and arrears much easier to compute without brittle hacks.

Rent Lifecycle as a State Machine

Instead of booleans like is_paid, model rent collection as states:

scheduled
partially_paid
paid
late
written_off (optional)

State derivation (example in PHP-like pseudo-code):

`function chargeStatus(Charge $charge, array $payments, DateTimeImmutable $now): string
{
$paidAmount = array_sum(array_map(fn($p) => $p->amount, $payments));

if ($paidAmount >= $charge->amount) {
    return 'paid';
}

if ($paidAmount > 0 && $paidAmount < $charge->amount) {
    return $now > $charge->due_date ? 'late' : 'partially_paid';
}

return $now > $charge->due_date ? 'late' : 'scheduled';

This is more robust than manually updating statuses from UI actions.

Automation Engine: Receipts and Reminders
Automation should be deterministic and idempotent.

Typical rules:

Generate receipt when a charge becomes fully paid
Send reminder on D+3 if status is late
Escalate reminder on D+10 if still unpaid
Pseudo-code:

<?php
if ($charge->statusChangedTo('paid')) {
    dispatch(new GenerateReceiptJob($charge->id));
}

if ($charge->isLateByDays(3) && !$charge->hasReminder('soft')) {
    dispatch(new SendReminderJob($charge->id, type: 'soft'));
}

if ($charge->isLateByDays(10) && !$charge->hasReminder('formal')) {
    dispatch(new SendReminderJob($charge->id, type: 'formal'));
}

Important implementation notes
Use unique job keys to avoid duplicate reminders.
Keep reminder templates versioned.
Persist reminder attempts with timestamps and delivery status.
Financial Steering: Metrics That Actually Matter
A landlord doesn't need 30 charts. They need a few reliable indicators:

Collection rate
Average delay days
Net monthly cash flow
Property-level yield trend
Vacancy impact

Example SQL for monthly collection rate:

SELECT
  DATE_TRUNC('month', c.due_date) AS month,
  SUM(c.amount) AS expected,
  COALESCE(SUM(p.amount), 0) AS collected,
  CASE
    WHEN SUM(c.amount) = 0 THEN 0
    ELSE COALESCE(SUM(p.amount), 0) / SUM(c.amount)
  END AS collection_rate
FROM charges c
LEFT JOIN payments p ON p.charge_id = c.id
GROUP BY 1
ORDER BY 1 DESC;

The key is consistency, not sophistication.

In practice, simple, trusted indicators outperform complex but unstable analytics.

Documents: From Storage to Workflow Artifact
Document modules are often treated as dead folders.

A better approach:

Link documents to domain events (lease_signed, receipt_generated, incident_closed)
Enforce metadata (property_id, tenant_id, type, period)
Make document generation part of the pipeline, not a manual upload step

That allows one-click traceability when disputes happen.

Migration Strategy (From Spreadsheet or Another Tool)

Most users switch with data that is:

incomplete
inconsistent
duplicated

A reliable migration pipeline usually has 4 stages:

Import raw files (CSV/XLS export)
Normalize fields (dates, amounts, references)
Validate constraints (required links, duplicate checks)
Dry-run + reconciliation report before final commit

Do not skip reconciliation.

If expected rent for March is €12,400 and imported charges sum to €11,950, stop and explain why before go-live.

Observability and Reliability
For a property management tool, failures are expensive because they impact money and legal documents.

Minimum observability setup:

Structured logs for billing/reminders/document generation
Business alerts (not only server alerts), e.g. "receipt generation failure > 1%"
Audit trail for sensitive actions (deletion, lease edits, manual overrides)
Daily consistency checks (expected vs generated receipts, due vs paid totals)

Example business alert:

Trigger: late_reminders_sent / late_charges < 0.95
Meaning: reminders pipeline is drifting

This catches product issues earlier than raw CPU or memory metrics.

Where Alternatives Win (and Where They Don’t)

An alternative tool like Rentilot can win on:

focus (investor-first workflows)
speed (faster roadmap decisions)
clarity (fewer, better metrics)

But there are trade-offs:

narrower feature coverage in edge legal cases
less ecosystem maturity
migration friction for established users

So the right question is not "Which tool is universally better?"

It is: Which tool matches your operating model today, and can scale with your decision complexity tomorrow?

Final Takeaway

Building a Rentila alternative is not about cloning screens.

It’s about rethinking the core job-to-be-done:

from managing records
to steering performance

If your architecture captures operational truth (charges, payments, events), automation and analytics become reliable by design.

That’s the direction behind Rentilot: less admin friction, more financial visibility, better decisions.

If you’re building in this space too, I’m happy to compare implementation patterns and trade-offs.

DEV Community