Building A-du · Part Five: Behind the platform
Building A-du: Part Five
Chris Koss, AIA|Published May 13, 2026|Last updated May 29, 2026
We were calling our customers the wrong word. Renaming 'homeowner' to 'landlord' across more than a dozen tables took months, and that's why language is part of the product.
The problem
For the first stretch of A-du's life, the word the platform used internally for "the person who owns the property and is renting out the ADU" was homeowner. It made sense at the time. Most of our users are homeowners, and the homeowner framing captured the everyday reality of building an ADU on the lot where you live.
Then we started running real flows with real users, and we noticed two things.
The first was that "homeowner" wasn't quite the role we were talking about. A homeowner is the person who owns a house. A landlord is the person who rents one out. Most of the time, on A-du, those are the same person. But not always. We started seeing flows where they diverged: a homeowner with multiple ADUs, a property held in an LLC, a manager handling the rental side on the homeowner's behalf. The language we were using made those situations harder to reason about than they had to be.
The second was a smaller, more honest thing. The word "homeowner" set the wrong frame for the responsibility the person was taking on. When you sign a lease, you become a landlord, with the legal obligations of one: fair-housing rules, FCRA obligations, habitability requirements, all of it. "Homeowner" is a word that lets people forget that. "Landlord" doesn't.
So we renamed it. Everywhere.
What we built
What this looked like in practice was a multi-month, deliberately slow rename across the entire platform. The visible side (the words on the screen, the emails, the dashboard labels) happened relatively quickly. The invisible side (the names of columns in our database, the names of fields in our code, the names of variables in dozens of files) took the rest of the year.
It moved in waves. The first migration tackled manager-agreement records. The next moved invoices. Then permit fee requests. Then one-time charges. Then lease agreements themselves. Each migration renamed the underlying field, fixed all the places in the code that referenced the old name, updated the data that was already in the database, and shipped. Then we moved to the next one.
Why so slow? Because doing this fast, in one big all-at-once migration, would have been the exact wrong move. The platform was already serving real landlords, real tenants, and real money was moving through it. A bulk rename that touches dozens of tables and hundreds of files simultaneously is an excellent way to take down production for a day, and a worse way to introduce a subtle bug that nobody notices until somebody's invoice references the wrong record.
The slow path was: rename one thing at a time, ship it, watch for a few days, move on. By the end, the schema and the code both used "landlord" everywhere it mattered, and we hadn't lost sleep over any of the steps.
What it means for you
Most of this was invisible to you, and that was the point. The landlord dashboard kept working. Invoices kept generating. Leases kept signing. Behind the scenes, the platform got clearer about what its users actually do.
A user-facing thing did change, though. The language across the product is now consistent. The dashboard says "landlord." The emails say "landlord." The legal documents say "landlord." If you're listing on A-du Rent, the platform talks to you in the same language a court would, and there's no confusion about which role you're playing in any given workflow.
For tenants, the practical effect is similar. You know exactly who's on the other end of a lease or a payment, and the platform doesn't let the relationship slide into the cozier-but-fuzzier "homeowner" framing.
What I learned
The first lesson is the obvious one: if the language is wrong, the product is wrong. There's a software-engineering tradition called "domain-driven design" that boils down, more or less, to if your code uses different words than your users use, you're going to have a bad time. The reverse is also true: when the words you use in the product don't match the role the user is actually playing, your product is going to drift.
The second lesson is about pace. The temptation when you realize you have an outdated word in the schema is to fix it all in a weekend. That impulse is wrong. A change that touches this many surfaces (database, code, UI, emails, legal docs) should take its time, in steps small enough that any single step is reversible. The whole rename took us about four months of incremental migrations. Nobody noticed. That's the goal.
The third thing, and this is more about taste, is that language is a place where my architect background actually helped. Architects spend a lot of time thinking about words, because the language used in a building's program (this is a "pavilion" vs. this is a "shed"; this is a "courtyard" vs. this is a "lightwell") shapes the design. Software has the same property. The word you put on the column shapes the thing the column ends up doing. Picking the right one is part of the work, not a polishing pass at the end.
A small note of honesty: there are still a few internal variable names in older parts of the codebase that say "homeowner." We'll get to them. The user-facing parts of the platform, the parts that actually touch a person, are the ones we made sure to clean up first.
Next in the series: how A-du Rent finds, surfaces, and lets landlords claim ADUs we already know about, by mailing real postcards.