Laravel Property Management System: A Custom Build Guide

Most lettings firms do not decide to build software. They drift into needing it. The portfolio grows from a few dozen units to a few hundred, the spreadsheets multiply, a generic CRM gets bent into a shape it was never meant to hold, and the website sits to one side doing nothing useful. One day someone misses a gas safety renewal, or spends a Friday afternoon working out who is actually in arrears, and the question finally gets asked: is there a better way to run this?

This post is about that better way: why Laravel suits a custom-built property management system, and when it is worth the money. We will walk through the real domain a lettings business deals with, where off-the-shelf products frustrate, and what a tailored build gives you, with a couple of concrete workflows so it is not all theory.

The firm that has outgrown its tools

Picture a lettings and property management firm in a mid-sized city, managing around 600 units across several hundred landlords. Some are single-property landlords with one flat; a few are portfolio landlords with twenty or thirty units each. The firm handles full management: rent collection, maintenance, compliance, tenant queries, the lot.

The tooling has accreted over years. A spreadsheet for the rent roll, another for compliance dates, a generic CRM holding contacts and a loose idea of properties, a shared inbox for maintenance, a folder on a drive for documents, and a brochure website that does nothing beyond list available properties. None of it talks to anything else. The same property exists, slightly differently, in four places, and when a tenant rings to chase a repair, someone has to go looking.

This is where a firm pays a quiet tax every day. Not in software fees, but in staff time, missed dates, double entry and never quite trusting the numbers. It is rarely one catastrophe. It is a hundred small frictions.

The domain a property system actually has to model

Before talking about tools, it helps to be honest about how much structure a lettings business contains. This is the bit generic software underestimates.

A property is not one thing. A building can hold several units, and a unit is what gets let. Against each unit you have tenancies, and a tenancy has a start, an end, named tenants, a deposit held in a scheme, and a rent. The rent is not a single number either; it implies a schedule, a series of due dates and expected amounts running into the future. Against that schedule sit actual payments, and the gap between what was due and what arrived is your arrears position.

Then there is the rest of it. Maintenance tickets, tied to a unit and a tenancy, moving from reported to resolved. Documents: tenancy agreements, deposit certificates, inventories, correspondence. Compliance items with hard legal deadlines, gas safety certificates, EPCs, electrical reports, each with an expiry date that must not be missed. Landlords, who own properties and want statements and visibility. Contractors, who do the repairs. And money flowing several ways, rent in from tenants, fees retained, the balance paid out to landlords.

In Laravel terms, this is a set of Eloquent models with clear relationships. A Property has many Unit records; a Unit has many Tenancy records over time; a Tenancy has many RentSchedule entries and Payment records; a Unit has many ComplianceItem, MaintenanceTicket and Document records. Once the domain is modelled honestly, in proper tables with real relationships rather than columns crammed into a spreadsheet, most of the hard problems become ordinary database queries. Who is in arrears this morning has a precise answer, not an afternoon's detective work.

Why off-the-shelf property software frustrates

There are perfectly good off-the-shelf lettings products, and for a lot of firms they are the right answer. We will come back to that honesty at the end. But there are recurring reasons firms move away from them, and they are worth naming plainly.

Rigid workflows. The product encodes one way of doing things, the way its makers imagined. Your firm does something differently, perhaps your arrears process has a particular sequence of letters and calls, or your landlord statements need a specific format, and the software will not bend. You adapt to the software instead of the other way round.

Per-unit pricing that punishes growth. A great many property platforms charge per unit per month. It feels reasonable at 100 units. At 600 it is a meaningful monthly bill, and at 1,500 a serious one, rising every time you do well and take on more. You end up penalised for growth, paying more precisely as the software does proportionally less that is special for you.

The one feature you need is missing. Every firm has a quirk: a particular block management calculation, a specific inspection, an unusual fee split with certain landlords. Off-the-shelf software covers the common 90 per cent well and the awkward 10 per cent not at all, and that 10 per cent is often exactly where your business differs from its competitors.

Integration walls. You want the system to talk to your accounting package, your payment provider, a contractor's portal, or your website. Off-the-shelf products expose what they choose to expose. If there is no API for the thing you need, there is no way through, and you are back to copying data by hand.

None of this means the products are bad. It means they are general, and a growing firm with its own way of working eventually wants something specific.

What a custom Laravel build gives you

Here is what changes when you build the system around your firm rather than fitting your firm around a product.

You model the exact domain. The tables match how your business thinks: your units, tenancy types, fee structures and compliance categories. Reports come straight off that data because it is shaped correctly in the first place.

You get role-based portals on one codebase. Staff work in a full admin. Landlords log in to a portal showing only their properties, statements, certificates and arrears, nothing belonging to anyone else, enforced in code rather than by politeness. Tenants log in to see their tenancy, pay rent, report repairs and find their documents. One application with three doors, and Laravel's authorisation handles who sees what.

For the staff side, a FilamentPHP admin panel is usually the right tool. It gives your team tidy forms for every record type, searchable and filterable tables so finding one tenancy among hundreds takes seconds, bulk actions for the jobs you do at scale, and roles so the right people touch the right things. It feels like proper business software because that is what it is, built around your data rather than a generic content model.

