5 minute read

It’s 11:40pm. Do you know where your polygons are?

It’s 11:40pm on a Friday and I’m staring at a ZIP code boundary that won’t render correctly on a map for the 20th time. The polygon is trying to wrap itself around the entire Eastern seaboard because somewhere in a coordinate system I don’t fully understand, a projection did something a projection should not do. My wife went to bed an hour ago. I am debugging a map.

This is, apparently, how I relax now.

I own two rental properties. I underwrote both of them the old-fashioned way: a spreadsheet, a lot of Zillow tabs, some gut feel, and a healthy dose of “well, it seemed fine.” It worked out. But “it worked out” is not a strategy, and I’ve always wanted something more rigorous — something that forces me to ask the boring, unglamorous questions before I fall in love with a listing photo of a nice kitchen.

So I’m building one. It’s called, very unpoetically, the REW platform (real estate underwriting — I never claimed to be a marketer). And I want to talk about it now, while it’s unfinished, rather than waiting until it’s polished enough to be impressive. Partly because I think the process is more interesting than the finished product. Mostly because I suspect I’m going to get a bunch of this wrong, and I’d rather be honest about that from the start than pretend I built a flawless machine on the first pass.

The Actual Problem I’m Trying to Solve

Here’s the question that matters: out of every possible place I could buy a rental property, how do I quickly rule out the bad ones and spend my real time and energy only on the good ones?

Most people do this backwards. They fall for a specific house, then start justifying the numbers to themselves. I’ve done this. It’s a great way to talk yourself into a mediocre deal because you already mentally moved in.

So I’m trying to build a pipeline that works in the opposite order: start broad, get skeptical fast, and only let a deal survive if it earns its way through several rounds of me actively trying to kill it.

Right now, that pipeline has three stages.

Stage One: Is This ZIP Code Even Worth Looking At?

Before I care about any specific house, I want to know something more fundamental: is this area one where owning a rental makes sense at all?

I built a scoring engine that pulls data from a handful of sources — Census, HUD, FRED — and boils a ZIP code down to six metrics I actually care about as a landlord:

Population growth (are people moving here, or leaving?)
Unemployment (is the local job base healthy?)
Price-to-rent ratio (are prices in line with what rent can support, or wildly detached from it?)
Median income (can the local population actually afford the rents I’d need to charge?)
Vacancy rate (is there a glut of empty units I’d be competing against?)
Supply pipeline (how much new housing is already under construction or permitted nearby?)

That last one took me the longest to get right, mostly because “how much is being built near here” turns out to be a genuinely annoying question to answer with public data. I ended up pulling county-level building permit data from the Census Bureau and matching it up as best I can to individual ZIP codes. It’s not perfect. I know it’s not perfect. But it’s a meaningfully better signal than “I have a feeling about this neighborhood,” which was more or less my prior methodology.

The output of stage one is just a score and a rough read on the market. It’s not a green light to buy anything. It’s closer to deciding whether a neighborhood deserves five more minutes of my attention.

Stage Two: Now Let’s Try to Kill It

This is my favorite part, mostly because it’s the part I was worst at doing manually.

Once a ZIP code clears the first screen, I don’t move straight to a full underwriting model. Instead, I run a quick, deliberately unforgiving pass on the specific property: rough rent estimate, rough expenses, rough financing assumptions, and a gut-check cash flow number. Nothing fancy. The whole point of this stage is speed and skepticism, not precision.

I’m explicitly trying to find a reason to say no. If a property can’t survive a lazy, surface-level version of the math, it has no business surviving the detailed version. This saves me from the trap I fell into with my own properties: spending three hours building a beautiful, detailed model for a deal that a five-minute sanity check would have thrown out immediately.

Think of it as triage. A property that fails here doesn’t get a eulogy. It just doesn’t move to the next room.

Stage Three: Full Underwriting, For the Survivors Only

Only the properties that make it through both filters get the full treatment: a detailed cash flow model, sensitivity around rent and expense assumptions, and eventually — this part isn’t built yet — Monte Carlo simulation across a range of market conditions, so I can see not just “what’s the expected return” but “how bad could this realistically get, and how bad could it get in an unlucky sequence of years.” Longtime readers know I have a soft spot for that kind of analysis; I wrote about the same idea applied to a stock/bond portfolio a while back, and I think the same logic applies just as well to a single rental property.

