Doorpass

Residential real estate access still depends on a strange little ritual: hide a key near the house, let authorized people find it, and hope the system around it holds. It holds until it doesn't. The lockbox is in the wrong place, the code fails, the agent can't get a signal, and the seller never has a useful sense of who entered the home or when. Meanwhile a buyer's agent is standing at the door with clients behind them, negotiating with a piece of aging access infrastructure.

Doorpass treats the showing differently. Instead of access as a shared secret, access becomes a permissioned event: someone requests it, someone approves it, the agent arrives, the door unlocks, and the system records what happened. That shift changed the design problem: the work became designing a clean handoff between people who don't all trust each other yet.

In January 2025 I flew to Louisville for a two-day product workshop with the founder and the CTO I'd recruited. The goal was to leave with the first version of the product: what Doorpass would be first, who it served, what had to work in the first pilot, and which tempting ideas we weren't going to build yet. Having the CTO in the room meant feasibility shaped the product strategy from the first sketch.

The opportunity space was broad: transactions, seller safety, agent coordination, showing access, brokerage compliance, hardware installation, payments, scheduling, and eventually a larger access platform. Too broad. A nice way to make a deck, a terrible way to ship. The important move was narrowing the wedge. We focused on the access moment because that's where the pain was immediate, repeated, and easy for agents to recognize. If Doorpass could make showings easier, safer, and more transparent, the product had a reason to exist before any grand platform story.

By the end of the workshop we had the first shape of the app: how properties get created, how locks get installed, how access gets requested and approved, how an agent unlocks the door, and how activity gets recorded. That workshop became the spine of everything we've built since.

The hardest part of Doorpass was the permission model around the unlock. Who's allowed in, who approved them, and for how long? What happens when a showing changes, when access needs to be revoked, or when someone is standing at the door on a bad connection? What does the seller see, what does the agent see, and what does the brokerage need later if something goes wrong? Those questions shaped the app more than the lock did.

The product also had to make sense to four overlapping groups at once: sellers who wanted control and a record, listing agents who wanted fewer coordination problems, buyer's agents who wanted reliable entry, and brokerages who wanted standardization and visibility. The app had to serve all four without becoming four different products, so I made the property the center of the system.

The obvious version of the app asks people what they are during onboarding: homeowner, listing agent, buyer's agent. Clean on a whiteboard, wrong in real life. The same person can be a homeowner on one property, a listing agent on another, and a guest somewhere else, and a spouse, contractor, or assistant may need access without identifying with any industry role at all. So onboarding got simpler: create a profile, add or claim a property, and let the property determine what's available. The app stopped asking what kind of person you are and started asking what your relationship to this property is. A small distinction with a lot of product weight behind it.

Language got the same treatment. Early versions ran on the metaphor of "passes": a person receives a pass, the pass grants access, the pass expires. It worked internally, but metaphors are expensive when someone is standing at a door, so the product language moved to plain "access," in three patterns: anytime, until revoked; scheduled, for a specific showing; and recurring, for predictable repeat visits. The system could be sophisticated underneath. At the surface it had to feel plain enough that agents and sellers could trust it without thinking through every edge case.

The model also got narrower as it got clearer. One early version treated the app more like a general real estate tool, with more of the surrounding transaction visible in the interface. As the product sharpened, I pulled the app back toward the access moment: property, lock, access, activity. That made the system easier to explain, easier to build, and easier to pilot.

At the door, the product shouldn't feel clever. An agent has already scheduled the showing, driven to the property, and walked up the path with clients behind them. That's the moment for confidence.

So I designed the app through several iterations around one principle: handle the complexity earlier so the door moment can be calm. The access should be unambiguous, the unlock action obvious, the feedback immediate. Security has to be present without becoming airport theater. Access is bound to the right person and device, the app confirms at the door, and everything gets logged, but the user-facing moment stays simple: yes, this is the property; yes, I have access; yes, the lock is responding. The best version of that screen is reassuring rather than impressive.

Doorpass is app-enabled hardware, which means the clean product diagram eventually runs into real doors, real locks, real phones, and real agents in a hurry. There's a specific humility required in hardware-adjacent software: a flow can look perfect in Figma and still lose to a sleeping lock, a dead spot, or a homeowner who doesn't want a science project attached to their house. So installation, lock state, connectivity, and recovery were treated as core product problems, and the app had to support setup, access, and recovery as thoroughly as the happy path. Underneath the screens, I built a design system that could absorb property states, access states, installation flows, empty states, and hardware errors without turning every new condition into a one-off.

I designed and built doorpass.ai end to end: content, information architecture, layout, visual design, development, and the refined brand expression. The site's job was to make a normalized pain visible again. Agents already know lockbox pain, and sellers already feel the strangeness of leaving home access in a box outside; the site had to turn those familiar annoyances into a product argument. The brand also had to catch up with the product. The original identity gave us a starting point, and I refined the expression as the app took shape so Doorpass read as the thing we were actually building: secure, modern, restrained.

I also created the pitch and progress materials the founder needed for investors, advisors, and pilot customers. The website had to make the product easy to understand; the decks had to make the company easy to believe, connecting the market pain, the access model, the product flow, the economics, and the pilot plan. The founder led much of the content strategy, and I shaped the narrative and designed the decks so the argument could travel without a twenty-minute spoken preamble. Early-stage products need artifacts that work when the founder isn't in the room.

By June 2026, the Doorpass iOS app was live in the App Store and working end to end: claim a property, install a lock, grant access, and operate the lock. I designed the product and the app; our CTO built it. The website is live, the pitch materials are in use, and the product is preparing for pilots with real estate teams.

That matters because the work moved the whole distance: from brand conversations to product direction, from a workshop to an app, from app design to an App Store release, from product design to a public site, and from the site to pitch and pilot materials. My contribution was the connective tissue, making Doorpass coherent across product strategy, app design, access logic, website, brand, and pitch.

Take away the smart lock and the real estate category, and what's left is one simple action with a complicated system underneath it. The user doesn't care about the permission model, device binding, lock state, or audit trail. They care that the door opens when it should, stays shut when it shouldn't, and leaves the right people confident about what happened. The lock, the app, the site, and the pitch all exist in service of that. The product is the trust system that makes the unlock feel safe.