Building A-du · Part One: A-du Rent
Building A-du: Part One
Chris Koss, AIA|Published: May 4, 2026
Last updated: September 25, 2026
Why every landlord on A-du clears identity verification before rent reaches them. How a single verification step became the foundation A-du Rent is built on, and why, since September 2026, it sits at the first rent payment instead of before a listing goes live.
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.
Update, September 2026: I've moved this gate. This section, and the lesson at the end about putting friction at the front, describe how A-du Rent launched. Here's how it works now. A landlord can publish and edit a listing, request a screening, generate a lease, and accept a reservation without verifying first. The check sits where money moves: A-du won't charge a tenant until the landlord's Stripe payout account is verified, so nobody collects rent through A-du unverified. Claiming a listing A-du already has on file still requires verification up front, because that's where it stops someone from claiming a property that isn't theirs. The verification itself also works differently from what I describe below. For landlords it happens inside Stripe's payout-account setup, which asks for details like date of birth and the last four digits of a Social Security number, not the separate document-and-selfie check, which we still use elsewhere on the platform. Why the move: we were asking homeowners for their Social Security digits before a single renter had seen the unit. The ask was real and the payoff was hypothetical. Friction belongs where it buys something, and for a landlord that moment is the first rent payment.
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 set up payments to receive rent (you can do it early from your dashboard if you'd rather get it out of the way), and then never again. From that point on, every rent payment you receive carries verified identity behind it. Tenants paying rent on 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 rent an ADU on A-du Rent as a tenant, you can know that the landlord your rent goes to has been verified by Stripe as the person they say they are, before A-du will take a payment from you. 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 the first 100 published listings on A-du Rent pay no landlord service fee, 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.