The number that started this
Okay, let’s unpack this. Because usually, when you think about the software you use every single day, you probably expect it to be built on a clean blueprint, like a perfectly organized file cabinet, right? Yeah, you want it to feel deliberate, like someone actually designed it that way from the ground up. Exactly.
You want an app to do something, you go to the settings menu, you flip a switch, and the software just obeys. If only it were that simple. Right, because then you peek behind the curtain of a massive, rapidly growing software platform, and suddenly you realize that pristine file cabinet is actually, well, it’s more like a house where the original builders kept adding secret rooms. And leaving random, unlabeled light switches in the hallways?
Yes, and then just wandering off to build another house entirely. Which is the absolute definition of technical debt. I mean, what you’re looking at isn’t a blueprint anymore, it’s an archeological dig. It’s every temporary decision the company ever made just layered on top of each other.
And welcome to the deep dive. Today we are looking at exactly that kind of architectural rescue mission. We’ve got our hands on a really fascinating internal strategy document from September, 2026 for a property management software company called PropFlow. Yeah, it details this massive high stakes project they call the settings cleanup strategy.
And our mission for you today is to explore how a company untangles this massive web of hidden settings, dead code, and just sprawling technical debt without breaking the live product that thousands of properties actually rely on. Which is incredibly difficult. I mean, this document isn’t just about cleaning up code, it’s a masterclass in how complex systems drift over time and the sheer amount of rigorous, almost painful discipline it takes to pull them back to reality. So before you can fix a broken system, you have to measure just how broken it actually is, right?
So let me hit you with the raw numbers from a code audit they did on September 9th. Ah, the famous 159 setting iceberg. The iceberg is so real. In all of PropFlow, there are exactly 159 things somebody can theoretically change or configure.
But if I’m a customer paying for the software, how many of those settings can I actually see on my screen? I love this part. 56. Just 56.
Which means you are locked out of nearly two thirds of the behavioral controls for the software you literally pay for. I couldn’t believe those numbers when I read them, I was aware of the rest of them hiding. Well, they’re buried. Yeah, like 73 of these settings require a software engineer to manually edit the backend database or run a custom script.
22 of them are hidden on an internal staff-only page. And 13 of them can only be changed when the company ships a brand new code release. It sounds chaotic, but if we look at how this happens to a successful company, you realize nobody actually sets out to build a labyrinth, you know? Right.
What happens is what engineers call the one-off safety feature trap. Okay, break that down for me. Why would an engineer intentionally hide a setting from a user in the first place? Fear, mostly.
Of those 159 settings,
Four problems wearing one number
55 are just simple on-off switches, and 44 of those are stored on a per building basis. So imagine an engineer wants to test a brand new feature, say a faster way to process a lease. Okay. They don’t want to break the whole platform if the code has a bug, so they build a hidden switch that only turns on for one specific property just to test it out safely.
I mean, that cell’s responsible. It’s a safety net. It is responsible in the moment, but then the new feature works. The property likes it, so the engineers move on to the next urgent fire they have to put out, right?
And they just leave the switch there. Exactly. Nobody ever goes back into the code to delete the switch and make that new feature the permanent default reality for everyone. The temporary scaffolding just becomes a permanent part of the building.
Fast forward a few years, and those abandoned per building switches just pile up to the point of completely paralyzing the system. Which creates an absolute onboarding nightmare for the people actually trying to use the software. The document highlights a real customer, Western Slope Property Management. Yep, that’s a great example.
They manage 82 different buildings. So if Western Slope wants to set a company-wide policy like establishing their standard renewal terms or their rules for apartment tours, they can’t just set it once for the whole company. Because of all this technical debt, those settings live strictly at the individual building level. So a human being literally has to sit at a desk and manually type the exact same answer 82 separate times just to configure their basic business rules.
That is just data entry with a deadline. It’s punishing your largest customers for being large. But as I read further, I realized it gets worse than tedious data entry. When settings are scattered like this, you get these hidden chains of fallbacks.
Yeah, this is where it actively starts hurting the business. Exactly. So PropFlow handles phone calls for these properties. There is a setting for what happens when a caller asks to speak to a real human.
But it’s not just one setting. It is controlled by five different fields
The hole that can lose a caller
spread across two different screens with a hidden chain of fallbacks. I tried to map this out and it’s chaotic. What happens if a building just leaves all five of those fields empty? Doesn’t the call just vanish?
Basically, yes. The software essentially shrugs. The system dials nothing. It leaves no record that anyone even asked for a human.
The call literally evaporates into the ether. And according to the internal document, that specific chaotic setup costs them a real customer. Wow. A dropped lead in property management is literally lost revenue.
And that’s just one example. You’ve got these follow-up case settings, which dictate how aggressively their AI texts a prospective renter. Those settings sit on an individual building page. But if you save them, the code secretly overwrites the settings for the entire company.
It’s a nut. Or you have properties like one called Yale 25 Station, which is running almost entirely on invisible code defaults because nobody ever bothered to configure it. Right, which brings us to the crucial pivot in this strategy document. They’ve measured the chaos.
Now, how do they build an architectural structure that prevents this from ever happening again? We have to move from the problem to the actual architectural theory. Enter the house model.
The house model
It’s an analogy to use in the doc. And I feel like it does a fantastic job of visualizing the solution. So imagine the entire software platform for one customer is a house. The overall company, Western Slope, in our example, is the front hall of that house.
Every individual building they own is a room branching off that front hall. OK, got it. And a setting in the software, like what are our office hours, that’s a code hook. And the actual value of that setting, the specific hours themselves, is the code hanging on the hook.
Exactly. The engineers propose a strict new logic called nearest hook wins. When the software needs to know a rule, it first walks into the specific room in the building. If there’s a coat on that hook, it wears it.
The local rule applies. But if that hook is empty, the software just walks out of the front hall at the company level and grabs the coat there, meaning Western Slope can just hang one coat in the front hall, and all 82 rooms can use it. They don’t have to type it 82 times anymore. Precisely.
And the company can choose to lock a setting. Basically, they nail the coat to the hook in the front hall, meaning no individual room is allowed to override it no matter what. I get the hierarchy. But it made me wonder about the platform itself.
What if there’s a rule that PropFlow wants to apply to every single customer they have? Is there a level above the company, like, I don’t know, a coat hook out in the street for the whole platform? See, that is a very dangerous temptation for software engineers. But the team addressed it head on.
There is deliberately no level above the company. Why limit yourself like that? If a rule applies to everyone, shouldn’t there be a master switch? Because if a rule applies to absolutely everyone, it shouldn’t be a setting at all.
It should just be a hard-coded, unchangeable law of the software. If you build a platform-wide settings tier, you are practically begging future engineers to start hiding their temporary switches up there again. You have to draw a hard boundary to stop the system from drifting back into a junk floor. Oh, that makes total sense.
You eliminate the space where the clutter accumulates in the first place. So armed with this house theory, they have to actually execute the cleanup. How do they deal with those 55 lingering on-off switches we talked about earlier?
The switch deep clean
They do a ruthless deep clean. Out of those 55 switches, they are straight up deleting 26 of them. Just ripping them out. But wait, if they are deleting settings, aren’t they taking choices away from the customer?
That’s the beauty of it. They aren’t real choices. The document notes that these 26 switches are a dedicated pure correctness. Pure correctness?
Yeah. For example, there was a switch that prevented the system from sending the same text message twice. Another switch stopped a user from booking an apartment tour in the past. So these were just bug fixes that got shipped as toggles.
Exactly. Nobody is consciously saying, yes, please give me the boogie version where people booked tours for yesterday. So those 26 get permanently deleted, and the bug fixes become the mandatory reality for everyone. Good riddance.
What are the remaining switches then? 12 of them stay, but they get converted into what are called dark switches at the company level. Dark meaning invisible to the user. Yes, invisible.
These govern unproven or risky new behaviors. Things like automatically converting a last lease into a month to month lease. That physically moves money, which is highly sensitive. So those switches stay dark, and they are assigned a specific named owner on the engineering team with a strict delete by date.
They acknowledge it’s temporary scaffolding, but they put an expiration date on it. Smart, which these 17 switches. Right, and these 17 cover the core business areas, leasing, renewals, maintenance, collections. Instead of having a messy on-off switch for every single building, they collapse them into a single three-state status per business area for the whole company.
The states are simply off drafts or live. Oh, wow. This is where the massive efficiency gain happens for Western Slope. Instead of flipping 17 different switches per building across 82 buildings, turning on their leasing is now one single decision at the company level.
One coat in the front hall. OK, so the theory is sound, and the cleanup is categorized. But you can’t just push a button and change the fundamental rules of a live software product. The document lists 15 specific behavior changes
Fifteen decisions on Fede’s desk
waiting for executive sign-off from someone named Fede. Won’t read the whole list, obviously, but looking at the themes, they’re essentially standardizing how this whole business operates. Yeah, they are systematically dismantling the chaos. Take communication, for example.
We talked about those vanishing phone calls earlier. Their proposal is to consolidate all those messy, redundant contact routing fields into one single source of truth. And they are changing the system so it universally alerts a company when a transfer call goes unanswered, right? Yes.
Which is wild, because currently, it seems only one single property, Camellia, gets those mistransfer alerts. Everyone else’s missed calls just vanish into a log. They are also standardizing the tenant experience universally. Right, like linking co-applicants into a single household everywhere.
Apparently, at that same Camellia property, if someone had a co-signer, the records just sat there, completely unlinked. Such a mess. They are also making the system automatically file a maintenance work order after a user requests a photo just once. Oh, and I love this one.
Allowing a spoken name correction on a phone call to automatically update the stored name across the entire platform. That’s a huge user experience win. Plus, one single company-level rule for tour notices, instead of a tangled web of same-day or weekday exceptions, and just one button to connect an email and calendar. Then you have the core property management logic, moving renewal terms to the company level.
Oh, this fixes our forgotten friend, Yale 25 Station, right? Exactly. It puts Yale 25 Station on the exact same renewal plumbing as Camellia and their other test properties, like the Willows, meaning the automated logic that generates a new lease is identical, safe, and compliant for everyone. They’re also making ignored properties a company-wide choice so all admins see the same portfolio, and moving those aggressive follow-up chase settings to the company page where they actually belong.
But I think my favorite decision is number 13 regarding incoming calls from unrecognized numbers. Oh, yeah. The old behavior was disastrous. If the system didn’t recognize a number, it might misroute it and answer with a completely different company’s greeting.
Hi, thanks for calling building A when you meant to call building B. So embarrassing. The new rule is to just refuse the call. Fail loudly rather than pretending to be the wrong building.
Absolutely. And finally, to round out the 15, they are deleting six completely dead settings that nothing in the code even reads anymore, like legacy brand colors or handyman pointers. And they are keeping five unfinished behaviors as those company-level dark switches we mentioned. So they’re recommending a yes on all 15 of these massive changes.
But changing the behavior of live software seems incredibly dangerous. How do they convince an executive like Fede to sign off on this? Well, by proving they have a non-negotiable safety net, what’s fascinating here is the engineering team isn’t acting recklessly. Every single change follows a strict three-step protocol.
Correctness fixes, not customer choices
First, the change ships dark to production, meaning the code is live, but totally inactive for real users. Second, it is tested exclusively at their internal testing property, the Willows. And third, it only ever reaches a real customer after it passes those tests and gets Fede’s explicit final go-ahead. Three separate steps, always.
But having a safety net is one thing. Actually, executing this transition across thousands of users without interrupting their day-to-day work is another.
The five-phase rollout
The document lays out a five-phase rollout. Right. So phase zero is the deep clean. This is where they delete those 26 bug fixes and the six dead settings.
But the most important part of phase zero isn’t what they delete. It’s what they build, the ship-a-switch registry. This tracks every single active switch, who owns it and when it expires. And they tie this registry to an automated build check.
I found this brilliant. If a rogue developer tries to sneak a new unregistered switch into the code, the system literally breaks the build. It refuses to compile. They stop the bleeding at the source.
But phase one, which was scheduled for mid-October, is where the real genius of this rollout shines. The goal here is to declare what an empty hook means for every surviving setting. Yes. Here’s where it gets really interesting.
When I read this, I had this massive aha moment. Usually when software companies overhaul their architecture, they have a migration weekend, the site goes down for maintenance, and they try to port millions of rows of data from the old system to the new one, and things always break. Oh, yeah. Data migrations are where data goes to die.
Right. PropFlow avoids it entirely. They engineer an empty hook to mean exactly what the production product does today. So a building with absolutely nothing configured will behave identically to how it did yesterday.
The defaults are just set to reality. There’s literally no data migration needed. It’s so clean, they even prove it’s safe by replaying real historical traffic from the Camellia property through the new system in a simulation, just to ensure the output is 100% identical. Amazing.
Then in phase two, they actually build the new company level screens one setting at a time, starting with who answers a call, and they add a tab for those specific building overrides. By phase three, which goes from mid-November into December, Western Slope finally gets to go live using just a single company-wide switch. And phase four is the final lockdown. They lock the values that must never vary across the platform and permanently rip out the code for the deleted fields for good so no one can ever resurrect them.
It’s an incredibly elegant plan. But as we know, you can’t just drop a master plan onto an existing architecture without stepping on some toes. The final piece of this puzzle is how this grand setting strategy
Where this bumps into Gera’s design
folds into an existing design created by a colleague named Gera. Right. You have to integrate with Gera’s existing model rather than just bulldozing around it. There were two specific conflicts they had to resolve.
Right. So conflict eight was about routing those phone calls. Gera’s architectural model required four separate settings, an office line, a transfer destination, an escalation owner, and who gets copied. But this new cleanup plan, as we discussed, only wants one single setting.
So they compromise. They keep the life safety emergency number completely separate, which is smart. You don’t mess with emergencies. They keep the public office number solely for what the AI, Clara, reads aloud to callers.
But for the actual plumbing of routing the call, they consolidate that into one unified setting. Got it. But conflict B is the trickier one. And it brings us back to something we touched on earlier, platform wide settings.
The new plan requires these master kill switches, essentially emergency breaks that can halt all text messages, stop all renewals, or freeze all collections across the entire platform. Right. If an email provider or a carrier suddenly blocks their texts, they need a master off switch for the whole system. But remember, Gera’s model strictly dictates there is no level above the company, no hook out in the street.
And the engineering team agreed with that rule. So how do they square that circle? How do you have a platform wide switch without a platform wide settings tier? By understanding that words matter in software engineering, the resolution is that these master breaks are not settings.
They are operational breaks that live on an entirely separate internal engineering page. They deliberately strip the word setting away from them. Because if you call it a setting, some future engineer will inevitably try to invent a whole new platform wide settings tier just to accommodate it. And the junk tour returns.
By explicitly naming them operational breaks, nobody has tempted to reinvent a tier for them later. They protect the integrity of the house model. That is just brilliant defensive engineering. OK, we have covered a massive amount of ground here today.
From the chaos of 159 scattered switches to a beautifully structured house model, 15 major business logic shifts, and a flawless five phase rollout. If you had to boil this entire massive September strategy document down to its absolute core takeaway, what is the one sentence summary? The mandated summary is this. Every setting gets one home, one screen, and a default equal to what the product does today.
The pile of per building switches gets deleted rather than moved. So switching Western slope on becomes one decision instead of 17 per building. Wow. So what does this all mean for you listening right now?
Why did we just spend this deep dive geeking out over an internal property management software document? Because the underlying lesson here applies to everything. Whether you are managing complex software, running a business process, or honestly just organizing your own digital life and your inbox, technical debt grows silently. Every time we implement a temporary fix or a work around because we’re in a hurry and then we just leave it behind, we are adding a secret switch to the hallway.
And eventually you end up living in a house where you don’t even know what the light switches do anymore. And a simple task takes 82 manual clicks. Exactly. It requires aggressive principled pruning to keep any system functional.
So I want to leave you with a final thought to mull over today as you go back to your own projects. Look at the tools, the apps, or the daily routines you rely on. Ask yourself how many of your daily workflows are just empty hooks running blindly on someone else’s unexamined defaults from three years ago. It might be time for your own phase zero deep clean.
Couldn’t agree more. Thank you for joining us for this deep dive. We’ll catch you next time.