The save that wipes out four hundred businesses
Imagine hitting save on this, uh, this really simple root ton software update. Right. To the tiny tweak. Exactly. Like maybe you are just trying to change the late fee policy for a few apartment buildings and instantly you wipe out the legal compliance settings for 400 different real estate businesses. Oh man. Which is a nightmare. A total nightmare. And not because you typed the wrong number, but because the foundational code of your software, it literally could not tell the difference between a brand identity and a physical brick and mortar building. Yeah. It's a type of invisible catastrophe that happens way more often than people think.
So today we are taking a deep dive into a confidential internal design document that reveals exactly how elite engineering teams prevent that kind of disaster. It is such a phenomenal look under the hood. I mean, what we have here is basically a master class in software architecture. Yeah. And it's captured at the exact moment a development team is staring down this massive complex new client. Right. They're at a total crossroads. Exactly. They have to make a critical multi-tenancy model decision. And, you know, just to define that briefly for you, if you aren't living in the engineering world every day, please do multi-tenancy is basically how a single instance of software serves hundreds or thousands of distinct corporate customers.
What multi-tenancy actually is
Right. So it's keeping all their data completely isolated and secure, but they're all still running on the same underlying code. I am so glad we are digging into this because, I mean, reading through these documents felt less like a technical manual and more like a, well, like a high stakes thriller. It really does read like one. It's a gripping mystery about avoiding a multi-million dollar mistake. And our mission today isn't just to talk about code in a vacuum, you know? Right. Nobody wants just a dry coding lecture. Exactly. The goal is to understand how you model real world chaos, the messy, overlapping, totally contradictory reality of how human beings actually run businesses.
Yeah. And how you put that into a digital system without burying yourself in massive technical debt. Because the stakes outlined in this document are, they're incredibly unforgiving. Oh, totally. A software platform only gets one, maybe two chances to decide the shape of its tendency model while it is still cheap to do so. Right. Before the cement dries. Exactly. Once you make that architectural decision and your customers start pouring their actual day-to-day business data into that structure, it sits like concrete. Yeah. And after that point, if you realize you built the wrong boxes.
It's game over. I mean, every structural change you want to make isn't just a quick update anymore. It is a full blown migration. Which is terrifying. It is. And the blast radius of a migration is measured in the disruption of other people's real world businesses. So to understand the puzzle they are trying to solve here, we need to quickly set up the sandbox they are playing in. Right. The property management domain. Yes. If you are building software for this specific industry, you are dealing with a few core concepts that sounds simple, but they get complicated fast.
Properties, organizations, and the question in the middle
You have properties, which are the physical buildings, right? The actual units with doors and windows. Yep. Then you have organizations, which are the management companies running the day-to-day operations. You have the owners, which are usually entirely separate LLCs holding the actual legal title to the building. Right. The money behind it. Exactly. And then layered on top of all that, you have consumer facing brands and geographic regions. And the fundamental challenge this architecture needs to resolve, and it has to do this thousands of times a second seamlessly, is a deceptively simple question.
What's the question? Exactly. Which configurations, rules, and policies apply to this specific building at this exact moment? Which sounds easy until you think about the scale. Exactly. Think about it. If a resident sends a text message to their management company at 8 p.m. on a Sunday, the system needs to instantly know, like, who gets the notification? Right. What is the after-hours emergency protocol? What specific AI persona and language should be used to reply? Are there local jurisdiction laws about texting hours? It's a massive decision tree. Which brings us to the villain of our story, or, well, maybe the hero, depending on how you look at it.
The forcing function: one incoming client
I like to think of them as the forcing function. Yeah. That's what the document calls it. A forcing function. It's an incoming client called the Situs Group, led by a guy named Hugo Weinberger. Right. And Situs Group is fascinating because they break absolutely every comfortable assumption the software platform currently holds about how a business should be shaped. They are the ultimate stress test. Oh, completely. To see why, we have to look at the shape of their portfolio. So Situs Group manages roughly a thousand units in total. Okay. In the Denver metro area, they have 434 units. But those aren't in one big, easily manageable skyscraper.
That would be too easy. Way too easy. They are spread across 21 different distinct named buildings, plus about 15 scattered single-family homes. Okay, so a decent chunk of Denver real estate. Right. Then you drive three hours away into the mountains to Grand Junction, and they have another 270 or so doors. And if you are an engineer, this is the part of the document where your blood pressure starts to spike. Oh, yeah. Because that Grand Junction portfolio, it runs under a completely different consumer-facing brand name. Yep. It is called Western Slope Real Estate and Property Management.
Twenty-one buildings, no leasing offices
But wait, it gets messier. Legally, all of these properties, both the Situs ones in Denver, and the Western Slope ones in Grand Junction, they are held across 14 or more entirely separate, single-purpose venture LLCs. It's a legal spiderweb. It really is. So you have multiple brands, multiple geographic regions, and highly fragmented legal ownership. Yet, operationally, they act as an incredibly tight, consolidated machine. Which is the crazy part. Right. They manage this entire fragmented empire with just one central team of about 12 people. Wow. They use one primary phone number, 303-789-3030 for almost everything.
And they have zero physical leasing offices anywhere. I mean, if I try to put myself in the shoes of the developer looking at this onboarding form. It's a nightmare. It's a total nightmare. Standard software logic wants neat little boxes. It wants a hierarchy. Yes. But Situs Group operates as a totally unified portfolio on the phones and in the back office while legally, geographically, and brand-wise, they are entirely fragmented. They are basically forcing the software to ask a philosophical question like, are you a single unified company or are you 40 different independent little companies?
One company or several? Both, simultaneously
Right. And the reality of modern real estate is that they are both simultaneously. They need the efficiency of a single company, but the legal and branding separation of 40 different ones. Let me stop you there though, because when I first read about this, my immediate thought was, why are we overcomplicating this? Because that's the natural instinct. Right. If I'm an engineer, my first instinct is just to draw a box around the Denver buildings, draw another box around the Grand Junction buildings and call it a day. Right now, according to the document, the software platform has two levels, organization at the very top and property at the very bottom.
The obvious fix: add a folder
Just those two. So the most obvious move in the world is to just add a third tier right in the middle, like a region folder or a brand folder. It feels like trying to organize a messy closet by just going to the store and buying bigger plastic bins. And that right there is what the document calls the trap of the obvious. Okay. It is so seductive because engineers intuitively reach for this model. It looks clean and it matches the mental model we all use every single day, which is nesting folders on a computer desktop.
Right, like double clicking into a folder. Exactly. You create the overarching Situs group folder, you click into it and you create a Denver folder and a Grand Junction folder. You double click Grand Junction and you drop the specific buildings inside. It feels beautifully organized. But the architecture document basically waves a massive red flag here. It explains exactly why that desktop folder instinct is a disastrous way to model a business. Yeah, it completely falls apart. And it all comes down to how these groupings actually relate to each other in the real world outside the computer screen.
Why groupings do not nest
Right. Because groupings above a physical building are plural and they are overlapping. They simply do not nest neatly into one another. Give me an example of that. Sure. Think about Situs group's 21 Denver buildings. You could partition them by brand. You could partition them by the LLC that holds the title. You could partition them by the specific metro sub-region. Okay. These partitions cut straight across each other. I see. Because a containment trick, like a computer folder structure, it can only cleanly represent one parent relationship. Exactly one. So if you choose brand as your middle folder, where do you put the legal ownership?
A single brand might span three different LLCs. Right. Or on the flip side, if you make ownership the folder, the brand has nowhere to live. Because one LLC might contain buildings that operate under two completely different consumer brands. Yes. If you force an overlapping reality into a strict tree structure, something has to break. The document calls out a very specific dangerous illusion here, which they termed the diagonal trap. The diagonal trap. Yeah. In the case of Situs group, two of these overlapping axes happen to co-vary perfectly. Oh, I see where this is going.
Right. The second region they operate in Grand Junction is also their second brand, Western Slope PM. Oh, man. So it's a total coincidence of their current business model that makes a bad architectural idea look like a brilliant one. It is incredibly dangerous. An engineer looks at that data and says, great, region and brand are basically the exact same thing for this customer. Let's just fuse them into a single portfolio tier in the database. And they high five and go to lunch. Exactly. But fusing them, just because the very first example lines up perfectly, is how you guarantee a massive, painful, expensive migration down the line.
The next customer breaks the folder anyway
Why? Because I promise you, the very next customer who walks through the door next month is going to have one brand spread across three regions. Or two completely different brands sharing one central leasing desk in a single region. And if you hard coded that feud portfolio folder structure into the bedrock of your software. It breaks. Your system literally cannot comprehend that next customer. You have to tell the sales team, sorry, we can't sign them. Our software doesn't understand their business. What is fascinating here is the intellectual rigor of the authors.
What the rest of the industry already learned
They didn't just rely on theory. They looked outward at the broader industry for validation. They noted that the entire property management software industry, I'm talking about the massive, multi-billion dollar legacy systems that have been around for decades. They have independently declined to build a containment tier between the company and the property. Really? All of them. Every single major player uses many to many customer defined tags instead of folders. And the authors write this beautiful sentence in the doc. When an entire industry independently declines to build the obvious thing, that is evidence, not coincidence.
It's such a great observation. Those legacy companies all tried the folder structure in the 90s and 2000s, and they all realize that a rigid hierarchy shatters when faced with the chaotic, overlapping realities of real estate. I do want to push back on that, though, because as a user, tags are incredibly messy. They can be, yeah. Let's say I have a building, and it has three different tags attached to it. Say it has a Denver tag, a luxury tag, and a corporate owned tag. Okay. If the Denver tag says the late fee is $50, but the luxury tag says the late fee is $100, who breaks the tie?
Tags instead of a chain of command
Right. A folder structure, for all its faults, implies a clear chain of command. The parent folder dictates the rules to the child folder. Tags just sit there in an unstructured pile. How does the software know what to do? You are hitting on the exact reason developers hate tags for configuration. Settings resolution requires ordering. The machine needs a definitive answer. It can't just guess. Right, so the team's elegant solution to the tag problem is to introduce explicit numeric precedence on the groups themselves. You literally assign a rank to the tags. Okay, so tag A outranks tag B.
Ties, and the red box
Exactly. But the truly crucial part is how they handle ties. Let's say a regional manager accidentally sets both the Denver group and the luxury group to the exact same precedence level, and they try to set conflicting late fees. Uh-oh. The system refuses the tie at right time. Wait, right time. Meaning when the human being is actually sitting at their keyboard trying to save the form? Exactly. Imagine you are that regional manager. You type in $100 for the late fee on the luxury tag, and you hit save. Instead of accepting it, the screen shakes.
Wow. A red box pops up and says, conflict detected. The Denver tag and the luxury tag have equal precedence and conflicting rules. You must specify which one is more important before you can save this setting. That's brilliant. It literally stops you from doing your job until you make a business decision. That is so much better than what most software does, which is just silently accept the input and guess. Most systems resolve ties implicitly. They might apply the rule from whichever tag was created first in the database or whichever one comes first alphabetically.
An implicit tie-break is a bug that reports success
Which is terrifying for financial rules. The document explicitly calls this out, stating, an implicit tie break is a bug that reports success. Oh, that's a great line. You never want the software quietly making a financial or legal business decision on your behalf and pretending everything is fine. You want it to throw an error in your face and force a human to decide. Okay, I am sold on the tags over folders. But if we can't use a neat hierarchy, how do we handle the fundamental branding problem? Situs Group still has these two completely different consumer-facing brands.
Right, Situs and Western Slope. And right now, in the existing software, brand is just free text typed into a notes field in the building's profile. Yeah. But this platform uses a voice AI agent that literally speaks that brand name allowed to prospective renters on the phone. Yes. It needs to know whether to say, hi, you've reached Situs Group, or hi, you've reached Western Slope. We have to give the rejected alternatives a fair hearing here, because the document spends significant time on them. They didn't just ignore other options. No, they didn't.
The two-organizations model, and why it fails
And the most attractive, seemingly simple alternative to solve the branding issue is the two organizations model. I'll admit, this is what I would have done. It sounds incredibly straightforward. Just create one totally separate organization account in the software for the Denver properties, and another completely separate account for the Grand Junction properties. Seems easy. Clean separation, two distinct billing accounts, two completely distinct AI greetings. Problem solved, right? It looks immensely attractive until you hit the brick wall of identity. Identity. Yeah. In this platform, and in most modern enterprise software, a person's identity, their phone number, email, application history, is scoped strictly to the organization level by design.
Oh, I see. It is a hard impenetrable boundary to ensure data privacy between completely different management companies. Which is how it should be. If I apply for an apartment in New York with Management Company A, Management Company B in Chicago shouldn't be able to just casually search my name and see my social security number and credit score. Exactly. The wall is there for a reason. But if you split Situs Group into two completely separate organizational accounts just to solve a branding problem, look at the real world consequence. Okay. Imagine a resident who currently rents an apartment in Denver under the Situs brand.
The tenant who moves to the mountains
They decide they want to move to the mountains, so they inquire about a property in Grand Junction under the Western Slope brand. Oh, no. Because those are two different organizations in the database. That resident would be recorded as two entirely different human beings. Oh, this is giving me flashbacks as a consumer. This is exactly why you can unsubscribe from a major retailer's promotional emails, but their sister brand keeps emailing you every day. Yes. The software fundamentally believes you are two different people. Yes. And in the highly regulated world of property management, that is a legal nightmare.
Opt-out, and the compliance breach hiding in a greeting
Oh, because of text messages. Right. If a tenant in Denver texts the word S-TESOP to opt out of automated messages, federal TCPA compliance laws dictate that they must be opted out across the entire portfolio. Every single text sent after a start-up request can carry a massive fine. But the two organizations model would sever that identity connection. So they opt out in Denver. And they successfully opt out there, but they would still be spammed by the Grand Junction account. That's a massive lawsuit waiting to happen. The document notes that a unified identity is the single property this specific client needs most.
The answer: presentation without a boundary
And the two org model destroys it entirely just to gain a customized phone greeting. So what was the actual solution? If you can't use a folder and you can't use two separate accounts, I mean, how do you give them two brands? The chosen solution is profound in its simplicity. The Etrique brand is a first-class entity that is owned by the overarching company but referenced by the building. Okay, unpack that for me. It is not a container that holds buildings. A brand is an object that can own specific things. A simple text label cannot.
It can own a specific sending domain for emails, a unique logo file, a specific AI voice persona, a custom message footer. But because it doesn't try to contain the building structurally, it can compose beautifully with all those other overlapping axes, like ownership LLCs, instead of competing with them. Let me make sure I have this right. It's like the difference between painting a car red versus putting the car inside a red garage. Exactly. If you put it in a red garage, it can't also be in the blue garage. But if you just apply a red attribute to the car itself, it can drive into whatever garage it wants.
That is a perfect analogy. By avoiding the trap of blindly adding new structural containers to solve every problem, the engineering team uncovered the true hidden cost of their existing architecture. Yeah. And this leads us to what I consider the single most crucial aha insight in the entire design document. This was the epiphany that reorganized their whole effort. The realization that the actual number of hierarchy levels, whether they had two tiers or three tiers, was never fundamentally the problem at all. Right. The document points out that the actual expensive mistake in their system was that resolution, the underlying logic in the code asking what rule applies to this specific building right now, was handwritten separately for every single feature in the platform.
Depth written into the code, in n places
I want to break down exactly what that means in practice, because this is where a lot of non-engineers get lost. Let's do it. Let's say the software has a hundred different features. You have rules for calling maintenance vendors, rules for how to handle lease renewal, rules for booking a physical tour, rules for calculating late fees. Right. In their old system, if you wanted the software to know the late fee, a developer had written a specific piece of code that essentially said, first, check the building. If the building's late fee is blank, check the company.
But then, completely separately, over in the maintenance vendor code, a different developer had written, first, check the company, then check the building. Exactly. You have bespoke customized logic scattered everywhere. So, if you have n number of resolvers, n being dozens or hundreds of these custom written rules, and the business decides they suddenly need to add a new tier, like region. You don't just add a tier, you have to rewrite n resolvers. It's awful. You have to open up hundreds of pieces of fragile code, find the specific lines where it checks the rules, and manually inject the region check into the middle.
Debating the direction of inheritance, n times
And it is so much worse than just injecting code. You have to debate the direction of inheritance n times. Oh, true. For the late fee, does the region override the company? What about for the maintenance vendors? Does the building override the region? You are having the same architectural debate hundreds of times across different teams. It is like having a factory with 100 custom built conveyor belts. Yeah. If management decides to add a new inspection room to the factory, you can't just drop the room in. You have to tear up and rebuild every single conveyor belt to route through the new room.
And that right there is the exact mechanism of massive recurring technical debt. Every time the real world business changes its shape, the engineering team has to perform a massive, risky, open heart surgery on the code base. So their real insight, the sentence they highlight in the document, and the mantra for this whole redesign is don't add a tier by the fold. By the fold. It is a brilliant concept borrowed from functional programming. Okay. What does that mean in normal English? Folding resolution means you completely centralize the logic for how settings are applied across the entire system.
One mechanism instead of hundreds
Instead of hundreds of custom conveyor belts, you build one universal mechanism. A smart pneumatic tube system for the whole factory. Yes. You declare every configurable key, whether it's late fee amount, emergency contact, or AI greeting just once in the central registry. Just once. And determining the value of that setting becomes a single universal mathematical operation. You give the system an ordered chain of context formulated as a list. Say company, region, brand, building. Okay. A simple array. Right. The central folding mechanism walks down that list step by step, folds the values together according to universal predetermined rules, and clamps the final result against legal compliance.
Walking the fold
Okay. Let's walk through that step by step so I can really visualize it. Let's use the late fee example again. Okay. The central system asks, what is the late fee for building A? The system looks at the list. Company, region, brand, building. It starts at the top. The company policy says $50. Right. It moves to the region. The region says $60. It moves to the brand. The brand left it blank. It moves to the building. The building says $75. The fold mechanism takes all those inputs, applies the rule of who wins, and spits out the final number.
When depth becomes data
Precisely. And here is the absolute magic trick of this architecture. When depth becomes data, when your hierarchy is just a list of words passed into the system rather than hard-coded into the structural architecture of the code. Adding a new level later stops being a migration. Yes. That's the beauty of it. If, two years from now, a massive new customer needs a subregion tier between region and brand, the engineers do not have to rewrite 100 resolvers. You don't have to touch the feature code at all. Not at all. They just add subregion as an extra element in the list.
The list becomes company, region, subregion, brand, building. Wow. The central folding mechanism just sees a list with five items instead of four and handles it automatically. The architecture absorbs new relationships without breaking a sweat. It fundamentally transforms what used to be a terrifying engineering problem into a simple data entry task. Exactly. But a universal system like that needs incredibly rigorous universal rules. If we are folding all these rules together, traversing down from the company to the region to the building, who actually wins when there is a conflict? Yeah, that's the hard part.
Who wins: company or building?
In my late fee example, if the company says $50 but the building says $75, who wins? This was a major point of contention within the company and the document details the internal fight. Oh, I bet. The team faced two existing written rulings from leadership that seemed completely contradictory. One ruling explicitly said, the overarching portfolio always wins conflicts to maintain brand standards. OK. Another ruling explicitly said, the company sets the defaults, but the local building always overrides them to accommodate local market conditions. I feel like in most software meetings, the loudest person in the room just forces a decision.
Pick a winner, mandate it, and move on. But the engineers realized that picking a blanket winner is the wrong instinct. They recognized a profound truth. Precedence isn't a property of the tier. What do you mean? It's not about whether the company generally beats the building. Precedence is a property of the key itself. Ah, so it depends entirely on what specific setting we are talking about. Precisely. You cannot treat a fair housing law the same way you treat a pet fee. Right. They establish four distinct classes of keys. And every single setting in the software must be categorized into one of them.
Class one: policy, where the company is authoritative
Let's go through them. The first class is policy. This is where the company is strictly authoritative. Think about fair housing language, data retention rules, or legal disclosures. Things that get you sued. Exactly. Yeah. A local building manager cannot decide to just opt out of fair housing laws because they feel like it. And the document notes this must be enforced by right time refusal. Yes. The system literally will not render a text box for the building manager to type a different rule into. It just grays it out. Yes. Or it doesn't show it at all.
Because if you allow them to type it in, but you silently override it behind the scenes with the company policy, you create a massive liability. Yeah. The user thinks their local rule is active, but it isn't. The company wins because there is nothing allowed to beat it. Okay. That makes total sense for legal stuff. The second class is parameter. And this is where the building wins. Correct. Parameters are operational things like rent concessions, monthly parking fees, or specific AI follow-up schedules. Local context matters most here. A building in downtown San Francisco has entirely different parking constraints than a suburban complex in Ohio.
Class two: the value that replaces rather than merges
And crucially, when the building provides a value, it replaces the company's value. It doesn't try to merge with it. Oh, why is that important? If the company has a complex list of five default fees, and the building provides a list of two local fees, the system uses the two local fees. If you try to write software that merges two complex lists, you end up with a hybrid monster of seven fees that no human actually authored or intended. Right. It just becomes a mess. The third class is identity. And this one really caught my attention.
Class three: identity, and the link that texted the wrong building
Identity applies to the building only. And the rule is that it is never inherited from the tears above it. The document cites a real, highly embarrassing incident that birthed this strict rule. Let's hear it. They had a new property go live on the platform, but the onboarding team forgot to fill in the building's specific rental application link. Okay. Because the old system was designed to be helpful. It couldn't find a link for the building. So it looked up the chain and inherited the application link from the parent company. Let me guess.
The parent company's link pointing to their flagship luxury property, not the new building. Exactly. The AI agents started enthusiastically texting hundreds of prospective renters for a mid-tier apartment complex, giving them application links to a luxury high-rise across town. Ouch. Yeah. Inheriting an identity value, like a specific property email address, a physical phone number, or a link to a specific building's management portal is not a helpful default. No, it's terrible. As the authors wrote, it is a false statement about the building. It is vastly better for the system to break and say, I don't have a link than to confidently send a prospective renter to the wrong property.
Class four: the compliance floor as a clamp
And finally, the fourth class, compliance floor. These are jurisdiction caps applied at the very end of the fold as a clamp. Not the overarching company, not the local building manager can overnight the law. If the state of Texas says you cannot text a resident after 8 p.m., the system clamps any setting that tries to push it to 9 p.m. And by rigorously classifying every setting into one of these four buckets, the contradiction between those two internal rulings completely dissolved. Oh, because they were both right. Exactly. Both rulings were true. They just applied to different types of keys.
Exceptions, and the golden rule
But this brings up a huge, messy operational reality. What happens when a building genuinely needs an exception to a strict company policy? It happens all the time. Right. And the natural instinct for any software designer, and I know this because I ask for it all the time, is to just add a little override checkbox. Just put a flag in the database that says, allow local value just for this specific case. And here we arrive at one of the most critical takeaways for you, the listener, whether you build software or manage a team.
This is huge. The golden rule from this document. An exception is a record, not a hole in the rule. I love that phrasing. An exception is a record, not a hole in the rule. Why is a simple override flag a little checkbox so dangerous in the long run? Because an exception that is just a true false checkbox becomes entirely invisible the day after it is granted. Fast forward two years. You have a database filled with hundreds of checkboxes, allowing exceptions to core company policies. The person who checked them left the company a year ago.
Why nobody can say which buildings are exempt
Nobody knows what they mean. Exactly. Nobody can tell you which buildings are exempt from what policy or why the exemption was granted in the first place or who authorized it. You have lost control of your business logic. It is exactly like a bouncer letting someone into an exclusive VIP club with a silent nod. By year two, the club is full of random people and the management has no idea why half of them are in there. That's a great way to put it. But an exception is a record that is like issuing a physical guest pass.
It has an expiration date printed on it, a stated reason for entry, and the manager's actual signature. The engineering team explicitly modeled this after Azure Cloud Infrastructure. In Azure, a policy exemption isn't a flag. It is a first-class object in the database. Okay. And carries who approved it, why they approved it, and crucially, when it expires. When it expires. I love that. Right. When you pair that record with a nightly automated report sent to executives showing every active override and its age, you solve the real fear those executives have. Because they can see it.
The fear was organisational, not technical
Exactly. When leadership was arguing about who wins in a software precedence dispute, their fear wasn't really about software. Their fear was organizational. That one unified portfolio-wide policy would slowly, quietly rot into 40 independent, untrackable, local overrides without anyone noticing. Wow. Okay, so this rigorous classification of keys and exceptions fixes how internal settings and policies apply. But what happens when the very data coming into the system from the outside world is fundamentally misaligned with reality? Oh, this is the phone number problem. Yes. Because Situs Group brought them a problem that forced a complete rethink of how communication routing actually works.
One phone number, forty buildings
But this revolves around that famous single phone number we mentioned earlier. 303-789-3030. One single phone number serving 40 different physical buildings. Right. And the software system currently operates on a seemingly logical airtight premise. When a text or call comes in, the software looks at the phone number the person dialed, maps that phone number to a specific building in the database, and then it derives the management company from that building. That's the standard model. But when one number maps to 40 buildings, the system just collapses. It doesn't know which building to pick.
Weeks spent looking for a bug that was a modelling error
The document points out how engineers were struggling with this for weeks. Everyone kept looking for missing configuration. They thought it was a bug. Right. They kept trying to figure out how to fill in a missing row in the database to make the routing work. Maybe we can route it by area code. Maybe we can route it by the AI guessing based on the text content. Just grasping at straws. But the lead architect steps in and says, this isn't a missing row. It is a fundamental type error. A type error. Meaning the fundamental shape of the reality doesn't fit the digital container we built for it.
Right. A database mapping from one phone number to one building simply cannot represent a reality where one number serves 40 buildings. It's mathematically impossible. Exactly. No amount of data entry. No amount of clever database patching. No amount of AI guessing will fix that. The resolution error was pointing the wrong way. Exactly. The system was demanding to know which building is this first. But caller ID only gives you the phone number they dialed. And that number only tells you the company with absolute certainty. Right. It says Situs Group. It tells you Situs Group.
How people actually answer the phone
It tells you absolutely nothing about the building. Here is where it gets really interesting though. Because this is how human beings actually work. Yeah. If I call a central desk for a massive property management company, the human receptionist doesn't freeze and crash because they don't know what building I want. The very first thing they ask is which community are you calling about today? Exactly. The human is comfortable not knowing yet, but the software wasn't allowed to not know. The legacy architecture rigidly required the building to be known before a conversation could even be instantiated in the database.
If a caller didn't specify a building immediately, the code literally threw a fatal error and couldn't even say the lead's phone number. So they just lost the business. Lost it entirely. The solution was to reverse the error, resolve the company from the phone number, instantiate the conversation at the overarching company level, and treat the specific building as an attribute that the conversation discovers over time. It sounds so obvious in retrospect. Let the AI ask the user what building they want, just like a human would. It does sound obvious, but architecturally, it is profound.
Holding ambiguity as a state
Forcing a rigid system to acknowledge what it doesn't know and allowing it to hold that ambiguity gracefully as a modeled conversation state rather than treating it as a routing failure is a massive paradigm shift. Yeah, that takes a lot of restructuring. And the document notes that waiting to fix this is the most expensive mistake they could possibly make. Every new feature added to the platform maintenance requests, lease renewals, hardens that false assumption that the building is known at and just deeper into the code. Which brings us to a massive cross-cutting principle, a philosophy that applies not just to property management software, but really to all software engineering, and honestly, to business operations in general.
Absence is not neutral
And this is our second key takeaway for you, the listener. Absence is not neutral. Absence is not neutral. What does that mean in the context of this system? Historically, in this specific platform, leaving a configuration setting blank meant the building was considered fully live but malfunctioning. Okay. The system assumed that if nothing was configured, it should just try its best to keep going and guess what the user wanted. It treated a blank space as a neutral, proceed with caution signal. Which sounds resilient. You want software that doesn't crash every time a user forgets to check a box.
What the real incidents looked like
But the real world incidents they cite in the document are terrifying. They are completely unacceptable. The document notes leave the escalation recipient unsaid, meaning nobody typed in the phone number of the after hours maintenance guy and emergency notifications reach literally nobody. Because the software just shrugs. Right. They fail silently, deliberately, with no alert to the management company, or leave the time zone unsaid. And the system silently defaults to central time because that's what the servers are. Oh, I read about this, the 7am text incident. Yes. They explicitly mentioned the 7am text incident where outbound automated messages were being fired off an hour before the legal operating floor because the system just guessed the time zone based on the server location.
When you only have four properties on your startup's platform, maybe you can get away with that helpful guessing. A human account manager notices the weird behavior within a day and fixes the settings manually. But at 40 properties. At 400 properties. At 4,000. You can't manually check that. No. The default outcome of absence at scale is catastrophic failure. They had a precedent where a building went live with only 27 configured attributes, while a comparable healthy building had 61. Wow. Its emergency forwards reached nobody. Its late fees were calculating wrong. But on every executive dashboard, that building looked perfectly fine.
Nothing configured is not everything is fine
It was a green dot across the board because it hadn't technically crashed. A modern system cannot assume nothing configured means everything is fine. It's like, imagine you tell a highly advanced robot to bake a cake, and you hand it an instruction form, but you accidentally leave the oven temperature field blank. Okay, yeah. A blank space isn't a no. It is an, I don't know. The robot shouldn't just guess 500 degrees and burn the house down, and it certainly shouldn't set the oven to zero and stare blankly at raw batter for an hour.
Right, it should complain. It should refuse to bake the cake. It should throw a red flag, beep loudly, and say, I need a temperature before I proceed. The architecture must explicitly distinguish between states of absence. Is this setting intentionally unset by the user? Is it inheriting a blank value from the company? Is it overridden locally to be blank? Is the feature disabled entirely? Or is it accidentally missing data that is required for operations? You have to know which kind of blank it is. Exactly. The registry entry for every single key is a field that developers rarely think to ask for.
The test that matters most
What does absence mean for this specific setting? And this flips the entire software testing paradigm on its head. The document argues that the most important test suite isn't the one proving the system works perfectly when everything is filled out correctly. Right. The most critical tests are the negative tests, proving mathematically and systematically that a half-configured building cannot go live on the platform. It physically cannot be turned on. Yes. If the property doesn't have an emergency line set, the system must fail explicitly. It must refuse to turn the AI on, instead of allowing that ambiguous absence to propagate into a silent, catastrophic failure two months later when a pipe bursts at 2 a.m.
Recap: the foundation, rebuilt
Okay, let's take a breath and recap the intellectual journey so far, because they have basically rebuilt the foundation of the house. They really did. The engineering team dodged the trap of neat, rigid folder hierarchies. They recognized that depth should be data, so they bought the fold, centralizing resolution into one mechanism. They enforced exceptions as explicit records with expiration dates, stopping policy rot. And they mandated that absence is not neutral, preventing silent failures. This is brilliant, elegant, architectural theory. But did it actually work? That is the ultimate question for any engineering team, isn't it?
Surviving contact with customers who do not exist yet
Yeah. Theoretical elegance doesn't pay the payroll. Exactly. The true test of any architecture is whether it survives contact with future unknown customer shapes without requiring a whole new migration. And the authors of this document did something I find incredibly impressive, and frankly, quite brave. They ran a generalizability test. They essentially locked themselves in a room and threw eight hypothetical, wildly different, chaotic customer shapes at their new model to see if it would break. It is a masterclass in intellectual honesty. You have to be deeply skeptical of your own brilliant design, rather than just trying to prove yourself right.
The shapes it absorbs
Let's look at the gauntlet they ran it through. Let's look at the successes first. Okay, shape number one, a real estate investment trust, a REIT. Let's say it has one overarching owner, 200 properties, and intermediate regional managers who only need to see their specific region. The model holds perfectly. Regions in this new architecture are just groups. The fold chain simply becomes company, region, building. So no big database changes. Exactly. It is literally just one extra element passed into the resolution list, not a fundamental schema change to the database. And the regional managers just scope their user access to that specific group tag.
This is exactly the shape the centralized fold was designed to absorb effortlessly. Shape number two, a massive third-party management company running 30 different owners under one single operational brand. It holds, and it proves that owner is a genuinely orthogonal access to operations. Meaning they don't affect each other. Right. A building can be sold to a new owner without changing its management company, its consumer brand, or its phone number. The owner tag sits beside the hierarchy, not inside it, so the fold doesn't trip over it. Shape number three, student housing. One brand, a specific phone number per university campus, and brutal, highly predictable seasonality with leasing.
Everyone moves in in August. Holds perfectly. The campus phone number is just a channel-binding scope to a group tag. In the seasonality. That isn't a structural change. That is just a parameter key, like a rent concession, with a strict date schedule attached to it. It has no structural implication for the core architecture whatsoever. And shape number four, which actually mirrors part of Setis Group's portfolio, 400 scattered single-family homes across a single city. This one holds, but it requires a human modeling judgment. Instead of treating them as 400 separate distinct buildings, which would multiply the onboarding checklist and the UI dropdown menus by 400, making the software unusable.
Four hundred units in one record
Right, that would be awful. Their model is one single building record in the database that contains 400 units, with per-unit addresses. The fold handles it beautifully because the complexity is pushed down to the unit level, not the structural level. That is really smart. But the document doesn't shy away from where the model fails, and I think analyzing the failures of a system is almost more instructive than celebrating its successes. Absolutely. Explicitly writing down the hard limits of your system prevents future developers from wasting weeks of their lives trying to wedge impossible data into it.
Failure case: the joint venture
So failure case one, a joint venture, one single massive apartment building co-owned and co-managed by two entirely different management companies. The document notes this is only partially supported. You can express the split financial ownership shares, sure. Okay. But having two active management companies with two different sets of policies, two different AI agents, and two different bank accounts operating one single building is fundamentally inexpressible in this model. Because the fold needs a boss. Yes. The fold demands a single chain of command for operations. And they know, crucially, it wouldn't have worked under any of the rejected designs either.
The weakest case: an acquisition
It is a known hard boundary of the abstraction they built. And the weakest case they found, the true failure. An acquisition. Two entirely different companies who are both already on the platform merging into one. This is a genuine unavoidable failure of the architecture. Because person identity is strictly scoped to the company level. Remember the tenant unsubscribe bug we talked about earlier? Merging two companies means reconciling two entirely separate identity partitions. It's a huge mess. The fold mechanism provides zero help here. You have to figure out if John Doe in company A is the exact same human being as J Doe in company B, it is a massive complex messy database migration.
Writing the limit down
And the authors state clearly and honestly, this is a genuine limit of our design and it should be written down as one. So after this incredible intellectual journey, we arrive at the final overarching architectural question. Did buying the fold actually create a reusable foundational primitive for the software industry? Or did they just spend a massive amount of engineering time building a highly sophisticated clever hack that only solves Situs group specific problems today? That is the multimillion dollar question. Did they just kick the technical debt can down the road? Or did they actually change the nature of the road itself?
What the investment actually bought
Right. The document concludes that the real return on this massive investment wasn't building a magical system that supports every single weird corporate shape out of the box with zero effort. So what is the actual ROI then? If it's not magic, what did they buy? The true ROI was transforming what used to be a terrifying engineering problem into a routine configuration conversation. Oh, that makes sense. If a bizarre new customer with a shape nobody's ever seen walks in the door next year, the engineers do not have to open the code base and rewrite logic.
The sales and onboarding teams just sit down with the customer and say, our resolution chain is just a list of tags. Tell us the shape of your business and we will configure the tags to match it. It moves the complexity out of the fragile application logic and into a generalized stable infrastructure mechanism. Exactly. It is the difference between custom building a bespoke house with permanent walls for every single new tenant versus building an incredibly flexible modular home where the onboarding team just rearranges the temporary walls based on who is moving in that day.
The journey, end to end
What an incredible journey through the diagnostic muddy waters of software architecture. We started with a chaotic real world client see this group with their single phone number and highly fragmented legal entities. We saw why the instinct to just build neat little nested desktop folders completely fails when reality overlaps. We learned that depth should be data and that centralizing your rules buying the fold eliminates the recurring nightmare of technical debt. It really has. We discovered that a conversation discovers context just like a human receptionist figuring out which building you were calling about rather than a system crashing because it doesn't know yet.
The two rules that outlive the software
And we unpack those two critical rules that extend far beyond software deep into how any organization should function. I want to explicitly repeat these for you because they are profound enough to write on a sticky note and put on your monitor. Number one, an exception is a record, not a hole in the rule. If you are going to deviate from a standard policy, you must rigorously document who approved it, why they approved it, and for exactly how long it is valid. Otherwise, your undocumented exceptions slowly become the new invisible rules of your business.
And number two, absence is not neutral. You cannot assume that blank spaces or missing data mean everything is fine and you should just push forward. You must define what happens when crucial information is missing and your systems, whether they are digital or human, must fail safely and explicitly when they don't have what they need to operate. This brings me to a final thought for you to mull over as we wrap up today. Look around your own life or your own team or your own organization today. Where are you treating absence as if it is neutral?
Where are you assuming no news is good news?
Where are you assuming that no news is good news when maybe it is actually a silent cascading failure? Yeah, that's a dangerous assumption. And where do you have a hole in the rule? A casual, undocumented workaround that everyone just accepts that really needs to be formalized as a recorded exception. Software architecture at its core is just human logic and organizational behavior written in stone. Maybe it is time to audit your own. It is a powerful exercise because eventually, reality will test whatever structure you have built. It absolutely will. Thank you so much for joining us on this deep dive.
We'll see you next time.