Case study 02 · Real-estate & construction ERP

Marrea

An enterprise ERP for a Philippine real-estate developer and its construction subsidiary — from selling a block-and-lot unit to collecting amortisations for years, building the house, and paying everyone involved.

Senior engineer & technical lead · five-developer team Feb 2024 – present
Laravel 12 PHP 8.2+ Filament v5 Livewire 4 Tailwind 4 Pest 4 Larastan Pusher PhpSpreadsheet FPDF/FPDI · DomPDF AWS S3
~240k lines of PHP
361 Eloquent models
1,599 migrations
7,671 commits · 1,203 mine
2 Filament panels
241 test files

The problem

A housing development is a decade-long financial object. A buyer reserves a unit, finances it through a bank or Pag-IBIG, and pays amortisations for years — through penalties, overpayments, price adjustments, and financing takeouts. Meanwhile the developer’s construction subsidiary procures materials, tracks cost-to-finish, runs a motor pool, and pays its people under Philippine statutory rules.

Before Marrea, that lifecycle lived across disconnected tools that could not answer the questions that matter — what is this buyer’s true balance, what will this project cost to finish, where is the cash — without manual assembly.

The system

Two Filament panels on one domain model: back-office for the developer and back-office/mbc for the construction subsidiary, each with its own resources, pages, and login. Underneath: 361 models, 86 services, 147 policies, layered as Actions, DTOs, Contracts, Observers, Rules, and queued Jobs.

Developer panelsales & buyer accounts · receivables · payables & treasury · procurement · HRIS & payroll · commissions · compliance
Construction panel (MBC)BOQ / POW / QTO imports · cost-to-finish · progress billing · stocks & transfers · motor pool
Shared domain model — 361 models · 86 services · 147 policies · Actions / DTOs / Observers / queued Jobs
Team infrastructure — versioned .agent-docs/ with routing table · Pest 4 · Larastan · PHP-CS-Fixer · full audit log
Sales & buyer accounts
block/lot inventory · reservations · contract-to-sell · TCP recalculation · cancellations · document workflow
Accounts receivable
amortisation schedules · penalties · overpayments · loan proceeds · bank & Pag-IBIG takeout monitoring
Payables & treasury
vouchers with allocation & sequencing · cheque library · bank reconciliation · general journal · petty cash
Procurement
canvass history · PO requests · multi-stage approvals · item-level deliveries · equipment rentals
Construction (MBC)
BOQ/POW/QTO imports · cost-to-finish · progress billing · labour matching · stocks, pullouts, transfers
HRIS & payroll
biometric import · SSS/PhilHealth/Pag-IBIG calculators · leave credits · KPI tracking · org chart
Motor pool
mobilisation · fuel monitoring · preventive maintenance · spare parts · trip tickets with PDFs
Cross-cutting
compliance obligations · agent commissions & incentives · admin ticketing

Engineering deep-dives

Where the work was mine, it says so. Where it was the team’s, it says that too.

01

Leading five developers in a 240k-line ERP

At this size, no one holds the system in their head. The quality mechanism is review: 1,203 commits of mine, a large share of them merges, gatekeeping every feature branch into a coherent whole.

The second mechanism is written standards over tribal knowledge — a versioned .agent-docs/ directory with a routing table that every contributor, human or AI assistant, works from. It exists as a deliberate answer to keeping five developers consistent in one codebase.

Review-as-gatekeeping costs the lead most of their feature velocity. The trade is deliberate: one integrator who says no is cheaper than five divergent styles compounding for years.

02

HRIS v2 + Payroll v1 — built by me, end to end

Philippine statutory payroll means SSS, PhilHealth, and Pag-IBIG calculators that must be right every cutoff. Attendance comes from biometric devices, and device data is bad data: the import pipeline stages rows into staging and error tables with batch tracking, so a corrupt export is recoverable rather than fatal.

When a punch is wrong, an override workflow with proof-of-time attachments corrects it — with an audit trail, because a payroll correction without provenance is a dispute waiting to happen. Cash advances and an hours badge round out the subsystem.

Staging tables double the storage and the moving parts of ingestion. The alternative — rejecting a whole biometric batch for one malformed row — was worse for the people whose pay depends on it.

03

Receivables that must stay correct for a decade

An amortisation schedule is a promise the system keeps for years — through penalties, overpayments, equity adjustments, down-payment overrides, price recalculation, and eventual bank or Pag-IBIG takeout. A rounding decision made in year one compounds for ten.

Total-contract-price recalculation runs as a queued job with its consequences flowing through the schedule, and every financial mutation is audited — the team treats a buyer ledger the way a bank would.

Recomputable schedules are harder to build than append-only ones, but real contracts get adjusted; a schedule that cannot absorb an adjustment forces the adjustment into a spreadsheet outside the system.

04

Two panels, one domain model

The construction subsidiary got its own Filament panel and login — back-office/mbc — rather than a role flag inside the developer panel. Construction users see construction: BOQ imports, cost-to-finish, progress billing, the motor pool, and nothing about buyer ledgers.

What it bought: independent navigation, resources, and access control per business, while both panels share the 361-model domain underneath — no data duplication, no cross-company sync.

Two panels mean some resources exist twice in slightly different forms. That duplication is visible and cheap; a single panel where every page branches on company would have been invisible and expensive.

Stack & practices

Outcome & hindsight

The system runs the developer’s sales, finance, HR, and construction operations across two panels, maintained by a five-developer team with review-gated merges. My directly-attributable subsystems — HRIS v2, Payroll v1, attendance, cash advances, cash-position reporting, and the projects/model-units modules — are in daily production use.

What I’d do differently: invest in the shared written standards even earlier. The .agent-docs/ discipline that now keeps the team consistent was an answer to drift that had already happened; starting with it would have been cheaper.