Building A-du · Part One: A-du Rent
Building A-du: Part One
Chris Koss, AIA|Published May 4, 2026|Last updated May 29, 2026
Why every landlord on A-du clears identity verification first. How a single verification step became the foundation A-du Rent is built on, and why it sits before any landlord can do anything that touches a tenant's data.
The problem
A rental marketplace is a trust problem before it's a product problem. A tenant who hands over identity documents, employment records, and a credit pull is taking a real risk that the person on the other side is who they say they are. A landlord on the other side of that exchange is taking a real risk too. They're about to invite a stranger into a unit they've spent years and a real chunk of money building. If either side of that transaction can be impersonated, the platform is a liability machine.
When I started building A-du Rent I had to decide where the trust gate would sit. The path of least resistance is to ask for a name, an email, maybe a phone number, and let people start listing or applying. I've used platforms like that. They feel frictionless right up until something goes wrong, at which point you find out nobody on the other side was ever actually verified.
I didn't want to build that platform.
What we built
Every landlord on A-du goes through identity verification before they can do anything that touches a tenant's data. That includes requesting a screening report, generating a lease, accepting a reservation, or collecting rent.
The verification itself is run by Stripe, the same company most people know for handling card payments. Stripe runs an identity product that does a real document-and-selfie check, the kind banks and brokerages use when you open a new account. It takes a couple of minutes. The landlord sees the standard Stripe screen, snaps a photo of their driver's license or passport, takes a selfie, and that's it. We don't see the document images at all. We just see the verified-or-not result.
What we do see, and what the rest of the platform reads from, is a clear "verified" status on the landlord's profile. Every sensitive part of A-du Rent (request a screening, sign a lease, take a payment) checks that status before it does anything. That check happens on our servers, not in the browser, so the gate can't be talked around.
We also chose to verify once, not per listing or per transaction. The verification result lives on the profile, and every part of the platform reads from that single source. The alternative, re-verifying for each new flow, would have created three or four near-identical implementations that would inevitably drift apart. One source of truth is harder to get wrong.
What it means for you
If you list on A-du Rent, you'll go through the verification once when you first set up your landlord profile, and then never again. From that point on, every screening request and every lease you sign carries verified identity behind it. Tenants applying to your listing know that the person on the other side isn't a Craigslist email address. They're a verified individual with documented identity.
If you apply for an ADU on A-du Rent as a tenant, you can know that the landlord you're handing your data to is, at a real document-and-selfie level, the person they say they are. That's a small thing, and you only notice it when it's missing somewhere else.
A note on cost: tenant signups are free, and our first 100 Rent listings carry no landlord platform fees for life. Verification is the same regardless of which side of that line you fall on. We don't charge to be verified.
What I learned
Two things, mostly.
First, "frictionless onboarding" is a metric that lies. Every step you remove from a flow makes the flow easier and makes the platform weaker. There are flows where that tradeoff is worth it. Browsing listings, for example, should be as close to zero friction as possible. There are flows where it isn't, and identity is the clearest one. The right question isn't "how do we minimize signup friction"; it's "where does the friction belong, and what is it buying us." For us it's buying trust we can stand behind, and we put it at the front of the workflow instead of trying to retrofit it later.
Second, gates work best when you build them once and use them everywhere. We don't ask landlords to re-verify per listing or per screening request. We verify once, the platform remembers, and every downstream feature reads off that single record. The cost is one careful piece of work up front. The benefit is that A-du doesn't end up with three different "is this person verified" answers that drift apart over time.
There's a third thing, less of a lesson and more of a posture: I trust boring infrastructure now in a way I didn't a few years ago. Stripe Identity isn't novel. It's exactly the kind of unsexy, well-tested rail a serious platform should sit on top of, and I'd rather use it than invent a clever in-house alternative that's worse on every axis. A lot of building A-du has been about that kind of choice. Letting the boring, correct option do the work, so we can spend our judgment on the parts that actually need it.
Next in the series: how I rebuilt tenant screening on top of TazWorks/RentPrep, and why the credit-report side of that took more care than the rest of the platform combined.