The tech, and the receipts
How it's built, where the code lives, and every number's source.
How it's built
Liberty Bee is an event-driven Monte-Carlo simulation engine — Python 3.12 + SQL Server — that plays out 240 months of housing operations per run: acquisitions, leases, renewals, maintenance events, inflation regimes, tenant retention. Every random draw comes from a recorded seed, so any run — a survival, a death, one tenant's discount schedule — can be reproduced exactly by anyone with the code.
Take it. Change the assumptions you doubt. Run it against your own city. If we got something wrong, this is how you'll prove it. And this is how you'll let me know: libertybeegray@gmail.com
Under the hood — the property market
Liberty Bee doesn't hand itself buildings. It runs a simulated property market that behaves like a real one: listings appear and disappear on a daily clock — more of them in the busy season — each priced from real local sales data and sized by real unit counts. Every building carries a days-on-market and a hold-period drawn from real distributions, so some sell fast, some linger, and owners sit on a property for years before it comes up again.
Against that market the operator does what a careful buyer does: watch what's available, value each property on its rents and its condition, and buy it outright when the numbers work and the cash is there. There's no auto-granted portfolio — every acquisition is a decision the model has to be able to afford, which is exactly why the starting-capital question has a hard floor.
The market's inputs — prices, rents, listing volume, days-on-market, seasonality, how long owners hold — are all calibrated from public real-estate and housing-market data for the Salem area. Where a number is a local market observation rather than an official statistic, we treat it as a calibration input, not a published claim — the goal is a market that behaves like Salem's, not a listings database.
Under the hood — inflation
Plenty of housing models pick one inflation number — say 3% a year — and let it ride. That single assumption can make an operator look invincible: a steady rate never produces a bad year. The world doesn't work that way. Neither does our simulation.
Instead, the model treats the economy as a set of regimes — calm stretches, rent surges, financial downturns, post-shock recoveries — and moves between them month to month, the way real markets do. And critically, everything inflates on its own track: rents, operating costs, property values, and vacancy don't march in lockstep. We model that because that decoupling is exactly what hurts a real operator — in a downturn, property values fall and vacancy climbs while taxes and insurance keep rising anyway. So we model it honestly.
The regimes are calibrated from real federal inflation and housing-price history. There have been only a couple of genuine crises in the last forty years — too few to simply resample — so how often a downturn strikes is a modeling decision we made to the best of our ability, not a statistic we can pretend to have measured. When we say "every market regime, calm to crash" that means something here, because the model has to survive surges and crashes, not one flattering straight line.
Compensation — how the deal got its numbers
Earlier versions of this model ran on two subsidies at once, and one of them was hidden. The visible one was the tenant deal: sign 10% below market, deepening by 5, 5, and 10 points at years 3, 6, and 10. The hidden one was payroll: staff pay was set at what the founder was personally prepared to live on — a declared value, not market data. The simulations survived because someone was quietly underwriting them out of their own paycheck.
So we repriced the labor and reran everything. At each region's own market wages (BLS metro medians to hire, 75th-percentile caps for a career, 25% benefits), the old configuration stops working: at real market pay, the original Salem model has no clean survival floor anywhere up to $11M, and at metro-median pay the Massachusetts floors climb by $1.5–3M each, and San Francisco's by about $4M. Paying people fairly is not a rounding error — the founder's sacrifice had been worth more than $4.5M of starting capital.
The current deal is what survived honest pricing: sign 5% below market, deepen 3/3/5 at the same year-3/6/10 marks, keep the 10% timely-payment credit, and pay real regional wages. In Salem that model holds from $7M — five hundred thousand dollars more than the founder-sacrifice original needed. Every generation of this reckoning ships as a reproducible corpus in the release, so you can check the fork we took — or take the other one, knowing its price.
The discount axis was tested to its limits too: at the subsidized pay basis, no funding level we tested — up to $11M — guaranteed survival past a 40% discount. Deeper generosity doesn't just cost more; past a point it stops being purchasable at all. The full sweep behind that — every discount depth from 15% to 50% off, at every funding level, on both the 2025 and 2026 records — ships in the release datasets for anyone who wants the dose-response data.
Wage basis: BLS OEWS May 2025, each region's own metro. Metro-area medians are deliberate — staff hire from the metro labor pool, and parts of a metro naturally run above or below the metro median. The cockpit's staffing page is the adjustment tool if your labor market differs.
Built the hard way
A model is only worth trusting if the people building it tried to break it. So we did — and when we found something wrong, it went on the page, even when the fix made our numbers worse. A sample of what we caught:
The full list — every defect we knew about at close, its cause, and its fix status — lives on the known-issues ledger. It stands as the final honesty ledger of the project.
The honest fence — in full
A model that only tells you its wins isn't a model, it's a pitch. An honest model names its own edges. None of these move the survival record; all of them bound what it can claim. The defects we know about — cause, status, fix — live on the known-issues ledger; these are limits, not bugs.
Where it isn’t finished — and where it was headed
Development wrapped here: the project is mothballed with the record complete. But the roadmap was real, and it stays published — for a future version of this project, or for whoever picks the model up first. What was next:
The model isn't flawless. What we stand behind is the direction it was built in: every pass made it more real and more mission-true — even when that was less flattering to us.