Building A-du · Part Two: A-du Rent
Building A-du: Part Two
Chris Koss, AIA|Published May 6, 2026|Last updated May 29, 2026
Why we rebuilt tenant screening twice. Tenant screening is the highest-stakes thing a rental platform does. Here's how A-du Rent ended up on RentPrep, what we tried first, and why I'd rather over-design this corner of the product than under-design it.
The problem
Tenant screening is the single most consequential thing a rental platform does. You're pulling a credit inquiry on a real person, returning a recommendation that may decide whether they get housing, and doing it under the Fair Credit Reporting Act, which treats both you and the landlord as parties with specific legal obligations. There are versions of "we ran a credit check" that will get a landlord sued. There are versions that won't. The difference is mostly invisible to landlords using the platform, which is exactly why a platform should get it right on their behalf.
Two things follow from that. First, you can't realistically build your own credit-reporting agency. You have to integrate with one. Second, the integration you pick has to be willing to do the unglamorous compliance work with you, and has to give you back data you can act on cleanly when something goes sideways.
What we built
A-du Rent screens tenants through TazWorks, the platform behind the RentPrep brand. The flow looks like this:
A tenant fills out a screening application (name, address history, employment, the usual), agrees to RentPrep's terms, authorizes a credit pull, and we send the request to RentPrep. RentPrep runs the credit and criminal-background portions separately, calls us back when each one is ready, and we surface the results in the landlord's dashboard. The tenant gets a copy of the report on request. The landlord gets a recommendation and the supporting detail.
Three pieces of judgment shaped that flow.
Reuse, not re-pay. Tenants on A-du can fill out their screening application once, get a result, and reuse it across multiple listings without paying again or re-disclosing their data. We call this a portable profile. It expires, but for the window of validity, applying to a second listing is two clicks instead of forty. That's not a side feature; it's how a tenant treats themselves like a person with a job and a life rather than a faucet for application fees.
Explicit consent, with a version number. Every tenant screened on A-du has to actively agree to RentPrep's terms before the request goes out, and we record exactly which version they agreed to and when. That sounds bureaucratic. It's the difference between a flow that holds up under a complaint and one that doesn't.
Two orders, not one. When we first built screening, we treated each screening request as a single thing. RentPrep returns credit and criminal background as separate orders with separate timelines, and that turned out to matter. We restructured to track each one independently, with its own status. That meant landlords could see "credit is back, criminal is still pending" instead of staring at a screening request that was either fully done or fully not, with no visibility into what was holding it up.
There's an honest detour in the history. The first version of A-du Rent's screening flow was built around Checkr, not RentPrep. Checkr is great for employee-style background screening, less great for the landlord-tenant rental flow with FCRA notice obligations on top. We ran into those edges, did the right thing, and rebuilt on RentPrep. We left the database half-shaped around the old integration for a few weeks longer than I'd like to admit before cleaning it up. The migration that finally removed the orphaned columns has a comment that just says: "…has since been replaced by RentPrep (TazWorks)…". I keep that note around because it's a reminder of the kind of decision I want to remember next time I'm tempted to ship before I've validated the integration.
A small, unglamorous thing worth mentioning, since the title references it. RentPrep's credit reports come back in an industry-standard format called MISMO XML. It was originally a mortgage data format, and is now the standard format for consumer credit data in this kind of integration. Pulling the credit score and the legal "reason codes" out of that format is the kind of careful, boring work that has to be done correctly because it's how a number ends up showing in a landlord's dashboard, and how the right language ends up on an adverse-action notice if a screening result fails. We do that work on our servers. The landlord just sees a number.
What it means for you
If you're a tenant, you fill out a screening application once and reuse it for as long as it's valid. You see exactly what you're agreeing to, with a record of which terms and which version. You can pull up the report we relied on, through a secure link, if you ever need to.
If you're a landlord, you request a screening on a candidate, the order goes out, and the result comes back into your dashboard with the credit picture, the criminal-background summary, and the supporting PDF, visible only to the landlord and tenant who are party to it.
For both sides: signups remain free, screening fees are straightforward and shown before you authorize, and the first 100 landlords on A-du Rent pay no platform fees, ever, including on how screening flows through.
What I learned
The integration you ship is a smaller fraction of the work than the integration you pick. We spent more calendar time on the Checkr build than I'd like to admit before realizing the model didn't match. The lesson there isn't "test integrations carefully" (everyone says that); it's to test them against the specific compliance flow your product needs, not the demo flow on the homepage. RentPrep's tenant-screening path had FCRA-aware hooks where we needed them. Checkr's didn't.
I also learned to stop being precious about the old work. We removed the orphaned columns from the previous integration in a single migration with a clear comment, and the codebase got much easier to reason about after. Carrying around dead fields "just in case" is how a system becomes the place where decisions go to die. Removing them was a small win that paid out for months.
The third lesson is one I'll keep coming back to: when an external partner gives you data in a domain-specific format, the right move is to learn that format well enough to extract what you need cleanly. The lazy alternative ("just store the whole blob, deal with it later") looks easy on day one and turns into the kind of bug that costs you a real apology to a real person.
Next in the series: the Fair Credit Reporting Act adverse-action workflow, and how a small scheduled job does most of the legal work for you when a screening result doesn't pass.