That full underwriting step is the expensive one, in terms of both my time and the computer’s. Which is exactly why I don’t want to run it on every listing I glance at. The first two stages exist entirely to protect the third one.

Where This Actually Stands Right Now

I want to be honest about the state of things, because I think “in progress” is a more useful thing to model publicly than “finished.”

The ZIP scoring engine works, mostly, though I’m still finding edge cases — ZIP codes that straddle county lines are a special kind of headache I did not anticipate when I started this. The quick-kill screen exists but needs more real-world deals run through it before I trust its instincts. And the full underwriting stage is still mostly aspirational; right now it’s a folder full of half-finished code and a Monte Carlo module I keep meaning to properly hook up.

I’m also in the middle of moving the whole thing off my laptop and onto a little Linux box that lives in my house, partly because I like understanding my own tools end to end, and partly because I’d rather not depend on someone else’s server for something I’m going to trust with real buying decisions. That’s its own rabbit hole, and probably its own post.

None of this is a product yet. It might never be, in the sense of something anyone else uses. But it’s already changing how I think about the two properties I own, and it’s forcing me to write down assumptions I used to just carry around in my head, which is worth something on its own.

Why Bother

I could just keep doing this in a spreadsheet. Plenty of successful investors do exactly that, forever, and do fine.

But I like building things, and I like being forced to be explicit about my reasoning instead of trusting a gut feeling I can’t fully explain even to myself. If I’m going to make real decisions with real money — and eventually, real decisions on behalf of anyone else who ever looks over my shoulder — I want a process I can actually defend, one metric at a time, rather than a vibe.

I’ll keep sharing this as it develops, including the parts that don’t work, the ZIP codes that break my map projections at midnight, and whatever the quick-kill screen gets embarrassingly wrong the first few times I trust it. That feels more honest than waiting until it’s shiny.

A reminder that we’re not licensed financial or investment professionals — just sharing what we’ve learned and how we think about it as we build it. Talk to a qualified advisor before making decisions with real money on the line.

5 minute read

We’re kicking off a new, multi-part series here. We’re going to be looking at several different investment strategies using Monte Carlo Simulation techniques. Our goals with this series are to:

Demystify the Monte Carlo simulation technique.
Objectively evaluate the performance of different strategies against each other.
Learn.

I’m going to drop in our disclaimer right here just to make sure there is no confusion:

Disclaimer: While we have a passion for providing entertaining, informational, and possibly useful articles about personal finance, we’re just random people on the internet with no formal credentials or expertise. Talk to a licensed professional advisor if you need advice.

What Is A Monte Carlo Simulation?

Monte Carlo simulations attempt to show how a system responds through the use of repeated, random sampling of a model of that system. In observing how the system responds to a range of inputs, we can make better decisions in real life. We would like to see if we can learn about how well different investment strategies performed so we can make decisions about what to do in the future. Check out wikipedia and investopedia for some more detail on Monte Carlo Simulations.

While this post/series is not a comprehensive overview of the topic, a brief introduction is useful. Remember the “Normal” distribution from your first statistics class? If not that’s OK. My first statistics class was traumatic too. It represents a range of values/probabilities that we’re likely to see in many systems. Here is a distribution that represents the US Stock Market’s annual returns:

1000 samples of annual US stock market returns from a distribution with mean of TBD and standard deviation of TBD.

For Monte Carlo Simulation, the distribution is at the heart of everything. It is our representation of the system. The underlying distribution tells us how often we expect to see a given result. Finally, it is also fundamentally based on assuming that the general shape of the past can give us clues to how the future will look. How?

We iteratively and randomly sample points from the distribution. In our case, this provides a hypothetical sequence of returns for that asset class. If we’re simulating a 30 year retirement, we need 30 points from each asset. We’re using a distribution rather than actual historical sequences like cFireSIM. Therefore, we can simulate an infinite number of sequences. Let me be clear: that’s not a knock against cFireSIM. It’s actually one of my favorite tools and an inspiration for a lot of our work here.

What does a Monte Carlo Simulation Look Like?