Compliance and rent reminders run themselves through queued jobs, and this is where Laravel's background processing earns its place. A scheduled task runs daily, checks every compliance date and every upcoming rent due date, and queues the right reminders, to staff, landlords and tenants, well ahead of any deadline. The work happens off to the side without slowing the application down, and whether or not anyone remembers. There is more on how this is structured in Laravel queues and dedicated workers.

Documents live in proper storage, attached to the right unit or tenancy, retrievable in a click rather than hunted for in a shared drive. Rent collection integrates directly: most firms collect by Direct Debit through GoCardless, by card through Stripe, or via Open Banking where the lower fees on regular high-value payments add up. The provider connects straight in, payments reconcile against the rent schedule automatically, and the system knows the moment one is late because it knows exactly what was due and when.

And reporting comes more or less for free, because the data is structured. Arrears by landlord, upcoming compliance renewals, void periods, fee income, all a query away.

Walkthrough one: a maintenance request, reported to resolved

Theory is cheap. Here is how a single repair moves through a custom system, and why each step is easier than the spreadsheet-and-inbox version.

A tenant logs into the portal and reports a leaking boiler. They pick the unit (the system already knows which is theirs), describe the problem and add a photo. A MaintenanceTicket is created, linked to the unit and the live tenancy, timestamped, in a "reported" state. The tenant immediately sees a reference and a status, so they are not left wondering whether anyone heard them.

A queued job fires off a notification to the managing agent. The ticket appears in the Filament admin in a clear queue of open work. A staff member reviews it, assigns a contractor from the firm's list, and the contractor receives the details. The state moves to "assigned", then "in progress" as work starts. Every change is logged against the ticket, so there is an audit trail without anyone keeping one by hand.

The contractor completes the job, an invoice is recorded against the ticket, and the state moves to "resolved". The tenant is notified automatically. The cost is now attached to the right unit, so it flows into the landlord's statement correctly and shows up in the firm's reporting on maintenance spend per property. Nothing was retyped, nobody had to remember to tell the tenant, and the whole history of that boiler lives in one place, ready for the next time it plays up.

Compare that with the inbox version: an email arrives, someone may or may not see it promptly, a contractor is rung, the cost is noted somewhere if anyone remembers, and the tenant chases twice because no one told them anything. The custom system does not work harder. It just stops things falling between people.

Walkthrough two: chasing rent arrears

Arrears are where a structured rent schedule quietly pays for itself.

Because every tenancy has a schedule of due dates and expected amounts, and payments reconcile against that schedule automatically, the system always knows the arrears position. There is no Friday-afternoon reconciliation. At any moment, a query answers "who is behind, by how much, and for how long".

A scheduled job runs each morning and looks for due dates that have passed without a matching payment. The day after rent was due and unpaid, the tenancy is flagged as in arrears and a gentle reminder is queued to the tenant. If nothing arrives, the process escalates on a timetable your firm decides: a firmer reminder after a few days, a notification to the assigned staff member, a flag for the landlord's statement, and so on through whatever sequence your arrears policy actually follows. The software runs your process, not a generic one.

Staff see a clear arrears dashboard in Filament: every tenancy behind on rent, sorted by amount or age, with the full payment history one click away. Landlords see their own arrears in their portal, so the calls asking "is my rent in?" largely stop. And because it is all driven by data the system already holds, the chasing is consistent. The tenant who is three days late is treated the same whether or not a staff member happened to notice.

The honest value here is not magic. The firm stops relying on someone remembering, and starts relying on a process that runs itself and is visible to everyone who needs it.

Being honest about when it is worth it

We would be doing you a disservice to claim every lettings firm should build custom software. Plenty should not.

If you manage a modest portfolio with straightforward processes and an off-the-shelf product fits comfortably, use it. Building your own is a real investment, in money to commission it and time to shape it, and that investment only pays back when there is enough scale or process complexity to justify it. A simple operation forcing itself into a bespoke build is making the same mistake, in reverse, as a complex one forcing itself into a generic tool.

The two things that tip the balance are portfolio size and process complexity, and complexity matters more. A firm of 150 units with genuinely unusual workflows, block management, an awkward fee model, compliance the standard products handle badly, can justify a build sooner than a plain 500-unit portfolio that fits a product neatly. The rough test: add up what per-unit licensing costs you, plus the staff time lost to workarounds, double entry and missed dates, over three to five years. When that number comfortably exceeds a build amortised over the same period, custom has earned its place. Until then, it has not.

When it does make sense, the gains compound. You stop paying more as you grow, the awkward 10 per cent that makes your firm distinctive is handled properly, compliance stops depending on memory, and you own the system, so when the business changes the software changes with it.

If you are weighing this up, we are happy to talk it through honestly, including telling you if an off-the-shelf product would serve you better than anything we would build. Book a free consultation and we will look at your portfolio, your processes and the real cost of how you work today, with no obligation and a reply within 24 hours. Our Laravel development page explains how we approach a build like this, from modelling the domain through to handover and support.

AugmentBLU is an Edinburgh studio, working with property firms across Scotland and the rest of the UK, mostly remotely.