Case study
I run an 80-unit, $2.6M real-estate portfolio across 20 separate LLCs. I couldn't find software shaped for that, so I designed and built it — and it runs the operation every day. Here's how it works under the hood.
Role
Sole designer, engineer & operator
Timeline
Nights & weekends, ongoing
Status
In daily production use
Scale
80+ units · 20 LLCs · $2.6M
The situation
Before this, the operation ran on paper and spreadsheets. I color-coded paper statements by hand to figure out which LLC each charge belonged to. Check amounts went on legal pads. Every tenant had its own folder on my desktop, and I could never see the whole portfolio at once.
Commercial platforms (AppFolio, Buildium, Yardi) are excellent at what they're built for: one company managing many properties. This portfolio is the inverse — twenty companies, each with its own books, taxes, and bank accounts, sharing one operator, with constant inter-entity transactions and shared bills to split. The common tools simply aren't shaped for it.
The goal
Replace the patchwork with a single application that handles money, operations, and reporting across every entity — accurate enough to run real books, fast enough to save real hours, and usable by everyone from the office to the field.
Roll up the whole portfolio or drill into a single unit, with clean per-entity books.
Charges, payments, and fees reconcile themselves so the numbers are always trustworthy.
Office staff and field techs use the same data, online or off.
The stack
Every layer — schema, security model, business logic, UI, field app, and integrations — designed and shipped solo.
Framework
Data & auth
UI
Services
The hard parts
The problem
One Amex or Lowe’s statement covers purchases for properties across different LLCs. Re-typing every line into a spreadsheet and tagging each to an entity was hours of work — and a magnet for errors.
What I built
I pipe the statement PDF through Claude with a strict parser prompt (extract every line, exact cents, never invent a transaction, reconcile to the statement total ±$0.01). Files are SHA-256 hashed so the same statement is never parsed — or charged — twice.
The problem
Parsing the statement is only half of it. Each line still has to land on the correct LLC’s books, and doing that by hand every month doesn’t scale.
What I built
A vendor-rule engine matches each line (exact / contains / starts-with / regex) and applies a confidence tier — always (auto-fills), usually (pre-fills, asks me to confirm), sometimes (suggestion only). Entity names resolve through exact → alias → fuzzy substring matching, and the splits validate back to the statement total before anything posts.
The problem
Across 20 entities and ~80 tenants, tracking who owes what — applying partial payments, voids, and bounced checks — was the single biggest source of errors on paper.
What I built
A double-entry-style ledger applies payments FIFO (oldest charge first), and every mutation re-walks the ledger to recompute running balances. Voids are soft-deletes that keep the audit trail; a bounced check posts a reversal plus an NSF fee and re-charges the original — atomically, so the books never drift.
The problem
Twenty separate legal entities share one system. A bug that bled one entity’s data into another’s books would be unacceptable — UI-only checks aren’t enough.
What I built
Isolation is enforced in Postgres with row-level security, under a permission model of nine modules × three levels (view / edit / admin) resolved per request — with a short-lived cache so a page firing five API calls doesn’t hammer the database. Cron endpoints authenticate with a timing-safe secret comparison and guard against double-charging rent.
The bill-breakout tool — sample data
Bill Breakout
American Express — March
Statement total
$4,820.00
The result
The whole portfolio lives in one place. The hours once spent cross-referencing statements, legal pads, and desktop folders mostly went away — so a small team runs an operation this size and the owners get faster answers.
$2.6M
Portfolio run on the system
80+
Units across 20 entities
~32h
Per week to run the operation
~1.5
People (one operator + part-time)
What I took from it
Building Shamar taught me how property-management software works from the inside out — what an operation actually needs day to day, and how to build something accurate and durable enough to depend on. I bring both sides to the table: I've run the operation, and I've shipped the system that runs it.
Benjamin M. Gill
Property manager & full-stack developer