Next, let’s look deeper at the first 5 points sampled from this type of distribution. We will illustrate how we can start to build up a sequence of returns. Remember, these 5 points are randomly drawn from the same distribution. Think of them as the first 5 years of a single “run” representing one potential retirement reality. Below, each panel shows a new point being randomly generated from the underlying distribution and added to the prior sequence.

Five successively chosen points from an underlying distribution.

Next, we can extend the sequence to 30 points (or any number) to represent a single retirement “run.” The next plot shows three such runs. Remember, we drew 3 sequences of 40 points from the same underlying distribution. And, the underlying distribution represents the annual performance of the US stock market. Therefore, you can think of this as three potential retirement experiences.

Three simulated “runs” of randomly generated sequences of returns.

When you make thousands of such multi-decade “runs”, you start to see the range of potential outcomes from this portfolio over time. And, that’s the foundation of our Monte Carlo simulation. We iteratively sample from the historical return data. We then simulate thousands of 20 year, 30 year, or 40 year (or more for those in the FIRE community) return sequences. Finally, let’s put the whole thing together and illustrate our 3 runs from above against a fuller population of simulation data.

In this plot, we simulated 1000 runs and then took the 10th to 90th percentile of those runs within a given year. We’re essentially eliminating some of the less likely returns from the summary. This reduced population forms the grey band in the graph. Overlaid on top of that are the three runs from above. Notice how many individual points are well outside of the grey bands. That’s important: any individual run can have some pretty extreme values (March of 2020, anyone?), but when you look at expected values they’re frequently less extreme. Are those extremes possible? Yes! But, they’re also less likely to occur.

Three 30 year simulated runs highlighted against the 10th -90th percentiles (grey band) of a 1000 run Monte Carlo Simulation

If you had two distributions, one that represents the annual performance of the US stock market, and another that represents the annual performance of the US bond market, you could start to build a model of their respective performance over time. From there, we can start to compare how well different portfolios perform…but we’ll dig into that another time. For now, let’s look at one caveat of many simulations: the shape of the underlying distribution(s).

Pitfalls of the Normal Distribution

In many systems, the normal distribution is a good fit for the underlying data. Stock market performance is not one of them. Here’s a great discussion on the topic. The key phrase is, “fat tails”. Over time, people observed that the stock market sees big movements more frequently than the normal distribution would suggest. This results in errors: differences in the model relative to historical performance. We would like our models to be as right as possible. I need to pause for the obligatory quote from legendary statistician and 20th century Renaissance Man, George Box:

“Essentially all models are wrong, but some are useful.”
George Box

Of course, we would like the models to be as right as possible, especially if we’re going to use them.

Metalogs – An Answer to the Normality Problem

Meta what?

“Metalogs”

They’re flexible distributions that more accurately reflect the underlying data than many of the classic distributions we’re used to (e.g., the Normal). Check them out here. They were invented by Tom Keelin who could be the 21st century’s Renaissance Man. By making distributions that can generate continuous samples from the underlying source data, Tom enabled us to reduce the bias in our original models. He helped us to fatten up our models’ tails when working with stock market return data (and his invention can be useful for modelling in any discipline. Have I sung his praises enough yet?).

Here’s a picture to help illustrate the differences between the actual data and two simulations. We can make 1802 annual return data points from Dr. Shiller’s dataset, called “Actuals” going forward. First, I calculated the mean/standard deviation of the Actuals and used those statistics to generate 1802 simulated returns using the Normal distribution. Then, I fit a Metalog to the original data (a 13-term metalog had the lowest standard error) and simulated 1802 more annual returns using a Metalog based on the actual data. Here’s a Box Plot (yes, the same George Box) showing how the three distributions compare.

Visually, you can see the Actual Returns and Metalog Simulation both have longer whiskers and more outliers than the Normal Simulation.

Wrap Up

That will do it for this first introduction to the topic of portfolio evaluation. It’s a fascinating problem. Inevitably, we will make mistakes along the way. I’m excited to dig into this topic and learn more about it. Hopefully, you have a better understanding of how we’re approaching this idea of portfolio evaluation. In subsequent posts, I will lay out some sample scenarios and start simulating!

Category: Advanced

Building the Thing I Wish I’d Had Before I Bought My First Rental