MiddleMan

Inspiration

I was apartment hunting in NYC and kept hitting the same uncomfortable moment: to be considered for a unit I'd never seen, I had to hand my SSN, bank statements, pay stubs, and tax returns to a broker I'd met once, who'd email them around in plaintext and keep them who-knows-where forever. And I'd do it three or four times over for apartments I wouldn't get. The whole packet ends up sitting in a stranger's inbox indefinitely, with no one obligated to delete it. It felt backwards that proving "I can afford this" required surrendering my entire financial identity to whoever happened to be holding the listing. MiddleMan started from a simple question: what if the landlord could get the answer they actually need without the tenant having to over-share to get it?

What it does

MiddleMan sits between renters and landlords so sensitive data doesn't have to change hands directly. Landlords set their criteria, post unit details, and see who's applied against those criteria. Renters verify their income through a direct Plaid connection — with identity verification through Stripe Identity as the next piece — so instead of emailing a folder of forgeable PDFs, the applicant arrives already verified at the source. The landlord gets facts they can trust; the renter shares far less to prove the same thing.

How we built it

We built the frontend in Next.js, with Supabase handling auth and data and a FastAPI backend orchestrating the verification flow. On the tenant side, income verification runs through Plaid, which reads income directly at the payroll/bank source rather than trusting an uploaded document — so an applicant arrives with income confirmed at the source instead of a folder of forgeable PDFs. Identity verification is designed around Stripe Identity (document authentication plus liveness); we scoped the integration but ran out of runway to ship it during the hackathon, so it's the first thing landing next. The landlord side is a portal where they define tenant criteria, upload apartment and unit details, and review incoming applicants against those criteria. Rather than building verification from scratch, we orchestrated a stack of specialized providers and put our own work into the flow that ties them together — tenant-controlled verification in, a clean applicant view out.

Challenges we ran into

The hardest problems turned out to be legal and architectural, not front-end. The big one is regulatory status: the moment a platform assembles information about people for housing decisions, it risks becoming a "consumer reporting agency" under the FCRA, which carries real obligations — so where verification happens and who initiates a credit pull isn't a detail, it decides what the product is even allowed to do. We also had to design around a hard truth we kept running into: you can't make sensitive data "self-destruct" on someone else's machine, so the right move is to not send the raw data at all and instead pass a verified result. And there's a genuine tension in being the middle layer — concentrating this data makes you a target, so minimizing what you store has to be a design principle, not an afterthought. On the practical side, scoping the verification stack under time pressure meant making calls about what to ship — income verification landed end-to-end; identity verification got designed but cut for time.

Accomplishments that we're proud of

We got a working loop: a renter can verify income at the source, and a landlord can post a unit, set criteria, and review applicants against it — without the sensitive documents ever passing through the landlord's inbox — with identity verification designed and ready to integrate next. More than the code, we're proud that the privacy win and the fraud win are the same feature: verifying income directly means the renter over-shares less and the landlord gets something a fake pay stub can't reproduce. That double duty is the core insight, and the prototype proves it's buildable.

What we learned

The biggest lesson: the landlord's six document requests are mostly one question — "can they pay?" — asked six redundant ways, plus one different question, "are they who they say?" Once you verify the underlying facts directly, most of those documents become unnecessary rather than something to authenticate. We also learned that you can't out-engineer a forwarded screenshot or a deleted-file trick — real protection comes from controlling access on your own infrastructure and never putting raw data on the other side. And we learned this is a space with serious, well-funded incumbents, which sharpened rather than discouraged us: the gap isn't "screening," it's tenant-controlled screening.

What's next for MiddleMan

The immediate next step is shipping the Stripe Identity integration we scoped — document authentication plus liveness — to close the identity half of the loop. Beyond that: nail down the regulatory architecture with real legal input, specifically keeping credit pulls tenant-initiated so the platform stays clear of CRA scope, since that decision shapes everything downstream. Then add the pieces that make it defensible and sellable: verified claims rather than any kind of score (to stay on the right side of fair-housing rules), plus expiring, watermarked, revocable access for any document that genuinely must change hands. On the go-to-market side, the real path is through NYC brokerages rather than one landlord at a time, and the honest next step is a small validation test — putting the verified-applicant flow in front of a handful of real leasing agents to see whether they'll accept it in place of the raw packet before building further.

One thing we'd redo: the name

We're not sold on "MiddleMan" — that's a branding exercise we chose to save for later :). It does half make sense, since we're the layer sitting between landlords and tenants, brokering trust while leaking as little as possible. But we know it cuts the wrong way too: "middleman" is exactly the careless intermediary we're trying to replace, not add. Consider it a placeholder we're aware of.